[PATCH 5.15 000/123] 5.15.196-rc1 review

[PATCH 5.15 000/123] 5.15.196-rc1 review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 5.15.196 release.
There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
or in the git tree and branch at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 5.15.196-rc1

Anup Patel <apatel@ventanamicro.com>
    RISC-V: Don't fail in riscv_of_parent_hartid() for disabled HARTs

Marek Vasut <marek.vasut+renesas@mailbox.org>
    PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()

Zhengchao Shao <shaozhengchao@huawei.com>
    net: rtnetlink: fix module reference count leak issue in rtnetlink_rcv_msg

Kuen-Han Tsai <khtsai@google.com>
    usb: gadget: f_acm: Refactor bind path to use __free()

Kuen-Han Tsai <khtsai@google.com>
    usb: gadget: f_ncm: Refactor bind path to use __free()

Kuen-Han Tsai <khtsai@google.com>
    usb: gadget: Introduce free_usb_request helper

Kuen-Han Tsai <khtsai@google.com>
    usb: gadget: Store endpoint pointer in usb_request

Kaushlendra Kumar <kaushlendra.kumar@intel.com>
    arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()

Darrick J. Wong <djwong@kernel.org>
    xfs: always warn about deprecated mount options

Maarten Lankhorst <dev@lankhorst.se>
    devcoredump: Fix circular locking dependency with devcd->mutex.

Niklas Cassel <cassel@kernel.org>
    PCI: tegra194: Reset BARs when running in PCIe endpoint mode

Marek Vasut <marek.vasut+renesas@mailbox.org>
    PCI: rcar-host: Drop PMSR spinlock

Marek Vasut <marek.vasut+renesas@gmail.com>
    PCI: rcar: Finish transition to L1 state in rcar_pcie_config_access()

Vidya Sagar <vidyas@nvidia.com>
    PCI: tegra194: Handle errors in BPMP response

Jaegeuk Kim <jaegeuk@kernel.org>
    f2fs: fix wrong block mapping for multi-devices

Chuck Lever <chuck.lever@oracle.com>
    NFSD: Define a proc_layoutcommit for the FlexFiles layout type

Jan Kara <jack@suse.cz>
    vfs: Don't leak disconnected dentries on umount

Gui-Dong Han <hanguidong02@gmail.com>
    drm/amdgpu: use atomic functions with memory barriers for vm fault info

Marek Vasut <marek.vasut+renesas@mailbox.org>
    PCI: rcar-host: Convert struct rcar_msi mask_lock into raw spinlock

Muhammad Usama Anjum <usama.anjum@collabora.com>
    wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again

Siddharth Vadapalli <s-vadapalli@ti.com>
    PCI: j721e: Fix programming sequence of "strap" settings

Siddharth Vadapalli <s-vadapalli@ti.com>
    PCI: j721e: Enable ACSPCIE Refclk if "ti,syscon-acspcie-proxy-ctrl" exists

Darrick J. Wong <djwong@kernel.org>
    fuse: fix livelock in synchronous file put from fuseblk workers

Amir Goldstein <amir73il@gmail.com>
    fuse: allocate ff->release_args only if release is needed

Xiao Liang <shaw.leon@gmail.com>
    padata: Reset next CPU when reorder sequence wraps around

Sean Nyekjaer <sean@geanix.com>
    iio: imu: inv_icm42600: Simplify pm_runtime setup

Bence Csókás <csokas.bence@prolan.hu>
    PM: runtime: Add new devm functions

Sean Nyekjaer <sean@geanix.com>
    iio: imu: inv_icm42600: Avoid configuring if already pm_runtime suspended

David Lechner <dlechner@baylibre.com>
    iio: imu: inv_icm42600: use = { } instead of memset()

Sergey Bashirov <sergeybashirov@gmail.com>
    NFSD: Fix last write offset handling in layoutcommit

Sergey Bashirov <sergeybashirov@gmail.com>
    NFSD: Minor cleanup in layoutcommit processing

Sergey Bashirov <sergeybashirov@gmail.com>
    NFSD: Rework encoding and decoding of nfsd4_deviceid

Christoph Hellwig <hch@lst.de>
    xfs: fix log CRC mismatches between i386 and other architectures

Christoph Hellwig <hch@lst.de>
    xfs: rename the old_crc variable in xlog_recover_process

Vineeth Vijayan <vneethv@linux.ibm.com>
    s390/cio: Update purge function to unregister the unused subchannels

Mark Rutland <mark.rutland@arm.com>
    arm64: errata: Apply workarounds for Neoverse-V3AE

Mark Rutland <mark.rutland@arm.com>
    arm64: cputype: Add Neoverse-V3AE definitions

Florian Eckert <fe@dev.tdt.de>
    serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018

Victoria Votokina <Victoria.Votokina@kaspersky.com>
    most: usb: hdm_probe: Fix calling put_device() before device initialization

Victoria Votokina <Victoria.Votokina@kaspersky.com>
    most: usb: Fix use-after-free in hdm_disconnect

Alexander Usyskin <alexander.usyskin@intel.com>
    mei: me: add wildcat lake P DID

Deepanshu Kartikey <kartikey406@gmail.com>
    comedi: fix divide-by-zero in comedi_buf_munge()

Alice Ryhl <aliceryhl@google.com>
    binder: remove "invalid inc weak" check

Mathias Nyman <mathias.nyman@linux.intel.com>
    xhci: dbc: enable back DbC in resume if it was enabled before suspend

Andrey Konovalov <andreyknvl@gmail.com>
    usb: raw-gadget: do not limit transfer length

Tim Guttzeit <t.guttzeit@tuxedocomputers.com>
    usb/core/quirks: Add Huawei ME906S to wakeup quirk

LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn>
    USB: serial: option: add Telit FN920C04 ECM compositions

Reinhard Speyerer <rspmn@arcor.de>
    USB: serial: option: add Quectel RG255C

Renjun Wang <renjunw0@foxmail.com>
    USB: serial: option: add UNISOC UIS7720

Anup Patel <apatel@ventanamicro.com>
    RISC-V: Don't print details of CPUs disabled in DT

Sunil V L <sunilvl@ventanamicro.com>
    riscv: cpu: Add 64bit hartid support on RV64

Tsukasa OI <research_trasio@irq.a4lg.com>
    RISC-V: Minimal parser for "riscv, isa" strings

