* Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> [221011 12:35]: > Dear Liam, dear Matthew, dear all, > > The reproducer for the 'memory leak in __anon_vma_prepare' bug (see > https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3113810b9abd3dfeb581759df93d3171d1a90f18) > is reproducible, it is triggering the memory leak on the current > mainline (commit 60bb8154d1d7), and it was not triggering on v6.0. My > build config is a x86_64 defconfig. > > My git bisection showed that: > > 524e00b36e8c547f5582eef3fb645a8d9fc5e3df is the first bad commit > commit 524e00b36e8c547f5582eef3fb645a8d9fc5e3df > Author: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> > Date: Tue Sep 6 19:48:48 2022 +0000 > > The git bisect log is below, note that the commits 7fdbd37da5c6, > d0cf3dd47f0d and 0c563f148043 are marked good in the git bisect as > they caused bugs "BUG: Bad rss-counter state mm: ... type:MM_ANONPAGES > val:2". This bug report might have overshadowed the actual issue, and > hence the bug might have been introduced earlier, but was only visible > once the Bad rss-counter state bug disappeared. > > ... > # first bad commit: [524e00b36e8c547f5582eef3fb645a8d9fc5e3df] mm: > remove rb tree. > > > If there is more information needed or other bisection to be done, > please let me know. Lukas, Thanks for the report. I am trying to reproduce this issue and have not been able to trigger a memory leak. So far I have built using the defconfig from arch/x86/configs/x86_64_defconfig and run the C code from the end of your report above. It also produces some output that is not captured in your report. Are you sure it's the defconfig being used? ------ # ./repro write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory write to /proc/sys/net/core/bpf_jit_kallsyms failed: No such file or directory write to /proc/sys/net/core/bpf_jit_harden failed: No such file or directory write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory ------ Note your output does not mention softlockup or hung_task issues. This is on 6.0.0-rc3-00207-g524e00b36e8c. It is also worth noting that the resulting kernel does not have /sys/kernel/debug/kmemleak. I have also tested your reproducer with my own config which does have the kmemleak debug file, but it did not trigger a memory leak either. I suspect I am missing a config option? Are you using gcc or clang? Thanks, Liam