On 02.07.23 14:27, Bagas Sanjaya wrote: > I notice a regression report on Bugzilla [1]. Quoting from it: > >> After upgrading to kernel version 6.4.0 from 6.3.9, I noticed frequent but >> random crashes in a user space program. After a lot of reduction, I have >> come up with the following reproducer program: > [...] >> After tuning the various parameters for my computer, exit code 2, which >> indicates that memory corruption was detected, occurs approximately 99% of >> the time. Exit code 1, which occurs approximately 1% of the time, means it >> ran out of statically-allocated memory before reproducing the issue, and >> increasing the memory usage any more only leads to diminishing returns. >> There is also something like a 0.1% chance that it segfaults due to memory >> corruption elsewhere than in the statically-allocated buffer. >> >> With this reproducer in hand, I was able to perform the following bisection: > [...] > > See Bugzilla for the full thread.
Additional details from https://bugzilla.kernel.org/show_bug.cgi?id=217624#c5 : ``` I can confirm that v6.4 with 0bff0aaea03e2a3ed6bfa302155cca8a432a1829 reverted no longer causes any memory corruption with either my reproducer or the original program. ``` FWIW: 0bff0aaea03 ("x86/mm: try VMA lock-based page fault handling first") [merged for v6.4-rc1, authored by Suren Baghdasaryan [already CCed]] That's the same commit that causes build problems with go: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf...@kernel.org/ Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot introduced: 0bff0aaea03e2a3