Tsukasa OI <research_trasio@irq.a4lg.com>
    RISC-V: Correctly print supported extensions

Rob Herring <robh@kernel.org>
    riscv: Use of_get_cpu_hwid()

Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    net: ravb: Ensure memory write completes before ringing TX doorbell

Michal Pecio <michal.pecio@gmail.com>
    net: usb: rtl8150: Fix frame padding

Stefano Garzarella <sgarzare@redhat.com>
    vsock: fix lock inversion in vsock_assign_transport()

Deepanshu Kartikey <kartikey406@gmail.com>
    ocfs2: clear extent cache after moving/defragmenting extents

Maciej W. Rozycki <macro@orcam.me.uk>
    MIPS: Malta: Fix keyboard resource preventing i8042 driver from registering

Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Revert "cpuidle: menu: Avoid discarding useful information"

Tonghao Zhang <tonghao@bamaicloud.com>
    net: bonding: fix possible peer notify event loss or dup issue

Alexey Simakov <bigalex934@gmail.com>
    sctp: avoid NULL dereference when chunk data buffer is missing

Huang Ying <ying.huang@linux.alibaba.com>
    arm64, mm: avoid always making PTE dirty in pte_mkwrite()

Ioana Ciornei <ioana.ciornei@nxp.com>
    dpaa2-eth: fix the pointer passed to PTR_ALIGN on Tx path

Wei Fang <wei.fang@nxp.com>
    net: enetc: correct the value of ENETC_RXB_TRUESIZE

Johannes Wiesböck <johannes.wiesboeck@aisec.fraunhofer.de>
    rtnetlink: Allow deleting FDB entries in user namespace

Nikolay Aleksandrov <razor@blackwall.org>
    net: rtnetlink: add NLM_F_BULK support to rtnl_fdb_del

Nikolay Aleksandrov <razor@blackwall.org>
    net: add ndo_fdb_del_bulk

Nikolay Aleksandrov <razor@blackwall.org>
    net: rtnetlink: add bulk delete support flag

Nikolay Aleksandrov <razor@blackwall.org>
    net: netlink: add NLM_F_BULK delete request modifier

Nikolay Aleksandrov <razor@blackwall.org>
    net: rtnetlink: use BIT for flag values

Nikolay Aleksandrov <razor@blackwall.org>
    net: rtnetlink: add helper to extract msg type's kind

Geert Uytterhoeven <geert@linux-m68k.org>
    m68k: bitops: Fix find_*_bit() signatures

Yangtao Li <frank.li@vivo.com>
    hfsplus: return EIO when type of hidden directory mismatch in hfsplus_fill_super()

Viacheslav Dubeyko <slava@dubeyko.com>
    hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()

Alexander Aring <aahringo@redhat.com>
    dlm: check for defined force value in dlm_lockspace_release

Viacheslav Dubeyko <slava@dubeyko.com>
    hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()

Yang Chenzhi <yang.chenzhi@vivo.com>
    hfs: validate record offset in hfsplus_bmap_alloc

Viacheslav Dubeyko <slava@dubeyko.com>
    hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()

Viacheslav Dubeyko <slava@dubeyko.com>
    hfs: make proper initalization of struct hfs_find_data

Viacheslav Dubeyko <slava@dubeyko.com>
    hfs: clear offset and space out of valid records in b-tree node

Simon Schuster <schuster.simon@siemens-energy.com>
    nios2: ensure that memblock.current_limit is set when setting pfn limits

Xichao Zhao <zhao.xichao@vivo.com>
    exec: Fix incorrect type for ret

Niko Mauno <niko.mauno@vaisala.com>
    Revert "perf test: Don't leak workload gopipe in PERF_RECORD_*"

Brian Norris <briannorris@google.com>
    PCI/sysfs: Ensure devices are powered for config reads (part 2)

Viacheslav Dubeyko <slava@dubeyko.com>
    hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()

Jiaming Zhang <r772577952@gmail.com>
    ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card

Randy Dunlap <rdunlap@infradead.org>
    ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings

Vincent Guittot <vincent.guittot@linaro.org>
    sched/fair: Fix pelt lost idle time detection

Ingo Molnar <mingo@kernel.org>
    sched/balancing: Rename newidle_balance() => sched_balance_newidle()

Timur Kristóf <timur.kristof@gmail.com>
    drm/amd/powerplay: Fix CIK shutdown temperature

Fabian Vogt <fvogt@suse.de>
    riscv: kprobes: Fix probe address validation

I Viswanath <viswanathiyyappan@gmail.com>
    net: usb: lan78xx: fix use of improperly initialized dev->chipid in lan78xx_reset

Oleksij Rempel <linux@rempel-privat.de>
    net: usb: lan78xx: Add error handling to lan78xx_init_mac_address

Jakub Kicinski <kuba@kernel.org>
    net: usb: use eth_hw_addr_set() instead of ether_addr_copy()

Sabrina Dubroca <sd@queasysnail.net>
    tls: don't rely on tx_work during send()

Sabrina Dubroca <sd@queasysnail.net>
    tls: always set record_type in tls_process_cmsg

Sabrina Dubroca <sd@queasysnail.net>
    tls: wait for async encrypt in case of error during latter iterations of sendmsg

Sascha Hauer <s.hauer@pengutronix.de>
    net: tls: wait for async completion on last message

David Howells <dhowells@redhat.com>
    splice, net: Add a splice_eof op to file-ops and socket-ops

Alexey Simakov <bigalex934@gmail.com>
    tg3: prevent use of uninitialized remote_adv and local_adv variables

Eric Dumazet <edumazet@google.com>
    tcp: fix tcp_tso_should_defer() vs large RTT

Raju Rangoju <Raju.Rangoju@amd.com>
    amd-xgbe: Avoid spurious link down messages during interface toggle

Dmitry Safonov <0x7f454c46@gmail.com>
    net/ip6_tunnel: Prevent perpetual tunnel growth

Linmao Li <lilinmao@kylinos.cn>
    r8169: fix packet truncation after S4 resume on RTL8168H/RTL8111H

Nicolas Dichtel <nicolas.dichtel@6wind.com>
    doc: fix seg6_flowlabel path

Yeounsu Moon <yyyynoom@gmail.com>
    net: dlink: handle dma_map_single() failure properly

Marc Kleine-Budde <mkl@pengutronix.de>
    can: m_can: m_can_plat_remove(): add missing pm_runtime_disable()

