Re: [PATCH v8 14/21] mm/mmap: Avoid zeroing vma tree in mmap_region()

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Wed, Oct 02, 2024 at 12:51:28PM GMT, Bert Karwatzki wrote:
> These printk patches tend to increase logs beyond reasonable manner (I've tried
> something similar for amdgpu, and got size of hundreds of M. This is already
> to big to be copied by clipboard into evolution so I'm writing this with vim, I've
> un-CCed lkml, too).
>  Will those printks still be helpful if they'd be done conditionally, e.g.
> if (!strcmp(get_current()->comm, "rundll32.exe"))
> 	printk();
> ?
>
> Bert Karwatzki
>
> PS: Anyway, here's the log:
>

[snip]

Thanks very much for posting, this is fine, I have the information I need
from this, much appreciated.

The size of these logs is why I wanted to keep them off-list (with a link
to them for people to see), they are now breaking lei completely it
seems... hopefully we shouldn't need much more like this anyway :)

Am homing in on the problem here.

The issue is definitely that we have an extra entry/pivot for the end of
this range, at exclusive end 0x68000000 (that is from maple tree point of
view, inclusive end 0x67ffffff).

I have a theory that we are trying to do this overwrite with an invalid
maple tree iterator meaning that we set the 0x67ffffff pivot at the wrong
place with the old one still in place...

I hopefully can get a simpler repro working for this!

Will ping back once I have something more.

Again THANKS for all your help. I owe you several beers...