This is the start of the stable review cycle for the 6.4.1 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 01 Jul 2023 18:41:39 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.4.1-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.4.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 6.4.1-rc1
Ricardo Cañuelo ricardo.canuelo@collabora.com Revert "thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in mtk_thermal_probe"
Mike Hommey mh@glandium.org HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
Ludvig Michaelsson ludvig.michaelsson@yubico.com HID: hidraw: fix data race on device refcount
Zhang Shurong zhang_shurong@foxmail.com fbdev: fix potential OOB read in fast_imageblit()
Hugh Dickins hughd@google.com mm/khugepaged: fix regression in collapse_file()
Linus Torvalds torvalds@linux-foundation.org gup: add warning if some caller would seem to want stack expansion
Jason Gerecke jason.gerecke@wacom.com HID: wacom: Use ktime_t rather than int when dealing with timestamps
Linus Torvalds torvalds@linux-foundation.org mm: always expand the stack with the mmap write lock held
Linus Torvalds torvalds@linux-foundation.org execve: expand new process stack manually ahead of time
Liam R. Howlett Liam.Howlett@oracle.com mm: make find_extend_vma() fail if write lock not held
Linus Torvalds torvalds@linux-foundation.org powerpc/mm: convert coprocessor fault to lock_mm_and_find_vma()
Linus Torvalds torvalds@linux-foundation.org mm/fault: convert remaining simple cases to lock_mm_and_find_vma()
Ben Hutchings ben@decadent.org.uk arm/mm: Convert to using lock_mm_and_find_vma()
Ben Hutchings ben@decadent.org.uk riscv/mm: Convert to using lock_mm_and_find_vma()
Ben Hutchings ben@decadent.org.uk mips/mm: Convert to using lock_mm_and_find_vma()
Michael Ellerman mpe@ellerman.id.au powerpc/mm: Convert to using lock_mm_and_find_vma()
Linus Torvalds torvalds@linux-foundation.org arm64/mm: Convert to using lock_mm_and_find_vma()
Linus Torvalds torvalds@linux-foundation.org mm: make the page fault mmap locking killable
Linus Torvalds torvalds@linux-foundation.org mm: introduce new 'lock_mm_and_find_vma()' page fault helper
Peng Zhang zhangpeng.00@bytedance.com maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()
Oliver Hartkopp socketcan@hartkopp.net can: isotp: isotp_sendmsg(): fix return error fix on TX path
Wyes Karny wyes.karny@amd.com cpufreq: amd-pstate: Make amd-pstate EPP driver name hyphenated
Thomas Gleixner tglx@linutronix.de x86/smp: Cure kexec() vs. mwait_play_dead() breakage
Thomas Gleixner tglx@linutronix.de x86/smp: Use dedicated cache-line for mwait_play_dead()
Thomas Gleixner tglx@linutronix.de x86/smp: Remove pointless wmb()s from native_stop_other_cpus()
Tony Battersby tonyb@cybernetics.com x86/smp: Dont access non-existing CPUID leaf
Thomas Gleixner tglx@linutronix.de x86/smp: Make stop_other_cpus() more robust
Borislav Petkov (AMD) bp@alien8.de x86/microcode/AMD: Load late on both threads too
-------------
Diffstat:
Makefile | 4 +- arch/alpha/Kconfig | 1 + arch/alpha/mm/fault.c | 13 +-- arch/arc/Kconfig | 1 + arch/arc/mm/fault.c | 11 +-- arch/arm/Kconfig | 1 + arch/arm/mm/fault.c | 63 ++++----------- arch/arm64/Kconfig | 1 + arch/arm64/mm/fault.c | 47 ++--------- arch/csky/Kconfig | 1 + arch/csky/mm/fault.c | 22 ++---- arch/hexagon/Kconfig | 1 + arch/hexagon/mm/vm_fault.c | 18 +---- arch/ia64/mm/fault.c | 36 ++------- arch/loongarch/Kconfig | 1 + arch/loongarch/mm/fault.c | 16 ++-- arch/m68k/mm/fault.c | 9 ++- arch/microblaze/mm/fault.c | 5 +- arch/mips/Kconfig | 1 + arch/mips/mm/fault.c | 12 +-- arch/nios2/Kconfig | 1 + arch/nios2/mm/fault.c | 17 +--- arch/openrisc/mm/fault.c | 5 +- arch/parisc/mm/fault.c | 23 +++--- arch/powerpc/Kconfig | 1 + arch/powerpc/mm/copro_fault.c | 14 +--- arch/powerpc/mm/fault.c | 39 +-------- arch/riscv/Kconfig | 1 + arch/riscv/mm/fault.c | 31 +++----- arch/s390/mm/fault.c | 5 +- arch/sh/Kconfig | 1 + arch/sh/mm/fault.c | 17 +--- arch/sparc/Kconfig | 1 + arch/sparc/mm/fault_32.c | 32 ++------ arch/sparc/mm/fault_64.c | 8 +- arch/um/kernel/trap.c | 11 +-- arch/x86/Kconfig | 1 + arch/x86/include/asm/cpu.h | 2 + arch/x86/include/asm/smp.h | 2 + arch/x86/kernel/cpu/microcode/amd.c | 2 +- arch/x86/kernel/process.c | 28 ++++++- arch/x86/kernel/smp.c | 73 ++++++++++------- arch/x86/kernel/smpboot.c | 81 ++++++++++++++++--- arch/x86/mm/fault.c | 52 +----------- arch/xtensa/Kconfig | 1 + arch/xtensa/mm/fault.c | 14 +--- drivers/cpufreq/amd-pstate.c | 2 +- drivers/hid/hid-logitech-hidpp.c | 2 +- drivers/hid/hidraw.c | 9 ++- drivers/hid/wacom_wac.c | 6 +- drivers/hid/wacom_wac.h | 2 +- drivers/iommu/amd/iommu_v2.c | 4 +- drivers/iommu/iommu-sva.c | 2 +- drivers/thermal/mediatek/auxadc_thermal.c | 14 +--- drivers/video/fbdev/core/sysimgblt.c | 2 +- fs/binfmt_elf.c | 6 +- fs/exec.c | 38 +++++---- include/linux/mm.h | 16 ++-- lib/maple_tree.c | 11 +-- mm/Kconfig | 4 + mm/gup.c | 14 +++- mm/khugepaged.c | 7 +- mm/memory.c | 127 ++++++++++++++++++++++++++++++ mm/mmap.c | 121 ++++++++++++++++++++++++---- mm/nommu.c | 17 ++-- net/can/isotp.c | 5 +- 66 files changed, 605 insertions(+), 531 deletions(-)
On Fri, 30 Jun 2023 at 00:18, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.4.1 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 01 Jul 2023 18:41:39 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.4.1-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.4.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm.
Following build regression noticed on Linux stable-rc 6.4 and also noticed on Linux mainline master.
Regressions found on Parisc and Sparc build failed: - build/gcc-11-defconfig
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Parisc Build log: ============= arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP)) | ^~~~ arch/parisc/mm/fault.c:292:22: note: each undeclared identifier is reported only once for each function it appears in
sparc Build log: =========== <stdin>:1519:2: warning: #warning syscall clone3 not implemented [-Wcpp] arch/sparc/mm/fault_32.c: In function 'force_user_fault': arch/sparc/mm/fault_32.c:315:49: error: 'regs' undeclared (first use in this function) 315 | vma = lock_mm_and_find_vma(mm, address, regs); | ^~~~ arch/sparc/mm/fault_32.c:315:49: note: each undeclared identifier is reported only once for each function it appears in
Links: - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29... - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29...
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29... - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29...
Both build failures noticed on mainline and sparc build have been fixed yesterday. - https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.4-8542-g82...
Following patch that got fixed --- From 0b26eadbf200abf6c97c6d870286c73219cdac65 Mon Sep 17 00:00:00 2001 From: Linus Torvalds torvalds@linux-foundation.org Date: Thu, 29 Jun 2023 20:41:24 -0700 Subject: sparc32: fix lock_mm_and_find_vma() conversion
The sparc32 conversion to lock_mm_and_find_vma() in commit a050ba1e7422 ("mm/fault: convert remaining simple cases to lock_mm_and_find_vma()") missed the fact that we didn't actually have a 'regs' pointer available in the 'force_user_fault()' case.
It's there in the regular page fault path ("do_sparc_fault()"), but not the window underflow/overflow paths.
Which is all fine - we can just pass in a NULL pointer. The register state is only used to avoid deadlock with kernel faults, which is not the case for any of these register window faults.
Reported-by: Stephen Rothwell sfr@canb.auug.org.au Fixes: a050ba1e7422 ("mm/fault: convert remaining simple cases to lock_mm_and_find_vma()") Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
-- Linaro LKFT https://lkft.linaro.org
On Fri, Jun 30, 2023 at 11:00:51AM +0530, Naresh Kamboju wrote:
On Fri, 30 Jun 2023 at 00:18, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.4.1 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 01 Jul 2023 18:41:39 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.4.1-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.4.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm.
Following build regression noticed on Linux stable-rc 6.4 and also noticed on Linux mainline master.
Regressions found on Parisc and Sparc build failed:
- build/gcc-11-defconfig
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Parisc Build log:
arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP)) | ^~~~ arch/parisc/mm/fault.c:292:22: note: each undeclared identifier is reported only once for each function it appears in
sparc Build log:
<stdin>:1519:2: warning: #warning syscall clone3 not implemented [-Wcpp] arch/sparc/mm/fault_32.c: In function 'force_user_fault': arch/sparc/mm/fault_32.c:315:49: error: 'regs' undeclared (first use in this function) 315 | vma = lock_mm_and_find_vma(mm, address, regs); | ^~~~ arch/sparc/mm/fault_32.c:315:49: note: each undeclared identifier is reported only once for each function it appears in
Links:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29...
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29...
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29...
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4-29...
Both build failures noticed on mainline and sparc build have been fixed yesterday.
Following patch that got fixed
From 0b26eadbf200abf6c97c6d870286c73219cdac65 Mon Sep 17 00:00:00 2001
From: Linus Torvalds torvalds@linux-foundation.org Date: Thu, 29 Jun 2023 20:41:24 -0700 Subject: sparc32: fix lock_mm_and_find_vma() conversion
The sparc32 conversion to lock_mm_and_find_vma() in commit a050ba1e7422 ("mm/fault: convert remaining simple cases to lock_mm_and_find_vma()") missed the fact that we didn't actually have a 'regs' pointer available in the 'force_user_fault()' case.
It's there in the regular page fault path ("do_sparc_fault()"), but not the window underflow/overflow paths.
Which is all fine - we can just pass in a NULL pointer. The register state is only used to avoid deadlock with kernel faults, which is not the case for any of these register window faults.
Reported-by: Stephen Rothwell sfr@canb.auug.org.au Fixes: a050ba1e7422 ("mm/fault: convert remaining simple cases to lock_mm_and_find_vma()") Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
Thanks! That saves me having to dig. I'll go push out updates with this in them...
greg k-h
On Thu, 29 Jun 2023 at 22:31, Naresh Kamboju naresh.kamboju@linaro.org wrote:
arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP))
Bah. "prev" should be "prev_vma" here.
I've pushed out the fix. Greg, apologies. It's
ea3f8272876f parisc: fix expand_stack() conversion
and Naresh already pointed to the similarly silly sparc32 fix.
Linus
On Thu, Jun 29, 2023 at 11:16:21PM -0700, Linus Torvalds wrote:
On Thu, 29 Jun 2023 at 22:31, Naresh Kamboju naresh.kamboju@linaro.org wrote:
arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP))
Bah. "prev" should be "prev_vma" here.
I've pushed out the fix. Greg, apologies. It's
ea3f8272876f parisc: fix expand_stack() conversion
and Naresh already pointed to the similarly silly sparc32 fix.
Ah, I saw it hit your repo before your email here, sorry about that. Now picked up.
greg k-h
On 6/30/23 08:29, Greg Kroah-Hartman wrote:
On Thu, Jun 29, 2023 at 11:16:21PM -0700, Linus Torvalds wrote:
On Thu, 29 Jun 2023 at 22:31, Naresh Kamboju naresh.kamboju@linaro.org wrote:
arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP))
Bah. "prev" should be "prev_vma" here.
I've pushed out the fix. Greg, apologies. It's
ea3f8272876f parisc: fix expand_stack() conversionand Naresh already pointed to the similarly silly sparc32 fix.
Ah, I saw it hit your repo before your email here, sorry about that. Now picked up.
I've just cherry-picked ea3f8272876f on top of -rc2, built and run-tested it, and everything is OK on parisc.
Thanks! Helge
On 6/29/23 23:16, Linus Torvalds wrote:
On Thu, 29 Jun 2023 at 22:31, Naresh Kamboju naresh.kamboju@linaro.org wrote:
arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP))
Bah. "prev" should be "prev_vma" here.
I've pushed out the fix. Greg, apologies. It's
ea3f8272876f parisc: fix expand_stack() conversionand Naresh already pointed to the similarly silly sparc32 fix.
Linus
Did you see that one (in mainline) ?
Building csky:defconfig ... failed -------------- Error log: arch/csky/mm/fault.c: In function 'do_page_fault': arch/csky/mm/fault.c:240:40: error: 'address' undeclared (first use in this function); did you mean 'addr'? 240 | vma = lock_mm_and_find_vma(mm, address, regs);
Guenter
On 6/29/23 23:29, Guenter Roeck wrote:
On 6/29/23 23:16, Linus Torvalds wrote:
On Thu, 29 Jun 2023 at 22:31, Naresh Kamboju naresh.kamboju@linaro.org wrote:
arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP))
Bah. "prev" should be "prev_vma" here.
I've pushed out the fix. Greg, apologies. It's
ea3f8272876f parisc: fix expand_stack() conversion
and Naresh already pointed to the similarly silly sparc32 fix.
Linus
Did you see that one (in mainline) ?
Building csky:defconfig ... failed
Error log: arch/csky/mm/fault.c: In function 'do_page_fault': arch/csky/mm/fault.c:240:40: error: 'address' undeclared (first use in this function); did you mean 'addr'? 240 | vma = lock_mm_and_find_vma(mm, address, regs);
This is also in {6.1,6.3,6.4}-rc unless I am missing something.
Guenter
On Thu, 29 Jun 2023 at 23:29, Guenter Roeck linux@roeck-us.net wrote:
Did you see that one (in mainline) ?
Building csky:defconfig ... failed
Nope. Thanks. Obvious fix: 'address' is called 'addr' here.
I knew we had all these tiny little mazes that looked the same but were just _subtly_ different, but I still ended up doing too much cut-and-paste.
And I only ended up cross-compiling the fairly small set that I had existing cross-build environments for. Which was less than half our ~24 different architectures.
Oh well. We'll get them all. Eventually. Let me go fix up that csky case.
Linus
On Thu, 29 Jun 2023 at 23:33, Linus Torvalds torvalds@linux-foundation.org wrote:
Oh well. We'll get them all. Eventually. Let me go fix up that csky case.
It's commit e55e5df193d2 ("csky: fix up lock_mm_and_find_vma() conversion").
Let's hope all the problems are these kinds of silly - but obvious - naming differences between different architectures.
Because as long as they cause build errors, they may be embarrassing, but easy to find and notice.
I may not have cared enough about some of these architectures, and it shows. sparc32. parisc. csky...
Linus
On 6/29/23 23:47, Linus Torvalds wrote:
On Thu, 29 Jun 2023 at 23:33, Linus Torvalds torvalds@linux-foundation.org wrote:
Oh well. We'll get them all. Eventually. Let me go fix up that csky case.
It's commit e55e5df193d2 ("csky: fix up lock_mm_and_find_vma() conversion").
Let's hope all the problems are these kinds of silly - but obvious - naming differences between different architectures.
Because as long as they cause build errors, they may be embarrassing, but easy to find and notice.
I may not have cared enough about some of these architectures, and it shows. sparc32. parisc. csky...
There is one more, unfortunately.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... failed ------------ Error log: 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’
This affects all stable release candidates as well as mainline. mmu builds are fine, and indeed lock_mm_and_find_vma() is only declared for CONFIG_MMU. I don't know if this needs a dummy or some other fix for the nommu case.
Guenter
On Fri, 30 Jun 2023 at 15:51, Guenter Roeck linux@roeck-us.net wrote:
There is one more, unfortunately.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... failed
Heh. I didn't even realize that anybody would ever do lock_mm_and_find_vma() code on a nommu platform.
With nommu, handle_mm_fault() will just BUG(), so it's kind of pointless to do any of this at all, and I didn't expect anybody to have this page faulting path that just causes that BUG() for any faults.
But it turns out xtensa has a notion of protection faults even for NOMMU configs:
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 is why it violated my expectations so badly.
I'm not sure if that protection fault handling really ever gets quite this far (it certainly should *not* make it to the BUG() in handle_mm_fault()), but I think the attached patch is likely the right thing to do.
Can you check if it fixes that xtensa case? It looks ObviouslyCorrect(tm) to me, but considering that I clearly missed this case existing AT ALL, it might be best to double-check.
Linus
On Fri, Jun 30, 2023 at 06:24:49PM -0700, Linus Torvalds wrote:
On Fri, 30 Jun 2023 at 15:51, Guenter Roeck linux@roeck-us.net wrote:
There is one more, unfortunately.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... failed
Heh. I didn't even realize that anybody would ever do lock_mm_and_find_vma() code on a nommu platform.
With nommu, handle_mm_fault() will just BUG(), so it's kind of pointless to do any of this at all, and I didn't expect anybody to have this page faulting path that just causes that BUG() for any faults.
But it turns out xtensa has a notion of protection faults even for NOMMU configs:
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 is why it violated my expectations so badly.
I'm not sure if that protection fault handling really ever gets quite this far (it certainly should *not* make it to the BUG() in handle_mm_fault()), but I think the attached patch is likely the right thing to do.
Can you check if it fixes that xtensa case? It looks ObviouslyCorrect(tm) to me, but considering that I clearly missed this case existing AT ALL, it might be best to double-check.
Linus
Yes, the patch below fixes the problem.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... running ......... passed
Thanks, Guenter
include/linux/mm.h | 5 +++-- mm/nommu.c | 11 +++++++++++ 2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h index 39aa409e84d5..4f2c33c273eb 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2323,6 +2323,9 @@ void pagecache_isize_extended(struct inode *inode, loff_t from, loff_t to); 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, @@ -2334,8 +2337,6 @@ void unmap_mapping_pages(struct address_space *mapping, 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, diff --git a/mm/nommu.c b/mm/nommu.c index 37d0b03143f1..fdc392735ec6 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -630,6 +630,17 @@ struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr) } 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
On Fri, 30 Jun 2023 at 19:50, Guenter Roeck linux@roeck-us.net wrote:
Yes, the patch below fixes the problem.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... running ......... passed
Thanks. Committed as
d85a143b69ab ("xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion")
and pushed out.
Linus
On Fri, Jun 30, 2023 at 09:22:45PM -0700, Linus Torvalds wrote:
On Fri, 30 Jun 2023 at 19:50, Guenter Roeck linux@roeck-us.net wrote:
Yes, the patch below fixes the problem.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... running ......... passed
Thanks. Committed as
d85a143b69ab ("xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion")
and pushed out.
Thanks, now queued up.
greg k-h
Hi Linus,
On Fri, Jun 30, 2023 at 9:23 PM Linus Torvalds torvalds@linux-foundation.org wrote:
On Fri, 30 Jun 2023 at 19:50, Guenter Roeck linux@roeck-us.net wrote:
Yes, the patch below fixes the problem.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... running ......... passed
Thanks. Committed as
d85a143b69ab ("xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion")
and pushed out.
Thanks for the build fix. Unfortunately despite being obviously correct it doesn't release the mm lock in case VMA is not found, so it results in a runtime hang. I've posted a fix for that.
On Sat, 1 Jul 2023 at 03:32, Max Filippov jcmvbkbc@gmail.com wrote:
Thanks for the build fix. Unfortunately despite being obviously correct it doesn't release the mm lock in case VMA is not found, so it results in a runtime hang. I've posted a fix for that.
Heh. I woke up this morning to that feeling of "Duh!" about this, and find you already had fixed it. Patch applied.
Linus
On Thu, Jun 29, 2023 at 11:33:45PM -0700, Linus Torvalds wrote:
On Thu, 29 Jun 2023 at 23:29, Guenter Roeck linux@roeck-us.net wrote:
Did you see that one (in mainline) ?
Building csky:defconfig ... failed
Nope. Thanks. Obvious fix: 'address' is called 'addr' here.
I knew we had all these tiny little mazes that looked the same but were just _subtly_ different, but I still ended up doing too much cut-and-paste.
And I only ended up cross-compiling the fairly small set that I had existing cross-build environments for. Which was less than half our ~24 different architectures.
Oh well. We'll get them all. Eventually. Let me go fix up that csky case.
Thanks, I've picked that up now as well.
greg k-h
On Fri, Jun 30, 2023 at 11:00:51AM +0530, Naresh Kamboju wrote:
On Fri, 30 Jun 2023 at 00:18, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 6.4.1 release. There are 28 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 01 Jul 2023 18:41:39 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.4.1-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.4.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm.
Following build regression noticed on Linux stable-rc 6.4 and also noticed on Linux mainline master.
Regressions found on Parisc and Sparc build failed:
- build/gcc-11-defconfig
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Parisc Build log:
arch/parisc/mm/fault.c: In function 'do_page_fault': arch/parisc/mm/fault.c:292:22: error: 'prev' undeclared (first use in this function) 292 | if (!prev || !(prev->vm_flags & VM_GROWSUP)) | ^~~~ arch/parisc/mm/fault.c:292:22: note: each undeclared identifier is reported only once for each function it appears in
This is now fixed in Linus's tree with ea3f8272876f ("parisc: fix expand_stack() conversion"), so I'll queue it up and push out yet-another-rc...
thanks,
greg k-h
-
Greg Kroah-Hartman -
Guenter Roeck -
Helge Deller -
Linus Torvalds -
Max Filippov -
Naresh Kamboju