Yuezhang Mo <Yuezhang.Mo@sony.com>
    dax: skip read lock assertion for read-only filesystems

Benjamin Tissoires <bentiss@kernel.org>
    HID: multitouch: fix sticky fingers

Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    cpufreq: CPPC: Avoid using CPUFREQ_ETERNAL as transition delay

Thomas Fourier <fourier.thomas@gmail.com>
    crypto: rockchip - Fix dma_unmap_sg() nents value

Kaustabh Chakraborty <kauschluss@disroot.org>
    drm/exynos: exynos7_drm_decon: remove ctx->suspended

Kaustabh Chakraborty <kauschluss@disroot.org>
    drm/exynos: exynos7_drm_decon: properly clear channels during bind

Kaustabh Chakraborty <kauschluss@disroot.org>
    drm/exynos: exynos7_drm_decon: fix uninitialized crtc reference in functions

Yu Kuai <yukuai3@huawei.com>
    blk-crypto: fix missing blktrace bio split events

Ma Ke <make24@iscas.ac.cn>
    media: lirc: Fix error handling in lirc_register()

keliu <liuke94@huawei.com>
    media: rc: Directly use ida_free()

Arnd Bergmann <arnd@arndb.de>
    media: s5p-mfc: remove an unused/uninitialized variable

Filipe Manana <fdmanana@suse.com>
    btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation already running

Deepanshu Kartikey <kartikey406@gmail.com>
    ext4: detect invalid INLINE_DATA + EXTENTS flag combination

Zhang Yi <yi.zhang@huawei.com>
    jbd2: ensure that all ongoing I/O complete before freeing blocks

Yi Cong <yicong@kylinos.cn>
    r8152: add error handling in rtl8152_driver_init


-------------

Diffstat:

 Documentation/arm64/silicon-errata.rst             |   2 +
 Documentation/networking/seg6-sysctl.rst           |   3 +
 Makefile                                           |   4 +-
 arch/arm64/Kconfig                                 |   1 +
 arch/arm64/include/asm/cputype.h                   |   2 +
 arch/arm64/include/asm/pgtable.h                   |   3 +-
 arch/arm64/kernel/cpu_errata.c                     |   1 +
 arch/m68k/include/asm/bitops.h                     |  25 ++--
 arch/mips/mti-malta/malta-setup.c                  |   2 +-
 arch/nios2/kernel/setup.c                          |  15 +++
 arch/riscv/include/asm/processor.h                 |   4 +-
 arch/riscv/kernel/cpu.c                            |  28 +++--
 arch/riscv/kernel/cpufeature.c                     |  84 ++++++++++---
 arch/riscv/kernel/probes/kprobes.c                 |  13 +-
 arch/riscv/kernel/smpboot.c                        |   9 +-
 block/blk-crypto-fallback.c                        |   3 +
 drivers/android/binder.c                           |  11 +-
 drivers/base/arch_topology.c                       |   2 +-
 drivers/base/devcoredump.c                         | 138 +++++++++++++--------
 drivers/base/power/runtime.c                       |  44 +++++++
 drivers/clocksource/timer-riscv.c                  |  15 +--
 drivers/comedi/comedi_buf.c                        |   2 +-
 drivers/cpufreq/cppc_cpufreq.c                     |  14 ++-
 drivers/cpuidle/governors/menu.c                   |  21 ++--
 drivers/crypto/rockchip/rk3288_crypto_ahash.c      |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   |   5 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c              |   7 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c              |   7 +-
 .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c    |   3 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c         |  98 +++++----------
 drivers/hid/hid-multitouch.c                       |  27 ++--
 drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c  |   5 +-
 drivers/iio/imu/inv_icm42600/inv_icm42600_core.c   |  35 ++----
 drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c   |   5 +-
 drivers/irqchip/irq-riscv-intc.c                   |   7 +-
 drivers/irqchip/irq-sifive-plic.c                  |   7 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c    |  35 ++----
 drivers/media/rc/lirc_dev.c                        |  15 +--
 drivers/media/rc/rc-main.c                         |   6 +-
 drivers/misc/mei/hw-me-regs.h                      |   2 +
 drivers/misc/mei/pci-me.c                          |   2 +
 drivers/most/most_usb.c                            |  13 +-
 drivers/net/bonding/bond_main.c                    |  40 +++---
 drivers/net/can/m_can/m_can_platform.c             |   2 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c           |   1 -
 drivers/net/ethernet/amd/xgbe/xgbe-mdio.c          |   1 +
 drivers/net/ethernet/broadcom/tg3.c                |   5 +-
 drivers/net/ethernet/dlink/dl2k.c                  |  23 ++--
 drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c   |   3 +-
 drivers/net/ethernet/freescale/enetc/enetc.h       |   2 +-
 drivers/net/ethernet/realtek/r8169_main.c          |   5 +-
 drivers/net/ethernet/renesas/ravb_main.c           |   8 ++
 drivers/net/usb/aqc111.c                           |   2 +-
 drivers/net/usb/lan78xx.c                          |  42 +++++--
 drivers/net/usb/r8152.c                            |   9 +-
 drivers/net/usb/rndis_host.c                       |   2 +-
 drivers/net/usb/rtl8150.c                          |  13 +-
 drivers/net/wireless/ath/ath11k/core.c             |   6 +-
 drivers/net/wireless/ath/ath11k/hal.c              |  16 +++
 drivers/net/wireless/ath/ath11k/hal.h              |   1 +
 drivers/pci/controller/cadence/pci-j721e.c         |  64 +++++++++-
 drivers/pci/controller/dwc/pcie-designware-ep.c    |   1 +
 drivers/pci/controller/dwc/pcie-tegra194.c         |  28 ++++-
 drivers/pci/controller/pcie-rcar-host.c            |  83 +++++++------
 drivers/pci/pci-sysfs.c                            |  10 +-
 drivers/s390/cio/device.c                          |  37 ++++--
 drivers/tty/serial/8250/8250_exar.c                |  11 ++
 drivers/usb/core/quirks.c                          |   2 +
 drivers/usb/gadget/function/f_acm.c                |  42 +++----
 drivers/usb/gadget/function/f_ncm.c                |  78 +++++-------
 drivers/usb/gadget/legacy/raw_gadget.c             |   2 -
 drivers/usb/gadget/udc/core.c                      |   3 +
 drivers/usb/host/xhci-dbgcap.c                     |   9 +-
 drivers/usb/serial/option.c                        |  10 ++
 fs/btrfs/relocation.c                              |  13 +-
 fs/dax.c                                           |   2 +-
 fs/dcache.c                                        |   2 +
 fs/dlm/lockspace.c                                 |   2 +-
 fs/exec.c                                          |   2 +-
 fs/ext4/inode.c                                    |   8 ++
 fs/f2fs/data.c                                     |   2 +-
 fs/fuse/dir.c                                      |   2 +-
 fs/fuse/file.c                                     |  75 ++++++-----
 fs/fuse/fuse_i.h                                   |   2 +-
 fs/hfs/bfind.c                                     |   8 +-
 fs/hfs/brec.c                                      |  27 +++-
 fs/hfs/mdb.c                                       |   2 +-
 fs/hfsplus/bfind.c                                 |   8 +-
 fs/hfsplus/bnode.c                                 |  41 ------
 fs/hfsplus/btree.c                                 |   6 +
 fs/hfsplus/hfsplus_fs.h                            |  42 +++++++
 fs/hfsplus/super.c                                 |  25 +++-
 fs/hfsplus/unicode.c                               |  24 ++++
 fs/jbd2/transaction.c                              |  13 +-
 fs/nfsd/blocklayout.c                              |   5 +-
 fs/nfsd/blocklayoutxdr.c                           |   7 +-
 fs/nfsd/flexfilelayout.c                           |   8 ++
 fs/nfsd/flexfilelayoutxdr.c                        |   3 +-
 fs/nfsd/nfs4layouts.c                              |   1 -
 fs/nfsd/nfs4proc.c                                 |  34 +++--
 fs/nfsd/nfs4xdr.c                                  |  14 +--
 fs/nfsd/xdr4.h                                     |  36 +++++-
 fs/ocfs2/move_extents.c                            |   5 +
 fs/splice.c                                        |  31 ++++-
 fs/xfs/libxfs/xfs_log_format.h                     |  30 ++++-
 fs/xfs/xfs_log.c                                   |   8 +-
 fs/xfs/xfs_log_priv.h                              |   4 +-
 fs/xfs/xfs_log_recover.c                           |  34 +++--
 fs/xfs/xfs_ondisk.h                                |   2 +
 fs/xfs/xfs_super.c                                 |  33 +++--
 include/linux/cpufreq.h                            |   3 +
 include/linux/fs.h                                 |   1 +
 include/linux/net.h                                |   1 +
 include/linux/netdevice.h                          |   9 ++
 include/linux/pm_runtime.h                         |   4 +
 include/linux/splice.h                             |   1 +
 include/linux/usb/gadget.h                         |  25 ++++
 include/net/ip_tunnels.h                           |  15 +++
 include/net/rtnetlink.h                            |   9 +-
 include/net/sock.h                                 |   1 +
 include/uapi/linux/netlink.h                       |   1 +
 kernel/padata.c                                    |   6 +-
 kernel/sched/fair.c                                |  38 +++---
 net/core/rtnetlink.c                               |  81 ++++++++----
 net/ipv4/ip_tunnel.c                               |  14 ---
 net/ipv4/tcp_output.c                              |  19 ++-
 net/ipv6/ip6_tunnel.c                              |   3 +-
 net/sctp/inqueue.c                                 |  13 +-
 net/socket.c                                       |  10 ++
 net/tls/tls_main.c                                 |   7 +-
 net/tls/tls_sw.c                                   |  22 +++-
 net/vmw_vsock/af_vsock.c                           |  38 +++---
 sound/firewire/amdtp-stream.h                      |   2 +-
 sound/usb/card.c                                   |  10 +-
 tools/perf/tests/perf-record.c                     |   4 -
 135 files changed, 1413 insertions(+), 774 deletions(-)

