Patch "xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion" has been added to the 6.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion

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:
     xtensa-fix-nommu-build-with-lock_mm_and_find_vma-conversion.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 d85a143b69abb4d7544227e26d12c4c7735ab27d Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 30 Jun 2023 18:24:49 -0700
Subject: xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

commit d85a143b69abb4d7544227e26d12c4c7735ab27d upstream.

It turns out that xtensa has a really odd configuration situation: you
can do a no-MMU config, but still have the page fault code enabled.
Which doesn't sound all that sensible, but it turns out that xtensa can
have protection faults even without the MMU, and we have this:

    config PFAULT
        bool "Handle protection faults" if EXPERT && !MMU
        default y
        help
          Handle protection faults. MMU configurations must enable it.
          noMMU configurations may disable it if used memory map never
          generates protection faults or faults are always fatal.

          If unsure, say Y.

which completely violated my expectations of the page fault handling.

End result: Guenter reports that the xtensa no-MMU builds all fail with

  arch/xtensa/mm/fault.c: In function ‘do_page_fault’:
  arch/xtensa/mm/fault.c:133:8: error: implicit declaration of function ‘lock_mm_and_find_vma’

because I never exposed the new lock_mm_and_find_vma() function for the
no-MMU case.

Doing so is simple enough, and fixes the problem.

Reported-and-tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>
Fixes: a050ba1e7422 ("mm/fault: convert remaining simple cases to lock_mm_and_find_vma()")
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
 include/linux/mm.h |    5 +++--
 mm/nommu.c         |   11 +++++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)

--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2314,6 +2314,9 @@ void pagecache_isize_extended(struct ino
 void truncate_pagecache_range(struct inode *inode, loff_t offset, loff_t end);
 int generic_error_remove_page(struct address_space *mapping, struct page *page);
 
+struct vm_area_struct *lock_mm_and_find_vma(struct mm_struct *mm,
+		unsigned long address, struct pt_regs *regs);
+
 #ifdef CONFIG_MMU
 extern vm_fault_t handle_mm_fault(struct vm_area_struct *vma,
 				  unsigned long address, unsigned int flags,
@@ -2325,8 +2328,6 @@ void unmap_mapping_pages(struct address_
 		pgoff_t start, pgoff_t nr, bool even_cows);
 void unmap_mapping_range(struct address_space *mapping,
 		loff_t const holebegin, loff_t const holelen, int even_cows);
-struct vm_area_struct *lock_mm_and_find_vma(struct mm_struct *mm,
-		unsigned long address, struct pt_regs *regs);
 #else
 static inline vm_fault_t handle_mm_fault(struct vm_area_struct *vma,
 					 unsigned long address, unsigned int flags,
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -631,6 +631,17 @@ struct vm_area_struct *find_vma(struct m
 EXPORT_SYMBOL(find_vma);
 
 /*
+ * At least xtensa ends up having protection faults even with no
+ * MMU.. No stack expansion, at least.
+ */
+struct vm_area_struct *lock_mm_and_find_vma(struct mm_struct *mm,
+			unsigned long addr, struct pt_regs *regs)
+{
+	mmap_read_lock(mm);
+	return vma_lookup(mm, addr);
+}
+
+/*
  * expand a stack to a given address
  * - not supported under NOMMU conditions
  */


Patches currently in stable-queue which might be from torvalds@xxxxxxxxxxxxxxxxxxxx are

queue-6.4/mm-always-expand-the-stack-with-the-mmap-write-lock-held.patch
queue-6.4/xtensa-fix-nommu-build-with-lock_mm_and_find_vma-conversion.patch
queue-6.4/arm-mm-convert-to-using-lock_mm_and_find_vma.patch
queue-6.4/mm-fault-convert-remaining-simple-cases-to-lock_mm_and_find_vma.patch
queue-6.4/sparc32-fix-lock_mm_and_find_vma-conversion.patch
queue-6.4/mm-make-the-page-fault-mmap-locking-killable.patch
queue-6.4/powerpc-mm-convert-to-using-lock_mm_and_find_vma.patch
queue-6.4/mm-khugepaged-fix-regression-in-collapse_file.patch
queue-6.4/powerpc-mm-convert-coprocessor-fault-to-lock_mm_and_find_vma.patch
queue-6.4/gup-add-warning-if-some-caller-would-seem-to-want-stack-expansion.patch
queue-6.4/arm64-mm-convert-to-using-lock_mm_and_find_vma.patch
queue-6.4/mm-introduce-new-lock_mm_and_find_vma-page-fault-helper.patch
queue-6.4/mm-make-find_extend_vma-fail-if-write-lock-not-held.patch
queue-6.4/riscv-mm-convert-to-using-lock_mm_and_find_vma.patch
queue-6.4/execve-expand-new-process-stack-manually-ahead-of-time.patch
queue-6.4/csky-fix-up-lock_mm_and_find_vma-conversion.patch
queue-6.4/mips-mm-convert-to-using-lock_mm_and_find_vma.patch
queue-6.4/parisc-fix-expand_stack-conversion.patch



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux