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.gz
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