[PATCH 5.15 061/123] arm64, mm: avoid always making PTE dirty in pte_mkwrite()

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Huang Ying <ying.huang@linux.alibaba.com>

[ Upstream commit 143937ca51cc6ae2fccc61a1cb916abb24cd34f5 ]

Current pte_mkwrite_novma() makes PTE dirty unconditionally.  This may
mark some pages that are never written dirty wrongly.  For example,
do_swap_page() may map the exclusive pages with writable and clean PTEs
if the VMA is writable and the page fault is for read access.
However, current pte_mkwrite_novma() implementation always dirties the
PTE.  This may cause unnecessary disk writing if the pages are
never written before being reclaimed.

So, change pte_mkwrite_novma() to clear the PTE_RDONLY bit only if the
PTE_DIRTY bit is set to make it possible to make the PTE writable and
clean.

The current behavior was introduced in commit 73e86cb03cf2 ("arm64:
Move PTE_RDONLY bit handling out of set_pte_at()").  Before that,
pte_mkwrite() only sets the PTE_WRITE bit, while set_pte_at() only
clears the PTE_RDONLY bit if both the PTE_WRITE and the PTE_DIRTY bits
are set.

To test the performance impact of the patch, on an arm64 server
machine, run 16 redis-server processes on socket 1 and 16
memtier_benchmark processes on socket 0 with mostly get
transactions (that is, redis-server will mostly read memory only).
The memory footprint of redis-server is larger than the available
memory, so swap out/in will be triggered.  Test results show that the
patch can avoid most swapping out because the pages are mostly clean.
And the benchmark throughput improves ~23.9% in the test.

Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()")
Signed-off-by: Huang Ying <ying.huang@linux.alibaba.com>
Cc: Will Deacon <will@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Gavin Shan <gshan@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/arm64/include/asm/pgtable.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index a0bfa9cd76dab..a1902dcf7a7e3 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -175,7 +175,8 @@ static inline pmd_t set_pmd_bit(pmd_t pmd, pgprot_t prot)
 static inline pte_t pte_mkwrite(pte_t pte)
 {
 	pte = set_pte_bit(pte, __pgprot(PTE_WRITE));
-	pte = clear_pte_bit(pte, __pgprot(PTE_RDONLY));
+	if (pte_sw_dirty(pte))
+		pte = clear_pte_bit(pte, __pgprot(PTE_RDONLY));
 	return pte;
 }
 
-- 
2.51.0

[PATCH 5.15 114/123] devcoredump: Fix circular locking dependency with devcd->mutex.

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Maarten Lankhorst <dev@lankhorst.se>

[ Upstream commit a91c8096590bd7801a26454789f2992094fe36da ]

The original code causes a circular locking dependency found by lockdep.

======================================================
WARNING: possible circular locking dependency detected
6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S   U
------------------------------------------------------
xe_fault_inject/5091 is trying to acquire lock:
ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660

but task is already holding lock:

ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&devcd->mutex){+.+.}-{3:3}:
       mutex_lock_nested+0x4e/0xc0
       devcd_data_write+0x27/0x90
       sysfs_kf_bin_write+0x80/0xf0
       kernfs_fop_write_iter+0x169/0x220
       vfs_write+0x293/0x560
       ksys_write+0x72/0xf0
       __x64_sys_write+0x19/0x30
       x64_sys_call+0x2bf/0x2660
       do_syscall_64+0x93/0xb60
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (kn->active#236){++++}-{0:0}:
       kernfs_drain+0x1e2/0x200
       __kernfs_remove+0xae/0x400
       kernfs_remove_by_name_ns+0x5d/0xc0
       remove_files+0x54/0x70
       sysfs_remove_group+0x3d/0xa0
       sysfs_remove_groups+0x2e/0x60
       device_remove_attrs+0xc7/0x100
       device_del+0x15d/0x3b0
       devcd_del+0x19/0x30
       process_one_work+0x22b/0x6f0
       worker_thread+0x1e8/0x3d0
       kthread+0x11c/0x250
       ret_from_fork+0x26c/0x2e0
       ret_from_fork_asm+0x1a/0x30
-> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}:
       __lock_acquire+0x1661/0x2860
       lock_acquire+0xc4/0x2f0
       __flush_work+0x27a/0x660
       flush_delayed_work+0x5d/0xa0
       dev_coredump_put+0x63/0xa0
       xe_driver_devcoredump_fini+0x12/0x20 [xe]
       devm_action_release+0x12/0x30
       release_nodes+0x3a/0x120
       devres_release_all+0x8a/0xd0
       device_unbind_cleanup+0x12/0x80
       device_release_driver_internal+0x23a/0x280
       device_driver_detach+0x14/0x20
       unbind_store+0xaf/0xc0
       drv_attr_store+0x21/0x50
       sysfs_kf_write+0x4a/0x80
       kernfs_fop_write_iter+0x169/0x220
       vfs_write+0x293/0x560
       ksys_write+0x72/0xf0
       __x64_sys_write+0x19/0x30
       x64_sys_call+0x2bf/0x2660
       do_syscall_64+0x93/0xb60
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
other info that might help us debug this:
Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex
 Possible unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(&devcd->mutex);
                               lock(kn->active#236);
                               lock(&devcd->mutex);
  lock((work_completion)(&(&devcd->del_wk)->work));
 *** DEADLOCK ***
5 locks held by xe_fault_inject/5091:
 #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0
 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220
 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280
 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0
 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660
stack backtrace:
CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S   U              6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)}
Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021
Call Trace:
 <TASK>
 dump_stack_lvl+0x91/0xf0
 dump_stack+0x10/0x20
 print_circular_bug+0x285/0x360
 check_noncircular+0x135/0x150
 ? register_lock_class+0x48/0x4a0
 __lock_acquire+0x1661/0x2860
 lock_acquire+0xc4/0x2f0
 ? __flush_work+0x25d/0x660
 ? mark_held_locks+0x46/0x90
 ? __flush_work+0x25d/0x660
 __flush_work+0x27a/0x660
 ? __flush_work+0x25d/0x660
 ? trace_hardirqs_on+0x1e/0xd0
 ? __pfx_wq_barrier_func+0x10/0x10
 flush_delayed_work+0x5d/0xa0
 dev_coredump_put+0x63/0xa0
 xe_driver_devcoredump_fini+0x12/0x20 [xe]
 devm_action_release+0x12/0x30
 release_nodes+0x3a/0x120
 devres_release_all+0x8a/0xd0
 device_unbind_cleanup+0x12/0x80
 device_release_driver_internal+0x23a/0x280
 ? bus_find_device+0xa8/0xe0
 device_driver_detach+0x14/0x20
 unbind_store+0xaf/0xc0
 drv_attr_store+0x21/0x50
 sysfs_kf_write+0x4a/0x80
 kernfs_fop_write_iter+0x169/0x220
 vfs_write+0x293/0x560
 ksys_write+0x72/0xf0
 __x64_sys_write+0x19/0x30
 x64_sys_call+0x2bf/0x2660
 do_syscall_64+0x93/0xb60
 ? __f_unlock_pos+0x15/0x20
 ? __x64_sys_getdents64+0x9b/0x130
 ? __pfx_filldir64+0x10/0x10
 ? do_syscall_64+0x1a2/0xb60
 ? clear_bhb_loop+0x30/0x80
 ? clear_bhb_loop+0x30/0x80
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x76e292edd574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574
RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b
RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063
R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000
 </TASK>
