On Mon, Jul 10, 2023 at 07:37:08AM +0200, Jiri Slaby wrote: > On 09. 07. 23, 11:44, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > > This is a note to let you know that I've just added the patch titled > > > > mm: disable CONFIG_PER_VMA_LOCK until its fixed > > > > to the 6.4-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > > The filename of the patch is: > > mm-disable-config_per_vma_lock-until-its-fixed.patch > > and it can be found in the queue-6.4 subdirectory. > > > > If you, or anyone else, feels it should not be added to the stable tree, > > please let <stable@xxxxxxxxxxxxxxx> know about it. > > > > > > From f96c48670319d685d18d50819ed0c1ef751ed2ac Mon Sep 17 00:00:00 2001 > > From: Suren Baghdasaryan <surenb@xxxxxxxxxx> > > Date: Wed, 5 Jul 2023 18:14:00 -0700 > > Subject: mm: disable CONFIG_PER_VMA_LOCK until its fixed > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > From: Suren Baghdasaryan <surenb@xxxxxxxxxx> > > > > commit f96c48670319d685d18d50819ed0c1ef751ed2ac upstream. > > > > 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 until the fix is confirmed. This is expected to be a > > temporary measure. > > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=217624 > > [2] https://lore.kernel.org/all/20230227173632.3292573-30-surenb@xxxxxxxxxx > > > > Link: https://lkml.kernel.org/r/20230706011400.2949242-3-surenb@xxxxxxxxxx > > Reported-by: Jiri Slaby <jirislaby@xxxxxxxxxx> > > Closes: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf51b@xxxxxxxxxx/ > > Reported-by: Jacob Young <jacobly.alt@xxxxxxxxx> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217624 > > Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first") > > Signed-off-by: Suren Baghdasaryan <surenb@xxxxxxxxxx> > > Cc: David Hildenbrand <david@xxxxxxxxxx> > > Cc: Holger Hoffstätte <holger@xxxxxxxxxxxxxxxxxxxxxx> > > Cc: <stable@xxxxxxxxxxxxxxx> > > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > --- > > mm/Kconfig | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -1198,8 +1198,9 @@ config ARCH_SUPPORTS_PER_VMA_LOCK > > def_bool n > > config PER_VMA_LOCK > > - def_bool y > > + bool "Enable per-vma locking during page fault handling." > > depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP > > + depends on BROKEN > > help > > Allow per-vma locking during page fault handling. > > > > > > Patches currently in stable-queue which might be from surenb@xxxxxxxxxx are > > > > queue-6.4/fork-lock-vmas-of-the-parent-process-when-forking-again.patch > > queue-6.4/mm-lock-a-vma-before-stack-expansion.patch > > queue-6.4/mm-lock-newly-mapped-vma-with-corrected-ordering.patch > > queue-6.4/mm-lock-newly-mapped-vma-which-can-be-modified-after-it-becomes-visible.patch > > queue-6.4/fork-lock-vmas-of-the-parent-process-when-forking.patch > > I am a bit confused now. Why all the fixes when this one (this e-mail): > > > queue-6.4/mm-disable-config_per_vma_lock-until-its-fixed.patch > > is applied too to disable the functionality? > > Note that while 6.5-rc1 indeed contains this _commit_, it does NOT contain > the _change_: > $ git describe --contains f96c48670319d685d18d50819ed0c1ef751ed2ac > v6.5-rc1~11^2~14 > $ git show v6.5-rc1:mm/Kconfig|grep -wA3 PER_VMA_LOCK > config PER_VMA_LOCK > def_bool y > depends on ARCH_SUPPORTS_PER_VMA_LOCK && MMU && SMP > help > > > It was dropped by a merge in commit 946c6b59c. But due to this, there will > be no "revert" of this patch upstream. So essentially, the listed patches > above don't make sense from my POV. (Or this very f96c48670319.) Depends > whether you want CONFIG_PER_VMA_LOCK in 6.4 or not. This has been dropped in -rc2 already, please see https://lore.kernel.org/all/2023070915-preformed-comprised-9d47@gregkh/ thanks for the review! greg k-h
