On Wed, Jul 05, 2023 at 10:22:27AM -0700, Suren Baghdasaryan wrote:
On Wed, Jul 5, 2023 at 10:16 AM David Hildenbrand david@redhat.com wrote:
On 05.07.23 19:12, 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.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=217624 [2] https://lore.kernel.org/all/20230227173632.3292573-30-surenb@google.com
Reported-by: Jiri Slaby jirislaby@kernel.org Closes: https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf51b@kernel.org/ Reported-by: Jacob Young jacobly.alt@gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217624 Fixes: 0bff0aaea03e ("x86/mm: try VMA lock-based page fault handling first") Cc: stable@vger.kernel.org Signed-off-by: Suren Baghdasaryan surenb@google.com
mm/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/Kconfig b/mm/Kconfig index 09130434e30d..0abc6c71dd89 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1224,8 +1224,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.
Do we have any testing results (that don't reveal other issues :) ) for patch #1? Not sure if we really want to mark it broken if patch #1 fixes the issue.
I tested the fix using the only reproducer provided in the reports plus kernel compilation and my fork stress test. All looked good and stable but I don't know if other reports had the same issue or something different.
The commit log seems slightly confusing. It mostly says the bug was still not solved, but I assume patch 1 is the current "fix", it's just not clear whether there's any other potential issues?
According to the stable tree rules:
- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.
I think it means vma lock will never be fixed in 6.4, and it can't (because after this patch it'll be BROKEN, and this patch copies stable, and we can't fix BROKEN things in stables).
Totally no problem I see, just to make sure this is what you wanted..
There'll still try to be a final fix, am I right? As IIRC allowing page faults during fork() is one of the major goals of vma lock.
Thanks,