xe 0000:03:00.0: [drm] Xe device coredump has been deleted.

Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work")
Cc: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v6.1+
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Cc: Matthew Brost <matthew.brost@intel.com>
Acked-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ replaced disable_delayed_work_sync() with cancel_delayed_work_sync() ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/base/devcoredump.c |  138 +++++++++++++++++++++++++++------------------
 1 file changed, 84 insertions(+), 54 deletions(-)

--- a/drivers/base/devcoredump.c
+++ b/drivers/base/devcoredump.c
@@ -26,50 +26,46 @@ struct devcd_entry {
 	void *data;
 	size_t datalen;
 	/*
-	 * Here, mutex is required to serialize the calls to del_wk work between
-	 * user/kernel space which happens when devcd is added with device_add()
-	 * and that sends uevent to user space. User space reads the uevents,
-	 * and calls to devcd_data_write() which try to modify the work which is
-	 * not even initialized/queued from devcoredump.
+	 * There are 2 races for which mutex is required.
 	 *
+	 * The first race is between device creation and userspace writing to
+	 * schedule immediately destruction.
 	 *
+	 * This race is handled by arming the timer before device creation, but
+	 * when device creation fails the timer still exists.
 	 *
-	 *        cpu0(X)                                 cpu1(Y)
+	 * To solve this, hold the mutex during device_add(), and set
+	 * init_completed on success before releasing the mutex.
 	 *
-	 *        dev_coredump() uevent sent to user space
-	 *        device_add()  ======================> user space process Y reads the
-	 *                                              uevents writes to devcd fd
-	 *                                              which results into writes to
+	 * That way the timer will never fire until device_add() is called,
+	 * it will do nothing if init_completed is not set. The timer is also
+	 * cancelled in that case.
 	 *
-	 *                                             devcd_data_write()
-	 *                                               mod_delayed_work()
-	 *                                                 try_to_grab_pending()
-	 *                                                   del_timer()
-	 *                                                     debug_assert_init()
-	 *       INIT_DELAYED_WORK()
-	 *       schedule_delayed_work()
-	 *
-	 *
-	 * Also, mutex alone would not be enough to avoid scheduling of
-	 * del_wk work after it get flush from a call to devcd_free()
-	 * mentioned as below.
-	 *
-	 *	disabled_store()
-	 *        devcd_free()
-	 *          mutex_lock()             devcd_data_write()
-	 *          flush_delayed_work()
-	 *          mutex_unlock()
-	 *                                   mutex_lock()
-	 *                                   mod_delayed_work()
-	 *                                   mutex_unlock()
-	 * So, delete_work flag is required.
+	 * The second race involves multiple parallel invocations of devcd_free(),
+	 * add a deleted flag so only 1 can call the destructor.
 	 */
 	struct mutex mutex;
-	bool delete_work;
+	bool init_completed, deleted;
 	struct module *owner;
 	ssize_t (*read)(char *buffer, loff_t offset, size_t count,
 			void *data, size_t datalen);
 	void (*free)(void *data);
+	/*
+	 * If nothing interferes and device_add() was returns success,
+	 * del_wk will destroy the device after the timer fires.
+	 *
+	 * Multiple userspace processes can interfere in the working of the timer:
+	 * - Writing to the coredump will reschedule the timer to run immediately,
+	 *   if still armed.
+	 *
+	 *   This is handled by using "if (cancel_delayed_work()) {
+	 *   schedule_delayed_work() }", to prevent re-arming after having
+	 *   been previously fired.
+	 * - Writing to /sys/class/devcoredump/disabled will destroy the
+	 *   coredump synchronously.
+	 *   This is handled by using disable_delayed_work_sync(), and then
+	 *   checking if deleted flag is set with &devcd->mutex held.
+	 */
 	struct delayed_work del_wk;
 	struct device *failing_dev;
 };
