This is the start of the stable review cycle for the 6.4.1 release. There are 29 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 Sun, 02 Jul 2023 05:56:14 +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-rc2.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-rc2
Linus Torvalds torvalds@linux-foundation.org sparc32: fix lock_mm_and_find_vma() conversion
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 Thu, 29 Jun 2023 at 22:59, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
Linus Torvalds torvalds@linux-foundation.org gup: add warning if some caller would seem to want stack expansion
Did you decide to take that one after all?
It's not exactly wrong, and it might help find any odd cases, but I do suspect you can get syzbot etc to trigger the warning. It's designed to find crazy users, and syzbot is - pretty much by definition and by design - one of the craziest out there.
Linus
On Thu, Jun 29, 2023 at 11:20:45PM -0700, Linus Torvalds wrote:
On Thu, 29 Jun 2023 at 22:59, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
Linus Torvalds torvalds@linux-foundation.org gup: add warning if some caller would seem to want stack expansion
Did you decide to take that one after all?
For now, yes.
It's not exactly wrong, and it might help find any odd cases, but I do suspect you can get syzbot etc to trigger the warning. It's designed to find crazy users, and syzbot is - pretty much by definition and by design - one of the craziest out there.
I think the "crazy users" reports might be triggered sooner with stable updates than from your tree as well, so this might be a early-warning type system. I am pretty sure at least one "distro" has enabled it in their kernel already as well.
But if this starts triggering a bunch of warnings, and they are causing problems, I'll drop it (and recommend you revert it in your tree too.)
I wanted to be "warning compatible" here for now to ensure the backports were working properly.
thanks,
greg k-h
On Thu, 29 Jun 2023 at 23:32, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
I think the "crazy users" reports might be triggered sooner with stable updates than from your tree as well, so this might be a early-warning type system.
Yeah, I agree, it might help find any potential odd cases more quickly.
So just as long as you are aware of the false positives by syzbot and friends..
Linus
linux-stable-mirror@lists.linaro.org