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