@@ -98,14 +94,27 @@ static void devcd_dev_release(struct dev
 	kfree(devcd);
 }
 
+static void __devcd_del(struct devcd_entry *devcd)
+{
+	devcd->deleted = true;
+	device_del(&devcd->devcd_dev);
+	put_device(&devcd->devcd_dev);
+}
+
 static void devcd_del(struct work_struct *wk)
 {
 	struct devcd_entry *devcd;
+	bool init_completed;
 
 	devcd = container_of(wk, struct devcd_entry, del_wk.work);
 
-	device_del(&devcd->devcd_dev);
-	put_device(&devcd->devcd_dev);
+	/* devcd->mutex serializes against dev_coredumpm_timeout */
+	mutex_lock(&devcd->mutex);
+	init_completed = devcd->init_completed;
+	mutex_unlock(&devcd->mutex);
+
+	if (init_completed)
+		__devcd_del(devcd);
 }
 
 static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj,
@@ -125,12 +134,12 @@ static ssize_t devcd_data_write(struct f
 	struct device *dev = kobj_to_dev(kobj);
 	struct devcd_entry *devcd = dev_to_devcd(dev);
 
-	mutex_lock(&devcd->mutex);
-	if (!devcd->delete_work) {
-		devcd->delete_work = true;
-		mod_delayed_work(system_wq, &devcd->del_wk, 0);
-	}
-	mutex_unlock(&devcd->mutex);
+	/*
+	 * Although it's tempting to use mod_delayed work here,
+	 * that will cause a reschedule if the timer already fired.
+	 */
+	if (cancel_delayed_work(&devcd->del_wk))
+		schedule_delayed_work(&devcd->del_wk, 0);
 
 	return count;
 }
@@ -158,11 +167,21 @@ static int devcd_free(struct device *dev
 {
 	struct devcd_entry *devcd = dev_to_devcd(dev);
 
+	/*
+	 * To prevent a race with devcd_data_write(), cancel work and
+	 * complete manually instead.
+	 *
+	 * We cannot rely on the return value of
+	 * cancel_delayed_work_sync() here, because it might be in the
+	 * middle of a cancel_delayed_work + schedule_delayed_work pair.
+	 *
+	 * devcd->mutex here guards against multiple parallel invocations
+	 * of devcd_free().
+	 */
+	cancel_delayed_work_sync(&devcd->del_wk);
 	mutex_lock(&devcd->mutex);
-	if (!devcd->delete_work)
-		devcd->delete_work = true;
-
-	flush_delayed_work(&devcd->del_wk);
+	if (!devcd->deleted)
+		__devcd_del(devcd);
 	mutex_unlock(&devcd->mutex);
 	return 0;
 }
@@ -186,12 +205,10 @@ static ssize_t disabled_show(struct clas
  *                                                                 put_device() <- last reference
  *             error = fn(dev, data)                           devcd_dev_release()
  *             devcd_free(dev, data)                           kfree(devcd)
- *             mutex_lock(&devcd->mutex);
  *
  *
- * In the above diagram, It looks like disabled_store() would be racing with parallely
- * running devcd_del() and result in memory abort while acquiring devcd->mutex which
- * is called after kfree of devcd memory  after dropping its last reference with
+ * In the above diagram, it looks like disabled_store() would be racing with parallelly
+ * running devcd_del() and result in memory abort after dropping its last reference with
  * put_device(). However, this will not happens as fn(dev, data) runs
  * with its own reference to device via klist_node so it is not its last reference.
  * so, above situation would not occur.
@@ -353,7 +370,7 @@ void dev_coredumpm(struct device *dev, s
 	devcd->read = read;
 	devcd->free = free;
 	devcd->failing_dev = get_device(dev);
-	devcd->delete_work = false;
+	devcd->deleted = false;
 
 	mutex_init(&devcd->mutex);
 	device_initialize(&devcd->devcd_dev);
@@ -362,8 +379,14 @@ void dev_coredumpm(struct device *dev, s
 		     atomic_inc_return(&devcd_count));
 	devcd->devcd_dev.class = &devcd_class;
 
-	mutex_lock(&devcd->mutex);
 	dev_set_uevent_suppress(&devcd->devcd_dev, true);
+
+	/* devcd->mutex prevents devcd_del() completing until init finishes */
+	mutex_lock(&devcd->mutex);
+	devcd->init_completed = false;
+	INIT_DELAYED_WORK(&devcd->del_wk, devcd_del);
+	schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT);
+
 	if (device_add(&devcd->devcd_dev))
 		goto put_device;
 
@@ -380,13 +403,20 @@ void dev_coredumpm(struct device *dev, s
 
 	dev_set_uevent_suppress(&devcd->devcd_dev, false);
 	kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD);
-	INIT_DELAYED_WORK(&devcd->del_wk, devcd_del);
-	schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT);
+
+	/*
+	 * Safe to run devcd_del() now that we are done with devcd_dev.
+	 * Alternatively we could have taken a ref on devcd_dev before
+	 * dropping the lock.
+	 */
+	devcd->init_completed = true;
 	mutex_unlock(&devcd->mutex);
 	return;
  put_device:
-	put_device(&devcd->devcd_dev);
 	mutex_unlock(&devcd->mutex);
+	cancel_delayed_work_sync(&devcd->del_wk);
+	put_device(&devcd->devcd_dev);
+
  put_module:
 	module_put(owner);
  free:

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Florian Fainelli]

