[CCing the regression list] On 03.07.23 20:21, Suren Baghdasaryan wrote: > A memory corruption was reported in [1] with bisection pointing to the > patch [2] enabling per-VMA locks for x86. > Disable per-VMA locks config to prevent this issue while the problem is > being investigated. This is expected to be a temporary measure. I have to wonder: is disabling by default sufficient here? Sure, it's a new feature, so once this change is merged and backported to 6.4.y it's not regression for anyone that will do the jump from older kernels to 6.4.y and run oldconfig. But how about those that did the jump already or will do so before the fix is backported (it's possible that Arch Linux and openSUSE Tumblweed do this; and there is a certain chance that Fedora already has CONFIG_PER_VMA_LOCK enabled in their 6.4 configs, too)? This sounds to me like many of those will have CONFIG_PER_VMA_LOCK enabled in their configs now. And unless I'm missing something switching the default won't turn it off next time they run make oldconfig -- or will it? So for them the regression won't be fixed (unless they fiddle manually with their configuration, but they shouldn't do so to fix a regression). Or is my logic mistaken somewhere? > [1] https://bugzilla.kernel.org/show_bug.cgi?id=217624 Side note: that should be a proper Link: or Closes: tag as described in Documentation/process/submitting-patches.rst or Documentation/process/5.Posting.rst -- and it should be close to the Reported-by: tag (checkpatch.pl should have mentioned that). E.g. like this: > [2] https://lore.kernel.org/all/20230227173632.3292573-30-surenb@xxxxxxxxxx > > Reported-by: Jiri Slaby <jirislaby@xxxxxxxxxx> Closes: https://lore.kernel.org/lkml/dbdef34c-3a07-5951-e1ae-e9c6e3cdf51b@xxxxxxxxxx/ > Reported-by: Jacob Young <jacobly.alt@xxxxxxxxx> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217624 [1] > Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first") > Signed-off-by: Suren Baghdasaryan <surenb@xxxxxxxxxx> > [...] Ciao, Thorsten
