traversing vma on nommu

Liam R. Howlett Liam.Howlett at oracle.com
Wed Nov 6 18:53:30 PST 2024


* Hajime Tazaki <thehajime at gmail.com> [241106 16:47]:
> 
> Hello,
> 
> Thanks for the detail information.
> 
> > Can you add some (totally untested) debug to the exit path in
> > kernel/acct.c?
> > 
> > +#include <linux/maple_tree.h>
> > 
> > ...
> > 		mmap_read_lock(mm);                                                                                     

I probably should have suggested adding:

if (!strcmp(current->comm, "apk")) {
> > +		mt_dump(&mm->mm_mt, mt_dump_hex);
> > +		mt_validate(&mm->mm_mt);
 }

> >                 for_each_vma(vmi, vma)
> >                         vsize += vma->vm_end - vma->vm_start;                                                           
> >                 mmap_read_unlock(mm);                                                                                   
> > 
> > You will need to enable CONFIG_DEBUG_MAPLE_TREE on the kernel.
> 
> I quickly added the code and here is the just part of the output.
> It's being so long; I put the full output at below.
> 
> https://gist.github.com/thehajime/30485f105ab78a09b66691eb024dc011
> 
> # I'm not yet looking at carefully the log but will do.

I think it's probably more important to try a real build.  I'm surprised
it gets as far as it does with the sequential nulls.

We have 32b testing in userspace for the maple tree, and it works.
maple_tree: 139594121 of 139594121 tests passed

So at least that much is known to work.

As you are probably finding out, building a nommu test system is a pain
(or you probably already know and want to stop doing it and use UML..).

I'll give my m68k build a go against v6.12-rc6.

I had a look at your patches and nothing seems to pop out against
any vma specific code changes in there?

Thanks,
Liam



More information about the maple-tree mailing list