On 10/27/25 11:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on 
BMIPS_GENERIC:

Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Slade Watkins]

On 10/27/2025 2:34 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +0000.
> Anything received after that time might be too late.

5.15.196-rc1 built and run on x86_64 test system with no errors or 
regressions:
Tested-by: Slade Watkins <sr@sladewatkins.com>

Slade

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Ron Economos]

On 10/27/25 11:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

The RISC-V build fails with:

arch/riscv/kernel/cpu.c: In function 'riscv_of_processor_hartid':
arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function 
'of_get_cpu_hwid'; did you mean 'of_get_cpu_node'? 
[-Werror=implicit-function-declaration]
    24 |         *hart = (unsigned long) of_get_cpu_hwid(node, 0);
       |                                 ^~~~~~~~~~~~~~~
       |                                 of_get_cpu_node
cc1: some warnings being treated as errors

The function of_get_cpu_hwid() doesn't exist in Linux 5.15.x. It was 
introduced in 5.16-rc1. The following patches should be reverted:

87b94f8227b3b654ea6e7670cefb32dab0e570ed RISC-V: Don't fail in 
riscv_of_parent_hartid() for disabled HARTs

568d34c6aafa066bbdb5e7b6aed9c492d81964e8 RISC-V: Don't print details of 
CPUs disabled in DT

And the stable-dep-of patches for the above should also be reverted 
since they cause warnings:

989694ece94da2bbae6c6f3f044994302f923cc8 riscv: cpu: Add 64bit hartid 
support on RV64

8c2544fd913bb7b29ee3af79e0b302036689fe7a RISC-V: Minimal parser for 
"riscv, isa" strings

e0cc917db8fb7b4881ad3e8feb76cefa06f04fe6 RISC-V: Correctly print 
supported extensions

c616540d6b67830bb4345130e8fa3d8e217249a0 iscv: Use of_get_cpu_hwid()

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

Hi!

> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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.

Same problem as 5.10:

arch/riscv/kernel/cpufeature.c: In function 'riscv_fill_hwcap':
2328
arch/riscv/kernel/cpufeature.c:107:16: warning: unused variable 'ext_end' [-Wunused-variable]
2329
  107 |    const char *ext_end = isa;
2330
      |                ^~~~~~~
2331
arch/riscv/kernel/cpu.c: In function 'riscv_of_processor_hartid':
2332
arch/riscv/kernel/cpu.c:24:26: error: implicit declaration of function 'of_get_cpu_hwid'; did you mean 'of_get_cpu_node'? [-Werror=implicit-function-declaration]
2333
   24 |  *hart = (unsigned long) of_get_cpu_hwid(node, 0);
2334
      |                          ^~~~~~~~~~~~~~~
2335
      |                          of_get_cpu_node
2336
  CC      arch/riscv/kernel/ptrace.o
2337
  AR      usr/built-in.a
2338
cc1: some warnings being treated as errors
2339
make[2]: *** [scripts/Makefile.build:289: arch/riscv/kernel/cpu.o] Error 1
2340
make[2]: *** Waiting for unfinished jobs

BR,
							Pavel
-- 
In cooperation with DENX Software Engineering GmbH, HRB 165235 Munich,
Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Greg Kroah-Hartman]

On Mon, Oct 27, 2025 at 09:49:59PM -0700, Ron Economos wrote:
> On 10/27/25 11:34, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.196 release.
> > There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> > or in the git tree and branch at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> The RISC-V build fails with:
> 
> arch/riscv/kernel/cpu.c: In function 'riscv_of_processor_hartid':
> arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function
> 'of_get_cpu_hwid'; did you mean 'of_get_cpu_node'?
> [-Werror=implicit-function-declaration]
>    24 |         *hart = (unsigned long) of_get_cpu_hwid(node, 0);
>       |                                 ^~~~~~~~~~~~~~~
>       |                                 of_get_cpu_node
> cc1: some warnings being treated as errors
> 
> The function of_get_cpu_hwid() doesn't exist in Linux 5.15.x. It was
> introduced in 5.16-rc1. The following patches should be reverted:
> 
> 87b94f8227b3b654ea6e7670cefb32dab0e570ed RISC-V: Don't fail in
> riscv_of_parent_hartid() for disabled HARTs
> 
> 568d34c6aafa066bbdb5e7b6aed9c492d81964e8 RISC-V: Don't print details of CPUs
> disabled in DT
> 
> And the stable-dep-of patches for the above should also be reverted since
> they cause warnings:
> 
> 989694ece94da2bbae6c6f3f044994302f923cc8 riscv: cpu: Add 64bit hartid
> support on RV64
> 
> 8c2544fd913bb7b29ee3af79e0b302036689fe7a RISC-V: Minimal parser for "riscv,
> isa" strings
> 
> e0cc917db8fb7b4881ad3e8feb76cefa06f04fe6 RISC-V: Correctly print supported
> extensions
> 
> c616540d6b67830bb4345130e8fa3d8e217249a0 iscv: Use of_get_cpu_hwid()

Thanks, I'll go drop all of these and push out a -rc2

