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

[Lorenzo Stoakes]

On Tue, Oct 01, 2024 at 10:38:35AM GMT, Bert Karwatzki wrote:
> Am Dienstag, dem 01.10.2024 um 09:02 +0100 schrieb Lorenzo Stoakes:
> > On Tue, Oct 01, 2024 at 04:34:00AM GMT, Bert Karwatzki wrote:
> > > I just noticed (via a bisect between v6.11 and v6.12-rc1) that this patch
> > > (commit f8d112a4e657 in linux-next tree) leads to a severe memory corruption
> > > error under these (rather rare) circumstances:
> > > 1. Start a 32bit windows game via steam (which uses proton, steam's version of wine)
> > > 2. When starting the game you the proton version used has to be updated
> >
> > Yikes. Thanks for the report, very very much appreciated. Will look into
> > this as Liam is out until next week.
> >
> > How repro is this? Is it consistent?
>
> Reproducability is 100%, only the method is weird, you have to switch to an
> older version of proton in the steam settings of the game, start the game and
> then switch back to the new version and start the game again.
>  It might also be possible using standard wine and repeatedly upgrading and
> downgrading wine and (I have not tried this, yet ...)
>

OK that's good.

Actually a quick one if you have a sec - could you try the same thing with tip
of Linus's tree?

This will help eliminate any other possible cause.

Thanks!

And again very grateful for you taking the time to report this/provide details.

> >
> > Can you confirm exactly what commit you are at in the kernel when you
> > generate the below dmesg?
> >
> > If you are able to reliably repro, could you try again with:
>
> Kernel is "commit f8d112a4e657 (HEAD) mm/mmap: avoid zeroing vma tree in
> mmap_region()" in linux-next tree.

Thanks!

>
>
> >
> > CONFIG_DEBUG_VM, CONFIG_DEBUG_VM_MAPLE_TREE and CONFIG_DEBUG_MAPLE_TREE enabled?
> >
> > Might be useful to get CONFIG_KASAN on the go too... and CONFIG_DEBUG_INFO :))
> >
> > Actually CONFIG_LOCKDEP and CONFIG_PROVE_LOCKING would be handy here too...
> >
> > Very much appreciated!
> >
> > >
> > > The effect is the following: The updating process of proton hangs and the game does
> > > not start and even after an exit from steam two processes remain, one of them at
> > > 100% CPU:
> > > $ ps aux | grep rundll
> > > bert      222638  1.7  0.1 2054868 87492 ?       Ss   23:14   0:01 C:\windows\syswow64\rundll32.exe setupapi,InstallHinfSection Wow64Install 128 \\?\Z:\mnt\data\.steam\debian-installation\steamapps\common\Proton - Experimental\files\share\wine\wine.inf
> > > bert      222639 99.8  0.0 2054868 2380 ?        R    23:14   1:01 C:\windows\syswow64\rundll32.exe setupapi,InstallHinfSection Wow64Install 128 \\?\Z:\mnt\data\.steam\debian-installation\steamapps\common\Proton - Experimental\files\share\wine\wine.inf
> >
> > Is there any dmesg at this point? Or not?
>
> As long as I don not try to kill those processes there's no error message (but I
> only have let them run for a few minutes ...)

Ugh ok I'm thinking debug config options should throw things up.

>
> >
> > >
> > > When trying to kill those processes with "killall rundll32.exe", these error happen:
> > >
> > > [ T4313] ------------[ cut here ]------------
> > > [ T4313] WARNING: CPU: 6 PID: 4313 at include/linux/rwsem.h:85 free_pgtables+0x233/0x250
> >
> > That should be rwsem_assert_held_write_nolockdep() if my kernel is not too
> > different from yours, which suggests we're asserting that a write lock is
> > held and it's not...
> >
>
> Yes, that's the warning.

Thanks, that's really crazy though.

Digging further...

>
> Bert Karwatzki
>
>