greg k-h

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Jon Hunter]

On Mon, 27 Oct 2025 19:34:40 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

All tests passing for Tegra ...

Test results for stable-v5.15:
    10 builds:	10 pass, 0 fail
    28 boots:	28 pass, 0 fail
    105 tests:	105 pass, 0 fail

Linux version:	5.15.196-rc1-g01e66f319490
Boards tested:	tegra124-jetson-tk1, tegra186-p2771-0000,
                tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
                tegra194-p3509-0000+p3668-0000, tegra20-ventana,
                tegra210-p2371-2180, tegra210-p3450-0000,
                tegra30-cardhu-a04

Tested-by: Jon Hunter <jonathanh@nvidia.com>

Jon

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Vijayendra Suman]

On 28/10/25 12:04 am, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/ 
> patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

perf failed to compile with following errors at compilation.

BUILDSTDERR: tests/perf-record.c: In function 'test__PERF_RECORD':
BUILDSTDERR: tests/perf-record.c:118:17: error: implicit declaration of 
function 'evlist__cancel_workload'; did you mean 
'evlist__start_workload'? [-Werror=implicit-function-declaration]
BUILDSTDERR:   118 |                 evlist__cancel_workload(evlist);
BUILDSTDERR:       |                 ^~~~~~~~~~~~~~~~~~~~~~~
BUILDSTDERR:       |                 evlist__start_workload


There is no definition for evlist__cancel_workload

Following are references of 'evlist__cancel_workload'
tools/perf/tests/perf-record.c:118:	evlist__cancel_workload(evlist);
tools/perf/tests/perf-record.c:130:	evlist__cancel_workload(evlist);
tools/perf/tests/perf-record.c:142:	evlist__cancel_workload(evlist);
tools/perf/tests/perf-record.c:155:	evlist__cancel_workload(evlist);


Commit which need to be reverted.
b7e5c59f3b09 perf test: Don't leak workload gopipe in PERF_RECORD_*

thanks
Vijay

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Shuah Khan]

On 10/27/25 12:34, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.196 release.
> There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/patch-5.15.196-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <skhan@linuxfoundation.org>

thanks,
-- Shuah

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Greg Kroah-Hartman]

On Tue, Oct 28, 2025 at 09:11:58PM +0530, Vijayendra Suman wrote:
> 
> 
> On 28/10/25 12:04 am, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.196 release.
> > There are 123 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 Wed, 29 Oct 2025 18:34:15 +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/v5.x/stable-review/
> > patch-5.15.196-rc1.gz
> > or in the git tree and branch at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> perf failed to compile with following errors at compilation.
> 
> BUILDSTDERR: tests/perf-record.c: In function 'test__PERF_RECORD':
> BUILDSTDERR: tests/perf-record.c:118:17: error: implicit declaration of
> function 'evlist__cancel_workload'; did you mean 'evlist__start_workload'?
> [-Werror=implicit-function-declaration]
> BUILDSTDERR:   118 |                 evlist__cancel_workload(evlist);
> BUILDSTDERR:       |                 ^~~~~~~~~~~~~~~~~~~~~~~
> BUILDSTDERR:       |                 evlist__start_workload
> 
> 
> There is no definition for evlist__cancel_workload
> 
> Following are references of 'evlist__cancel_workload'
> tools/perf/tests/perf-record.c:118:	evlist__cancel_workload(evlist);
> tools/perf/tests/perf-record.c:130:	evlist__cancel_workload(evlist);
> tools/perf/tests/perf-record.c:142:	evlist__cancel_workload(evlist);
> tools/perf/tests/perf-record.c:155:	evlist__cancel_workload(evlist);
> 
> 
> Commit which need to be reverted.
> b7e5c59f3b09 perf test: Don't leak workload gopipe in PERF_RECORD_*

This is already being reverted in the latest -rc release, does that not
work here for you?

thanks,

greg k-h

Re: [PATCH 5.15 000/123] 5.15.196-rc1 review

[Vijayendra Suman]

Hi Greg,

On 29/10/25 3:50 pm, Greg Kroah-Hartman wrote:
> On Tue, Oct 28, 2025 at 09:11:58PM +0530, Vijayendra Suman wrote:
>>
>>
>> On 28/10/25 12:04 am, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.15.196 release.
>>> There are 123 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 Wed, 29 Oct 2025 18:34:15 +0000.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> 	https://urldefense.com/v3/__https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/__;!!ACWV5N9M2RV99hQ!IVHnCNGPANSvr6y0A-odHf0UE4PdtiY7sjGz2BlRApDAo-XoZrirsziXr5syGOL9x2-s6GjtEsk_yVSVuFc7OkW3YM4C$
>>> patch-5.15.196-rc1.gz
>>> or in the git tree and branch at:
>>> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> perf failed to compile with following errors at compilation.
>>
>> BUILDSTDERR: tests/perf-record.c: In function 'test__PERF_RECORD':
>> BUILDSTDERR: tests/perf-record.c:118:17: error: implicit declaration of
>> function 'evlist__cancel_workload'; did you mean 'evlist__start_workload'?
>> [-Werror=implicit-function-declaration]
>> BUILDSTDERR:   118 |                 evlist__cancel_workload(evlist);
>> BUILDSTDERR:       |                 ^~~~~~~~~~~~~~~~~~~~~~~
>> BUILDSTDERR:       |                 evlist__start_workload
>>
>>
>> There is no definition for evlist__cancel_workload
>>
>> Following are references of 'evlist__cancel_workload'
>> tools/perf/tests/perf-record.c:118:	evlist__cancel_workload(evlist);
>> tools/perf/tests/perf-record.c:130:	evlist__cancel_workload(evlist);
>> tools/perf/tests/perf-record.c:142:	evlist__cancel_workload(evlist);
>> tools/perf/tests/perf-record.c:155:	evlist__cancel_workload(evlist);
>>
>>
>> Commit which need to be reverted.
>> b7e5c59f3b09 perf test: Don't leak workload gopipe in PERF_RECORD_*
> 
> This is already being reverted in the latest -rc release, does that not
> work here for you?

I think saw, this error on v5.15.196-rc1, When I rechecked on 
v5.15.196-rc2, It was fixed as "perf test: Don't leak workload gopipe in 
PERF_RECORD_*" was reverted, had confirmed same on revert of rc2 release.

> 
> thanks,
> 
> greg k-h

thanks,

Vijay