6.6.115-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainercover 6.6.115-rc1 review
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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/v6.x/stable-review/patch-6.6.115-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-6.6.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 6.6.115-rc1
Haoyu Li <[email protected]>
gpio: ljca: Initialize num before accessing item in ljca_gpio_config
Darrick J. Wong <[email protected]>
fuse: fix livelock in synchronous file put from fuseblk workers
Amir Goldstein <[email protected]>
fuse: allocate ff->release_args only if release is needed
Vineeth Vijayan <[email protected]>
s390/cio: Update purge function to unregister the unused subchannels
Babu Moger <[email protected]>
x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID
Jakub Acs <[email protected]>
fs/notify: call exportfs_encode_fid with s_umount
Darrick J. Wong <[email protected]>
xfs: always warn about deprecated mount options
Maarten Lankhorst <[email protected]>
devcoredump: Fix circular locking dependency with devcd->mutex.
Daniel Golle <[email protected]>
serial: 8250_mtk: Enable baud clock and manage in runtime PM
Florian Eckert <[email protected]>
serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018
Artem Shimko <[email protected]>
serial: 8250_dw: handle reset control deassert error
Xu Yang <[email protected]>
dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp
Michael Grzeschik <[email protected]>
tcpm: switch check for role_sw device with fw_node
Victoria Votokina <[email protected]>
most: usb: hdm_probe: Fix calling put_device() before device initialization
Victoria Votokina <[email protected]>
most: usb: Fix use-after-free in hdm_disconnect
Junhao Xie <[email protected]>
misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup
Alexander Usyskin <[email protected]>
mei: me: add wildcat lake P DID
Deepanshu Kartikey <[email protected]>
comedi: fix divide-by-zero in comedi_buf_munge()
Alice Ryhl <[email protected]>
binder: remove "invalid inc weak" check
Andrew Cooper <[email protected]>
x86/microcode: Fix Entrysign revision check for Zen1/Naples
Mathias Nyman <[email protected]>
xhci: dbc: enable back DbC in resume if it was enabled before suspend
Andrey Konovalov <[email protected]>
usb: raw-gadget: do not limit transfer length
Tim Guttzeit <[email protected]>
usb/core/quirks: Add Huawei ME906S to wakeup quirk
LI Qingwu <[email protected]>
USB: serial: option: add Telit FN920C04 ECM compositions
Reinhard Speyerer <[email protected]>
USB: serial: option: add Quectel RG255C
Renjun Wang <[email protected]>
USB: serial: option: add UNISOC UIS7720
Andy Shevchenko <[email protected]>
sched: Remove never used code in mm_cid_get()
Alok Tiwari <[email protected]>
io_uring: correct __must_hold annotation in io_install_fixed_file
Haotian Zhang <[email protected]>
gpio: ljca: Fix duplicated IRQ mapping
Wentong Wu <[email protected]>
gpio: update Intel LJCA USB GPIO driver
Guenter Roeck <[email protected]>
hwmon: (sht3x) Fix error handling
Anup Patel <[email protected]>
RISC-V: Don't print details of CPUs disabled in DT
Anup Patel <[email protected]>
RISC-V: Define pgprot_dmacoherent() for non-coherent devices
Artem Shimko <[email protected]>
firmware: arm_scmi: Fix premature SCMI_XFER_FLAG_IS_RAW clearing in raw mode
Cristian Marussi <[email protected]>
firmware: arm_scmi: Account for failed debug initialization
Han Xu <[email protected]>
spi: spi-nxp-fspi: add extra delay after dll locked
Matthieu Baerts (NGI0) <[email protected]>
selftests: mptcp: join: mark implicit tests as skipped if not supported
Matthieu Baerts (NGI0) <[email protected]>
selftests: mptcp: join: mark 'flush re-add' as skipped if not supported
Lad Prabhakar <[email protected]>
net: ravb: Ensure memory write completes before ringing TX doorbell
Lad Prabhakar <[email protected]>
net: ravb: Enforce descriptor type ordering
Michal Pecio <[email protected]>
net: usb: rtl8150: Fix frame padding
Sebastian Reichel <[email protected]>
net: stmmac: dwmac-rk: Fix disabling set_clock_selection
Stefano Garzarella <[email protected]>
vsock: fix lock inversion in vsock_assign_transport()
Deepanshu Kartikey <[email protected]>
ocfs2: clear extent cache after moving/defragmenting extents
Maciej W. Rozycki <[email protected]>
MIPS: Malta: Fix keyboard resource preventing i8042 driver from registering
David Howells <[email protected]>
cifs: Fix TCP_Server_Info::credits to be signed
Marc Kleine-Budde <[email protected]>
can: netlink: can_changelink(): allow disabling of automatic restart
Xi Ruoyao <[email protected]>
ACPICA: Work around bogus -Wstringop-overread warning since GCC 11
Rafael J. Wysocki <[email protected]>
Revert "cpuidle: menu: Avoid discarding useful information"
William Breathitt Gray <[email protected]>
gpio: 104-idio-16: Define maximum valid register address offset
William Breathitt Gray <[email protected]>
gpio: pci-idio-16: Define maximum valid register address offset
Kaushlendra Kumar <[email protected]>
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Marek Szyprowski <[email protected]>
dma-debug: don't report false positives with DMA_BOUNCE_UNALIGNED_KMALLOC
Tonghao Zhang <[email protected]>
net: bonding: fix possible peer notify event loss or dup issue
Alexey Simakov <[email protected]>
sctp: avoid NULL dereference when chunk data buffer is missing
Huang Ying <[email protected]>
arm64, mm: avoid always making PTE dirty in pte_mkwrite()
Amery Hung <[email protected]>
net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ
Amery Hung <[email protected]>
net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for legacy RQ
Carolina Jubran <[email protected]>
net/mlx5e: Reuse per-RQ XDP buffer to avoid stack zeroing overhead
Xin Long <[email protected]>
selftests: net: fix server bind failure in sctp_vrf.sh
Hangbin Liu <[email protected]>
selftests/net: convert sctp_vrf.sh to run it in unique namespace
Marc Kleine-Budde <[email protected]>
can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb() instead of can_dropped_invalid_skb()
Ioana Ciornei <[email protected]>
dpaa2-eth: fix the pointer passed to PTR_ALIGN on Tx path
Wei Fang <[email protected]>
net: enetc: correct the value of ENETC_RXB_TRUESIZE
Jianpeng Chang <[email protected]>
net: enetc: fix the deadlock of enetc_mdio_lock
Sebastian Andrzej Siewior <[email protected]>
net: Tree wide: Replace xdp_do_flush_map() with xdp_do_flush().
Johannes Wiesböck <[email protected]>
rtnetlink: Allow deleting FDB entries in user namespace
Nathan Chancellor <[email protected]>
net/mlx5e: Return 1 instead of 0 in invalid case in mlx5e_mpwrq_umr_entry_size()
Linus Torvalds <[email protected]>
Unbreak 'make tools/*' for user-space targets
Stefan Metzmacher <[email protected]>
smb: server: let smb_direct_flush_send_list() invalidate a remote key first
Yicong Yang <[email protected]>
drivers/perf: hisi: Relax the event ID check in the framework
Christophe Leroy <[email protected]>
powerpc/32: Remove PAGE_KERNEL_TEXT to fix startup failure
Geert Uytterhoeven <[email protected]>
m68k: bitops: Fix find_*_bit() signatures
Junjie Cao <[email protected]>
lkdtm: fortify: Fix potential NULL dereference on kmalloc failure
Yangtao Li <[email protected]>
hfsplus: return EIO when type of hidden directory mismatch in hfsplus_fill_super()
Viacheslav Dubeyko <[email protected]>
hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()
Alexander Aring <[email protected]>
dlm: check for defined force value in dlm_lockspace_release
Viacheslav Dubeyko <[email protected]>
hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
Yang Chenzhi <[email protected]>
hfs: validate record offset in hfsplus_bmap_alloc
Viacheslav Dubeyko <[email protected]>
hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()
Viacheslav Dubeyko <[email protected]>
hfs: make proper initalization of struct hfs_find_data
Viacheslav Dubeyko <[email protected]>
hfs: clear offset and space out of valid records in b-tree node
Simon Schuster <[email protected]>
nios2: ensure that memblock.current_limit is set when setting pfn limits
Xichao Zhao <[email protected]>
exec: Fix incorrect type for ret
-------------
Diffstat:
.../devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 10 +- Makefile | 8 +- arch/arm64/include/asm/pgtable.h | 3 +- arch/m68k/include/asm/bitops.h | 25 ++- arch/mips/mti-malta/malta-setup.c | 2 +- arch/nios2/kernel/setup.c | 15 ++ arch/powerpc/include/asm/pgtable.h | 12 - arch/powerpc/mm/book3s32/mmu.c | 4 +- arch/powerpc/mm/pgtable_32.c | 2 +- arch/riscv/include/asm/pgtable.h | 2 + arch/riscv/kernel/cpu.c | 4 +- arch/x86/kernel/cpu/microcode/amd.c | 2 +- arch/x86/kernel/cpu/resctrl/monitor.c | 12 +- drivers/acpi/acpica/tbprint.c | 6 + drivers/android/binder.c | 11 +- drivers/base/arch_topology.c | 2 +- drivers/base/devcoredump.c | 138 +++++++----- drivers/comedi/comedi_buf.c | 2 +- drivers/cpuidle/governors/menu.c | 21 +- drivers/firmware/arm_scmi/common.h | 24 +- drivers/firmware/arm_scmi/driver.c | 47 ++-- drivers/gpio/Kconfig | 4 +- drivers/gpio/gpio-104-idio-16.c | 1 + drivers/gpio/gpio-ljca.c | 248 ++++++++++++--------- drivers/gpio/gpio-pci-idio-16.c | 1 + drivers/hwmon/sht3x.c | 27 ++- drivers/misc/fastrpc.c | 2 + drivers/misc/lkdtm/fortify.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/bxcan.c | 2 +- drivers/net/can/dev/netlink.c | 6 +- drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 +- drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 3 +- drivers/net/ethernet/freescale/enetc/enetc.c | 27 ++- drivers/net/ethernet/freescale/enetc/enetc.h | 2 +- drivers/net/ethernet/freescale/fec_main.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 2 +- drivers/net/ethernet/marvell/mvneta.c | 2 +- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en.h | 7 + .../net/ethernet/mellanox/mlx5/core/en/params.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 6 - drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 128 +++++++---- drivers/net/ethernet/netronome/nfp/nfd3/xsk.c | 2 +- drivers/net/ethernet/renesas/ravb_main.c | 24 +- drivers/net/ethernet/sfc/efx_channels.c | 2 +- drivers/net/ethernet/sfc/siena/efx_channels.c | 2 +- drivers/net/ethernet/socionext/netsec.c | 2 +- drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 9 +- drivers/net/ethernet/ti/cpsw_priv.c | 2 +- drivers/net/usb/rtl8150.c | 11 +- drivers/perf/hisilicon/hisi_uncore_pmu.c | 2 +- drivers/perf/hisilicon/hisi_uncore_pmu.h | 3 +- drivers/s390/cio/device.c | 37 +-- drivers/spi/spi-nxp-fspi.c | 6 + drivers/tty/serial/8250/8250_dw.c | 4 +- drivers/tty/serial/8250/8250_exar.c | 11 + drivers/tty/serial/8250/8250_mtk.c | 6 +- drivers/usb/core/quirks.c | 2 + drivers/usb/gadget/legacy/raw_gadget.c | 2 - drivers/usb/host/xhci-dbgcap.c | 9 +- drivers/usb/serial/option.c | 10 + drivers/usb/typec/tcpm/tcpm.c | 4 +- fs/dlm/lockspace.c | 2 +- fs/exec.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/notify/fdinfo.c | 6 + fs/ocfs2/move_extents.c | 5 + fs/smb/client/cifsglob.h | 2 +- fs/smb/server/transport_rdma.c | 11 +- fs/xfs/xfs_super.c | 33 ++- io_uring/filetable.c | 2 +- kernel/dma/debug.c | 5 +- kernel/sched/sched.h | 2 - net/core/rtnetlink.c | 3 - net/sctp/inqueue.c | 13 +- net/vmw_vsock/af_vsock.c | 38 ++-- tools/testing/selftests/net/mptcp/mptcp_join.sh | 6 +- tools/testing/selftests/net/sctp_hello.c | 17 +- tools/testing/selftests/net/sctp_vrf.sh | 85 ++++--- 98 files changed, 917 insertions(+), 604 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/84 exec: Fix incorrect type for ret
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xichao Zhao <[email protected]>
[ Upstream commit 5e088248375d171b80c643051e77ade6b97bc386 ]
In the setup_arg_pages(), ret is declared as an unsigned long. The ret might take a negative value. Therefore, its type should be changed to int.
--- fs/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/exec.c +1 -1
@@ -748,7 +748,7 @@ int setup_arg_pages(struct linux_binprm *bprm,unsigned long stack_top, int executable_stack) { -unsigned long ret; + int ret;unsigned long stack_shift;struct mm_struct *mm = current->mm;struct vm_area_struct *vma = bprm->vma;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 2/84 nios2: ensure that memblock.current_limit is set when setting pfn limits
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Schuster <[email protected]>
[ Upstream commit a20b83cf45be2057f3d073506779e52c7fa17f94 ]
On nios2, with CONFIG_FLATMEM set, the kernel relies on memblock_get_current_limit() to determine the limits of mem_map, in particular for max_low_pfn.
Unfortunately, memblock.current_limit is only default initialized to MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading to situations where max_low_pfn can erroneously exceed the value of max_pfn and, thus, the valid range of available DRAM.
This can in turn cause kernel-level paging failures, e.g.:
[ 76.900000] Unable to handle kernel paging request at virtual address 20303000 [ 76.900000] ea = c0080890, ra = c000462c, cause = 14 [ 76.900000] Kernel panic - not syncing: Oops [ 76.900000] ---[ end Kernel panic - not syncing: Oops ]---
This patch fixes this by pre-calculating memblock.current_limit based on the upper limits of the available memory ranges via adjust_lowmem_bounds, a simplified version of the equivalent implementation within the arm architecture.
--- arch/nios2/kernel/setup.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
arch/nios2/kernel/setup.c +15 -0
@@ -147,6 +147,20 @@ static void __init find_limits(unsigned long *min, unsigned long *max_low, *max_high =PFN_DOWN (memblock_end_of_DRAM ()); } +static void __init adjust_lowmem_bounds (void ) +{ +phys_addr_t block_start, block_end; +u64 i; +phys_addr_t memblock_limit =0 ; + +for_each_mem_range (i, &block_start, &block_end) { +if (block_end > memblock_limit) + memblock_limit = block_end; + } + +memblock_set_current_limit (memblock_limit); +} +void __init setup_arch (char **cmdline_p) {console_verbose ();
@@ -160,6 +174,7 @@ void __init setup_arch(char **cmdline_p)/* Keep a copy of command line */ *cmdline_p = boot_command_line; +adjust_lowmem_bounds ();find_limits (&min_low_pfn, &max_low_pfn, &max_pfn); max_mapnr = max_low_pfn;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 3/84 hfs: clear offset and space out of valid records in b-tree node
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viacheslav Dubeyko <[email protected]>
[ Upstream commit 18b07c44f245beb03588b00b212b38fce9af7cc9 ]
Currently, hfs_brec_remove() executes moving records towards the location of deleted record and it updates offsets of moved records. However, the hfs_brec_remove() logic ignores the "mess" of b-tree node's free space and it doesn't touch the offsets out of records number. Potentially, it could confuse fsck or driver logic or to be a reason of potential corruption cases.
This patch reworks the logic of hfs_brec_remove() by means of clearing freed space of b-tree node after the records moving. And it clear the last offset that keeping old location of free space because now the offset before this one is keeping the actual offset to the free space after the record deletion.
--- fs/hfs/brec.c | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-)
fs/hfs/brec.c +23 -4
@@ -179,6 +179,7 @@ int hfs_brec_remove(struct hfs_find_data *fd)struct hfs_btree *tree;struct hfs_bnode *node, *parent;int end_off, rec_off, data_off, size; +int src, dst, len; tree = fd->tree; node = fd->bnode;
@@ -208,10 +209,14 @@ int hfs_brec_remove(struct hfs_find_data *fd) }hfs_bnode_write_u16 (node, offsetof(struct hfs_bnode_desc , num_recs), node->num_recs); -if (rec_off == end_off) - goto skip; size = fd->keylength + fd->entrylength; +if (rec_off == end_off) { + src = fd->keyoffset; +hfs_bnode_clear (node, src, size); + goto skip; + } + do { data_off = hfs_bnode_read_u16(node, rec_off); hfs_bnode_write_u16(node, rec_off + 2, data_off - size);
@@ -219,9 +224,23 @@ int hfs_brec_remove(struct hfs_find_data *fd) }while (rec_off >= end_off);/* fill hole */ -hfs_bnode_move (node, fd->keyoffset, fd->keyoffset + size, - data_off - fd->keyoffset - size); + dst = fd->keyoffset; + src = fd->keyoffset + size; + len = data_off - src; + +hfs_bnode_move (node, dst, src, len); + + src = dst + len; + len = data_off - src; + +hfs_bnode_clear (node, src, len); + skip: +/* +* Remove the obsolete offset to free space. +*/ +hfs_bnode_write_u16 (node, end_off,0 ); +hfs_bnode_dump (node);if (!fd->record)hfs_brec_update_parent (fd);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 4/84 hfs: make proper initalization of struct hfs_find_data
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viacheslav Dubeyko <[email protected]>
[ Upstream commit c62663a986acee7c4485c1fa9de5fc40194b6290 ]
Potenatially, __hfs_ext_read_extent() could operate by not initialized values of fd->key after hfs_brec_find() call:
static inline int __hfs_ext_read_extent(struct hfs_find_data *fd, struct hfs_extent *extent,
u32 cnid, u32 block, u8 type)
{
int res;
hfs_ext_build_key(fd->search_key, cnid, block, type);
fd->key->ext.FNum = 0;
res = hfs_brec_find(fd);
if (res && res != -ENOENT)
return res;
if (fd->key->ext.FNum != fd->search_key->ext.FNum ||
fd->key->ext.FkType != fd->search_key->ext.FkType)
return -ENOENT;
if (fd->entrylength != sizeof(hfs_extent_rec))
return -EIO;
hfs_bnode_read(fd->bnode, extent, fd->entryoffset, sizeof(hfs_extent_rec));
return 0;
}This patch changes kmalloc() on kzalloc() in hfs_find_init() and intializes fd->record, fd->keyoffset, fd->keylength, fd->entryoffset, fd->entrylength for the case if hfs_brec_find() has been found nothing in the b-tree node.
--- fs/hfs/bfind.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/hfs/bfind.c +7 -1
@@ -21,7 +21,7 @@ int hfs_find_init(struct hfs_btree *tree, struct hfs_find_data *fd) fd->tree = tree; fd->bnode =NULL ; - ptr =kmalloc (tree->max_key_len *2 +4 ,GFP_KERNEL ); + ptr =kzalloc (tree->max_key_len *2 +4 ,GFP_KERNEL );if (!ptr)return -ENOMEM ; fd->search_key = ptr;
@@ -115,6 +115,12 @@ int hfs_brec_find(struct hfs_find_data *fd)__be32 data;int height, res; + fd->record =-1 ; + fd->keyoffset =-1 ; + fd->keylength =-1 ; + fd->entryoffset =-1 ; + fd->entrylength =-1 ; + tree = fd->tree;if (fd->bnode)hfs_bnode_put (fd->bnode);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 5/84 hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viacheslav Dubeyko <[email protected]>
[ Upstream commit 4840ceadef4290c56cc422f0fc697655f3cbf070 ]
The syzbot reported issue in __hfsplus_ext_cache_extent():
[ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.196959][ T9350] cont_write_begin+0x1000/0x1950 [ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.199393][ T9350] vfs_write+0xb0f/0x14e0 [ 70.199771][ T9350] ksys_write+0x23e/0x490 [ 70.200149][ T9350] __x64_sys_write+0x97/0xf0 [ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.202054][ T9350] [ 70.202279][ T9350] Uninit was created at: [ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80 [ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0 [ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0 [ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.205074][ T9350] cont_write_begin+0x1000/0x1950 [ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.207552][ T9350] vfs_write+0xb0f/0x14e0 [ 70.207961][ T9350] ksys_write+0x23e/0x490 [ 70.208375][ T9350] __x64_sys_write+0x97/0xf0 [ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.210230][ T9350] [ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5 [ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.212115][ T9350] ===================================================== [ 70.212734][ T9350] Disabling lock debugging due to kernel taint [ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ... [ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5 [ 70.214679][ T9350] Tainted: [B]=BAD_PAGE [ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.215999][ T9350] Call Trace: [ 70.216309][ T9350] <TASK> [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0 [ 70.217025][ T9350] dump_stack+0x1e/0x30 [ 70.217421][ T9350] panic+0x502/0xca0 [ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0
[ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel :[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 set ... [ 70.221254][ T9350] ? __msan_warning+0x96/0x120 [ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0 [ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0 [ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0 [ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950 [ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130 [ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060 [ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460 [ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0 [ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0 [ 70.228997][ T9350] ? ksys_write+0x23e/0x490 [ 70.229458][ T9350] ? __x64_sys_write+0x97/0xf0 [ 70.229939][ T9350] ? x64_sys_call+0x3015/0x3cf0 [ 70.230432][ T9350] ? do_syscall_64+0xd9/0x1d0 [ 70.230941][ T9350] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.231926][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.232738][ T9350] ? kmsan_internal_set_shadow_origin+0x77/0x110 [ 70.233711][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.234516][ T9350] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.235398][ T9350] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.236323][ T9350] ? hfsplus_brec_find+0x218/0x9f0 [ 70.237090][ T9350] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 70.237938][ T9350] ? __msan_instrument_asm_store+0xbf/0xf0 [ 70.238827][ T9350] ? __msan_metadata_ptr_for_store_4+0x27/0x40 [ 70.239772][ T9350] ? __hfsplus_ext_write_extent+0x536/0x620 [ 70.240666][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.241175][ T9350] __msan_warning+0x96/0x120 [ 70.241645][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.242223][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.242748][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.243255][ T9350] ? kmsan_internal_set_shadow_origin+0x77/0x110 [ 70.243878][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.244400][ T9350] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.244967][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.245531][ T9350] ? __pfx_hfsplus_get_block+0x10/0x10 [ 70.246079][ T9350] cont_write_begin+0x1000/0x1950 [ 70.246598][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.247105][ T9350] ? __pfx_hfsplus_get_block+0x10/0x10 [ 70.247650][ T9350] ? __pfx_hfsplus_write_begin+0x10/0x10 [ 70.248211][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.248752][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.249314][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.249856][ T9350] ? kmsan_internal_set_shadow_origin+0x77/0x110 [ 70.250487][ T9350] vfs_write+0xb0f/0x14e0 [ 70.250930][ T9350] ? __pfx_generic_file_write_iter+0x10/0x10 [ 70.251530][ T9350] ksys_write+0x23e/0x490 [ 70.251974][ T9350] __x64_sys_write+0x97/0xf0 [ 70.252450][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.252924][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.253384][ T9350] ? irqentry_exit+0x16/0x60 [ 70.253844][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.254430][ T9350] RIP: 0033:0x7f7a92adffc9 [ 70.254873][ T9350] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 70.256674][ T9350] RSP: 002b:00007fff0bca3188 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ 70.257485][ T9350] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7a92adffc9 [ 70.258246][ T9350] RDX: 000000000208e24b RSI: 0000000020000100 RDI: 0000000000000004 [ 70.258998][ T9350] RBP: 00007fff0bca31a0 R08: 00007fff0bca31a0 R09: 00007fff0bca31a0 [ 70.259769][ T9350] R10: 0000000000000000 R11: 0000000000000202 R12: 000055e0d75f8250 [ 70.260520][ T9350] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 70.261286][ T9350] </TASK> [ 70.262026][ T9350] Kernel Offset: disabled
(gdb) l *__hfsplus_ext_cache_extent+0x7d00xffffffff8318aef0 is in __hfsplus_ext_cache_extent (fs/hfsplus/extents.c:168).
163 fd->key->ext.cnid = 0;
164 res = hfs_brec_find(fd, hfs_find_rec_by_key);
165 if (res && res != -ENOENT)
166 return res;
167 if (fd->key->ext.cnid != fd->search_key->ext.cnid ||
168 fd->key->ext.fork_type != fd->search_key->ext.fork_type)
169 return -ENOENT;
170 if (fd->entrylength != sizeof(hfsplus_extent_rec))
171 return -EIO;
172 hfs_bnode_read(fd->bnode, extent, fd->entryoffset,
The __hfsplus_ext_cache_extent() calls __hfsplus_ext_read_extent():
res = __hfsplus_ext_read_extent(fd, hip->cached_extents, inode->i_ino,
block, HFSPLUS_IS_RSRC(inode) ? HFSPLUS_TYPE_RSRC : HFSPLUS_TYPE_DATA);
And if inode->i_ino could be equal to zero or any non-available CNID, then hfs_brec_find() could not find the record in the tree. As a result, fd->key could be compared with fd->search_key. But hfsplus_find_init() uses kmalloc() for fd->key and fd->search_key allocation:
int hfs_find_init(struct hfs_btree *tree, struct hfs_find_data *fd) {
<skipped>
ptr = kmalloc(tree->max_key_len * 2 + 4, GFP_KERNEL);
if (!ptr)
return -ENOMEM;
fd->search_key = ptr;
fd->key = ptr + tree->max_key_len + 2;<skipped>
}
Finally, fd->key is still not initialized if hfs_brec_find() has found nothing.
This patch changes kmalloc() on kzalloc() in hfs_find_init() and intializes fd->record, fd->keyoffset, fd->keylength, fd->entryoffset, fd->entrylength for the case if hfs_brec_find() has been found nothing in the b-tree node.
--- fs/hfsplus/bfind.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/hfsplus/bfind.c +7 -1
@@ -18,7 +18,7 @@ int hfs_find_init(struct hfs_btree *tree, struct hfs_find_data *fd) fd->tree = tree; fd->bnode =NULL ; - ptr =kmalloc (tree->max_key_len *2 +4 ,GFP_KERNEL ); + ptr =kzalloc (tree->max_key_len *2 +4 ,GFP_KERNEL );if (!ptr)return -ENOMEM ; fd->search_key = ptr;
@@ -158,6 +158,12 @@ int hfs_brec_find(struct hfs_find_data *fd, search_strategy_t do_key_compare)__be32 data;int height, res; + fd->record =-1 ; + fd->keyoffset =-1 ; + fd->keylength =-1 ; + fd->entryoffset =-1 ; + fd->entrylength =-1 ; + tree = fd->tree;if (fd->bnode)hfs_bnode_put (fd->bnode);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 6/84 hfs: validate record offset in hfsplus_bmap_alloc
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Chenzhi <[email protected]>
[ Upstream commit 738d5a51864ed8d7a68600b8c0c63fe6fe5c4f20 ]
hfsplus_bmap_alloc can trigger a crash if a
record offset or length is larger than node_size
[ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] <TASK> [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 <f3> 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] </TASK>
When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff
``` len = hfs_brec_lenoff(node, 2, &off16); off = off16; off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap_local_page(*pagep); ```
However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node.
This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions.
--- fs/hfsplus/bnode.c | 41 ---------------------------------------- fs/hfsplus/btree.c | 6 ++++++ fs/hfsplus/hfsplus_fs.h | 42 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 41 deletions(-)
fs/hfsplus/bnode.c +0 -41
@@ -18,47 +18,6 @@#include "hfsplus_fs.h" #include "hfsplus_raw.h" -static inline -bool is_bnode_offset_valid (struct hfs_bnode *node,int off) -{ -bool is_valid = off < node->tree->node_size; - -if (!is_valid) { -pr_err ("requested invalid offset: " -"NODE: id %u, type %#x, height %u, " -"node_size %u, offset %d\n" , - node->this, node->type, node->height, - node->tree->node_size, off); - } - -return is_valid; -} - -static inline -int check_and_correct_requested_length (struct hfs_bnode *node,int off,int len) -{ -unsigned int node_size; - -if (!is_bnode_offset_valid (node, off)) -return 0 ; - - node_size = node->tree->node_size; - -if ((off + len) > node_size) { -int new_len = (int )node_size - off; - -pr_err ("requested length has been corrected: " -"NODE: id %u, type %#x, height %u, " -"node_size %u, offset %d, " -"requested_len %d, corrected_len %d\n" , - node->this, node->type, node->height, - node->tree->node_size, off, len, new_len); - -return new_len; - } - -return len; -}/* Copy a specified range of bytes from the raw data of a node */ void hfs_bnode_read (struct hfs_bnode *node,void *buf,int off,int len)
fs/hfsplus/btree.c +6 -0
@@ -393,6 +393,12 @@ struct hfs_bnode *hfs_bmap_alloc(struct hfs_btree *tree) len =hfs_brec_lenoff (node,2 , &off16); off = off16; +if (!is_bnode_offset_valid (node, off)) { +hfs_bnode_put (node); +return ERR_PTR (-EIO ); + } + len =check_and_correct_requested_length (node, off, len); + off += node->page_offset; pagep = node->page + (off >>PAGE_SHIFT ); data =kmap_local_page (*pagep);
fs/hfsplus/hfsplus_fs.h +42 -0
48 lines not on this page · raw message
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 7/84 hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viacheslav Dubeyko <[email protected]>
[ Upstream commit 9b3d15a758910bb98ba8feb4109d99cc67450ee4 ]
The syzbot reported issue in hfsplus_delete_cat():
[ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Tainted: G B 6.12.0-rc6-dirty #17 [ 70.715007][ T9333] Tainted: [B]=BAD_PAGE [ 70.715365][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.716311][ T9333] Call Trace: [ 70.716621][ T9333] <TASK> [ 70.716899][ T9333] dump_stack_lvl+0x1fd/0x2b0 [ 70.717350][ T9333] dump_stack+0x1e/0x30 [ 70.717743][ T9333] panic+0x502/0xca0 [ 70.718116][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.718611][ T9333] kmsan_report+0x296/0x2a0 [ 70.719038][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.719859][ T9333] ? __msan_warning+0x96/0x120 [ 70.720345][ T9333] ? hfsplus_subfolders_dec+0x1d7/0x220 [ 70.720881][ T9333] ? hfsplus_delete_cat+0x105d/0x12b0 [ 70.721412][ T9333] ? hfsplus_rmdir+0x13d/0x310 [ 70.721880][ T9333] ? vfs_rmdir+0x5ba/0x810 [ 70.722458][ T9333] ? do_rmdir+0x964/0xea0 [ 70.722883][ T9333] ? __x64_sys_rmdir+0x71/0xb0 [ 70.723397][ T9333] ? x64_sys_call+0xcd8/0x3cf0 [ 70.723915][ T9333] ? do_syscall_64+0xd9/0x1d0 [ 70.724454][ T9333] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.725110][ T9333] ? vprintk_emit+0xd1f/0xe60 [ 70.725616][ T9333] ? vprintk_default+0x3f/0x50 [ 70.726175][ T9333] ? vprintk+0xce/0xd0 [ 70.726628][ T9333] ? _printk+0x17e/0x1b0 [ 70.727129][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.727739][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.728324][ T9333] __msan_warning+0x96/0x120 [ 70.728854][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.729479][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.729984][ T9333] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.730646][ T9333] ? __msan_metadata_ptr_for_load_4+0x24/0x40 [ 70.731296][ T9333] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.731863][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.732390][ T9333] ? __pfx_hfsplus_rmdir+0x10/0x10 [ 70.732919][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.733416][ T9333] ? kmsan_get_shadow_origin_ptr+0x4a/0xb0 [ 70.734044][ T9333] do_rmdir+0x964/0xea0 [ 70.734537][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.735032][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.735579][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.736092][ T9333] ? irqentry_exit+0x16/0x60 [ 70.736637][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.737269][ T9333] RIP: 0033:0x7fa9424eafc9 [ 70.737775][ T9333] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 70.739844][ T9333] RSP: 002b:00007fff099cd8d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000054 [ 70.740760][ T9333] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa9424eafc9 [ 70.741642][ T9333] RDX: 006c6f72746e6f63 RSI: 000000000000000a RDI: 0000000020000100 [ 70.742543][ T9333] RBP: 00007fff099cd8e0 R08: 00007fff099cd910 R09: 00007fff099cd910 [ 70.743376][ T9333] R10: 0000000000000000 R11: 0000000000000202 R12: 0000565430642260 [ 70.744247][ T9333] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 70.745082][ T9333] </TASK>
The main reason of the issue that struct hfsplus_inode_info has not been properly initialized for the case of root folder. In the case of root folder, hfsplus_fill_super() calls the hfsplus_iget() that implements only partial initialization of struct hfsplus_inode_info and subfolders field is not initialized by hfsplus_iget() logic.
This patch implements complete initialization of struct hfsplus_inode_info in the hfsplus_iget() logic with the goal to prevent likewise issues for the case of root folder.
--- fs/hfsplus/super.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)
fs/hfsplus/super.c +18 -5
@@ -67,13 +67,26 @@ struct inode *hfsplus_iget(struct super_block *sb, unsigned long ino)if (!(inode->i_state &I_NEW ))return inode; -INIT_LIST_HEAD (&HFSPLUS_I (inode)->open_dir_list); -spin_lock_init (&HFSPLUS_I (inode)->open_dir_lock); -mutex_init (&HFSPLUS_I (inode)->extents_lock); -HFSPLUS_I (inode)->flags =0 ; +atomic_set (&HFSPLUS_I (inode)->opencnt,0 ); +HFSPLUS_I (inode)->first_blocks =0 ; +HFSPLUS_I (inode)->clump_blocks =0 ; +HFSPLUS_I (inode)->alloc_blocks =0 ; +HFSPLUS_I (inode)->cached_start =U32_MAX ; +HFSPLUS_I (inode)->cached_blocks =0 ; +memset (HFSPLUS_I (inode)->first_extents,0 ,sizeof (hfsplus_extent_rec)); +memset (HFSPLUS_I (inode)->cached_extents,0 ,sizeof (hfsplus_extent_rec));HFSPLUS_I (inode)->extent_state =0 ; +mutex_init (&HFSPLUS_I (inode)->extents_lock);HFSPLUS_I (inode)->rsrc_inode =NULL ; -atomic_set (&HFSPLUS_I (inode)->opencnt,0 ); +HFSPLUS_I (inode)->create_date =0 ; +HFSPLUS_I (inode)->linkid =0 ; +HFSPLUS_I (inode)->flags =0 ; +HFSPLUS_I (inode)->fs_blocks =0 ; +HFSPLUS_I (inode)->userflags =0 ; +HFSPLUS_I (inode)->subfolders =0 ; +INIT_LIST_HEAD (&HFSPLUS_I (inode)->open_dir_list); +spin_lock_init (&HFSPLUS_I (inode)->open_dir_lock); +HFSPLUS_I (inode)->phys_size =0 ;if (inode->i_ino >=HFSPLUS_FIRSTUSER_CNID || inode->i_ino ==HFSPLUS_ROOT_CNID ) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 8/84 dlm: check for defined force value in dlm_lockspace_release
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Aring <[email protected]>
[ Upstream commit 6af515c9f3ccec3eb8a262ca86bef2c499d07951 ]
Force values over 3 are undefined, so don't treat them as 3.
--- fs/dlm/lockspace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/dlm/lockspace.c +1 -1
@@ -802,7 +802,7 @@ static int release_lockspace(struct dlm_ls *ls, int force)dlm_device_deregister (ls); -if (force <3 &&dlm_user_daemon_available ()) +if (force !=3 &&dlm_user_daemon_available ())do_uevent (ls,0 );dlm_recoverd_stop (ls);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 9/84 hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Viacheslav Dubeyko <[email protected]>
[ Upstream commit 2048ec5b98dbdfe0b929d2e42dc7a54c389c53dd ]
The syzbot reported issue in hfs_find_set_zero_bits():
=====================================================
BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 =====================================================
The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get():
HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL);
Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine.
But if the allocated memory contains the "garbage", then it can affect the bitmap operations and it triggers the reported issue.
This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and "garbage" in the not initialized memory will be the reason of volume coruptions and file system driver bugs.
--- fs/hfs/mdb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/hfs/mdb.c +1 -1
@@ -172,7 +172,7 @@ int hfs_mdb_get(struct super_block *sb)pr_warn ("continuing without an alternate MDB\n" ); } -HFS_SB (sb)->bitmap =kmalloc (8192 ,GFP_KERNEL ); +HFS_SB (sb)->bitmap =kzalloc (8192 ,GFP_KERNEL );if (!HFS_SB (sb)->bitmap) goto out;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 10/84 hfsplus: return EIO when type of hidden directory mismatch in hfsplus_fill_super()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yangtao Li <[email protected]>
[ Upstream commit 9282bc905f0949fab8cf86c0f620ca988761254c ]
If Catalog File contains corrupted record for the case of hidden directory's type, regard it as I/O error instead of Invalid argument.
--- fs/hfsplus/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/hfsplus/super.c +1 -1
@@ -538,7 +538,7 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent)if (!hfs_brec_read (&fd, &entry,sizeof (entry))) {hfs_find_exit (&fd);if (entry.type !=cpu_to_be16 (HFSPLUS_FOLDER )) { - err = -EINVAL ; + err = -EIO ; goto out_put_root; } inode =hfsplus_iget (sb,be32_to_cpu (entry.folder.id));
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 11/84 lkdtm: fortify: Fix potential NULL dereference on kmalloc failure
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junjie Cao <[email protected]>
[ Upstream commit 01c7344e21c2140e72282d9d16d79a61f840fc20 ]
Add missing NULL pointer checks after kmalloc() calls in lkdtm_FORTIFY_STR_MEMBER() and lkdtm_FORTIFY_MEM_MEMBER() functions.
--- drivers/misc/lkdtm/fortify.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/misc/lkdtm/fortify.c +6 -0
@@ -44,6 +44,9 @@ static void lkdtm_FORTIFY_STR_MEMBER(void)char *src; src =kmalloc (size,GFP_KERNEL ); +if (!src) +return ; +strscpy (src,"over ten bytes" , size); size =strlen (src) +1 ;
@@ -109,6 +112,9 @@ static void lkdtm_FORTIFY_MEM_MEMBER(void)char *src; src =kmalloc (size,GFP_KERNEL ); +if (!src) +return ; +strscpy (src,"over ten bytes" , size); size =strlen (src) +1 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 12/84 m68k: bitops: Fix find_*_bit() signatures
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geert Uytterhoeven <[email protected]>
[ Upstream commit 6d5674090543b89aac0c177d67e5fb32ddc53804 ]
The function signatures of the m68k-optimized implementations of the find_{first,next}_{,zero_}bit() helpers do not match the generic variants.
Fix this by changing all non-pointer inputs and outputs to "unsigned long", and updating a few local variables.
--- arch/m68k/include/asm/bitops.h | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
arch/m68k/include/asm/bitops.h +14 -11
@@ -329,12 +329,12 @@ arch___test_and_change_bit(unsigned long nr, volatile unsigned long *addr)#include <asm-generic/bitops/ffz.h> #else -static inline int find_first_zero_bit (const unsigned long *vaddr, -unsigned size) +static inline unsigned long find_first_zero_bit (const unsigned long *vaddr, +unsigned long size) {const unsigned long *p = vaddr; -int res =32 ; -unsigned int words; +unsigned long res =32 ; +unsigned long words;unsigned long num;if (!size)
@@ -355,8 +355,9 @@ static inline int find_first_zero_bit(const unsigned long *vaddr, }#define find_first_zero_bit find_first_zero_bit -static inline int find_next_zero_bit (const unsigned long *vaddr,int size, -int offset) +static inline unsigned long find_next_zero_bit (const unsigned long *vaddr, +unsigned long size, +unsigned long offset) {const unsigned long *p = vaddr + (offset >>5 );int bit = offset &31UL , res;
@@ -385,11 +386,12 @@ static inline int find_next_zero_bit(const unsigned long *vaddr, int size, }#define find_next_zero_bit find_next_zero_bit -static inline int find_first_bit (const unsigned long *vaddr,unsigned size) +static inline unsigned long find_first_bit (const unsigned long *vaddr, +unsigned long size) {const unsigned long *p = vaddr; -int res =32 ; -unsigned int words; +unsigned long res =32 ; +unsigned long words;unsigned long num;if (!size)
@@ -410,8 +412,9 @@ static inline int find_first_bit(const unsigned long *vaddr, unsigned size) }#define find_first_bit find_first_bit -static inline int find_next_bit (const unsigned long *vaddr,int size, -int offset) +static inline unsigned long find_next_bit (const unsigned long *vaddr, +unsigned long size, +unsigned long offset) {const unsigned long *p = vaddr + (offset >>5 );int bit = offset &31UL , res;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 13/84 powerpc/32: Remove PAGE_KERNEL_TEXT to fix startup failure
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
[ Upstream commit 9316512b717f6f25c4649b3fdb0a905b6a318e9f ]
PAGE_KERNEL_TEXT is an old macro that is used to tell kernel whether kernel text has to be mapped read-only or read-write based on build time options.
But nowadays, with functionnalities like jump_labels, static links, etc ... more only less all kernels need to be read-write at some point, and some combinations of configs failed to work due to innacurate setting of PAGE_KERNEL_TEXT. On the other hand, today we have CONFIG_STRICT_KERNEL_RWX which implements a more controlled access to kernel modifications.
Instead of trying to keep PAGE_KERNEL_TEXT accurate with all possible options that may imply kernel text modification, always set kernel text read-write at startup and rely on CONFIG_STRICT_KERNEL_RWX to provide accurate protection.
Do this by passing PAGE_KERNEL_X to map_kernel_page() in __maping_ram_chunk() instead of passing PAGE_KERNEL_TEXT. Once this is done, the only remaining user of PAGE_KERNEL_TEXT is mmu_mark_initmem_nx() which uses it in a call to setibat(). As setibat() ignores the RW/RO, we can seamlessly replace PAGE_KERNEL_TEXT by PAGE_KERNEL_X here as well and get rid of PAGE_KERNEL_TEXT completely.
--- arch/powerpc/include/asm/pgtable.h | 12 ------------ arch/powerpc/mm/book3s32/mmu.c | 4 ++-- arch/powerpc/mm/pgtable_32.c | 2 +- 3 files changed, 3 insertions(+), 15 deletions(-)
arch/powerpc/include/asm/pgtable.h +0 -12
@@ -20,18 +20,6 @@ struct mm_struct;#include <asm/nohash/pgtable.h> #endif /* !CONFIG_PPC_BOOK3S */ -/* -* Protection used for kernel text. We want the debuggers to be able to -* set breakpoints anywhere, so don't write protect the kernel text -* on platforms where such control is possible. -*/ -#if defined(CONFIG_KGDB ) || defined(CONFIG_XMON ) || defined(CONFIG_BDI_SWITCH ) || \ - defined(CONFIG_KPROBES ) || defined(CONFIG_DYNAMIC_FTRACE ) -#define PAGE_KERNEL_TEXT PAGE_KERNEL_X -#else -#define PAGE_KERNEL_TEXT PAGE_KERNEL_ROX -#endif -/* Make modules code happy. We don't set RO yet */ #define PAGE_KERNEL_EXEC PAGE_KERNEL_X
arch/powerpc/mm/book3s32/mmu.c +2 -2
@@ -204,7 +204,7 @@ void mmu_mark_initmem_nx(void)for (i =0 ; i < nb -1 && base < top;) { size =bat_block_size (base, top); -setibat (i++,PAGE_OFFSET + base, base, size,PAGE_KERNEL_TEXT ); +setibat (i++,PAGE_OFFSET + base, base, size,PAGE_KERNEL_X ); base += size; }if (base < top) {
@@ -215,7 +215,7 @@ void mmu_mark_initmem_nx(void)pr_warn ("Some RW data is getting mapped X. " "Adjust CONFIG_DATA_SHIFT to avoid that.\n" ); } -setibat (i++,PAGE_OFFSET + base, base, size,PAGE_KERNEL_TEXT ); +setibat (i++,PAGE_OFFSET + base, base, size,PAGE_KERNEL_X ); base += size; }for (; i < nb; i++)
arch/powerpc/mm/pgtable_32.c +1 -1
@@ -109,7 +109,7 @@ static void __init __mapin_ram_chunk(unsigned long offset, unsigned long top) p = memstart_addr + s;for (; s < top; s +=PAGE_SIZE ) { ktext =core_kernel_text (v); -map_kernel_page (v, p, ktext ?PAGE_KERNEL_TEXT :PAGE_KERNEL ); +map_kernel_page (v, p, ktext ?PAGE_KERNEL_X :PAGE_KERNEL ); v +=PAGE_SIZE ; p +=PAGE_SIZE ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 14/84 drivers/perf: hisi: Relax the event ID check in the framework
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yicong Yang <[email protected]>
[ Upstream commit 43de0ac332b815cf56dbdce63687de9acfd35d49 ]
Event ID is only using the attr::config bit [7, 0] but we check the event range using the whole 64bit field. It blocks the usage of the rest field of attr::config. Relax the check by only using the bit [7, 0].
--- drivers/perf/hisilicon/hisi_uncore_pmu.c | 2 +- drivers/perf/hisilicon/hisi_uncore_pmu.h | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-)
drivers/perf/hisilicon/hisi_uncore_pmu.c +1 -1
@@ -212,7 +212,7 @@ int hisi_uncore_pmu_event_init(struct perf_event *event)return -EINVAL ; hisi_pmu =to_hisi_pmu (event->pmu); -if (event->attr.config > hisi_pmu->check_event) +if ((event->attr.config &HISI_EVENTID_MASK ) > hisi_pmu->check_event)return -EINVAL ;if (hisi_pmu->on_cpu ==-1 )
drivers/perf/hisilicon/hisi_uncore_pmu.h +2 -1
@@ -43,7 +43,8 @@return FIELD_GET (GENMASK_ULL (hi, lo), event->attr.config); \ } -#define HISI_GET_EVENTID (ev) (ev->hw.config_base & 0xff) +#define HISI_EVENTID_MASK GENMASK(7, 0) +#define HISI_GET_EVENTID (ev) ((ev)->hw.config_base & HISI_EVENTID_MASK)#define HISI_PMU_EVTYPE_BITS 8#define HISI_PMU_EVTYPE_SHIFT (idx) ((idx) % 4 * HISI_PMU_EVTYPE_BITS)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 15/84 smb: server: let smb_direct_flush_send_list() invalidate a remote key first
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <[email protected]>
[ Upstream commit 1b53426334c3c942db47e0959a2527a4f815af50 ]
If we want to invalidate a remote key we should do that as soon as possible, so do it in the first send work request.
--- fs/smb/server/transport_rdma.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
fs/smb/server/transport_rdma.c +7 -4
@@ -938,12 +938,15 @@ static int smb_direct_flush_send_list(struct smb_direct_transport *t, struct smb_direct_sendmsg, list); +if (send_ctx->need_invalidate_rkey) { + first->wr.opcode =IB_WR_SEND_WITH_INV ; + first->wr.ex.invalidate_rkey = send_ctx->remote_key; + send_ctx->need_invalidate_rkey = false; + send_ctx->remote_key =0 ; + } + last->wr.send_flags =IB_SEND_SIGNALED ; last->wr.wr_cqe = &last->cqe; -if (is_last && send_ctx->need_invalidate_rkey) { - last->wr.opcode =IB_WR_SEND_WITH_INV ; - last->wr.ex.invalidate_rkey = send_ctx->remote_key; - } ret =smb_direct_post_send (t, &first->wr);if (!ret) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 16/84 Unbreak make tools/* for user-space targets
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <[email protected]>
[ Upstream commit ee916dccd4df6e2fd19c3606c4735282b72f1473 ]
This pattern isn't very documented, and apparently not used much outside of 'make tools/help', but it has existed for over a decade (since commitea01fa9f63ae: "tools: Connect to the kernel build system").
However, it doesn't work very well for most cases, particularly the useful "tools/all" target, because it overrides the LDFLAGS value with an empty one.
And once overridden, 'make' will then not honor the tooling makefiles trying to change it - which then makes any LDFLAGS use in the tooling directory break, typically causing odd link errors.
Remove that LDFLAGS override, since it seems to be entirely historical. The core kernel makefiles no longer modify LDFLAGS as part of the build, and use kernel-specific link flags instead (eg 'KBUILD_LDFLAGS' and friends).
This allows more of the 'make tools/*' cases to work. I say 'more', because some of the tooling build rules make various other assumptions or have other issues, so it's still a bit hit-or-miss. But those issues tend to show up with the 'make -C tools xyz' pattern too, so now it's no longer an issue of this particular 'tools/*' build rule being special.
--- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Makefile +2 -2
@@ -1358,11 +1358,11 @@ endif tools/: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ + $(Q)$(MAKE) O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ tools/%: FORCE $(Q)mkdir -p $(objtree)/tools - $(Q)$(MAKE) LDFLAGS= O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ $* + $(Q)$(MAKE) O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ $* # --------------------------------------------------------------------------- # Kernel selftest
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 17/84 net/mlx5e: Return 1 instead of 0 in invalid case in mlx5e_mpwrq_umr_entry_size()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
[ Upstream commit aaf043a5688114703ae2c1482b92e7e0754d684e ]
When building with Clang 20 or newer, there are some objtool warnings from unexpected fallthroughs to other functions:
vmlinux.o: warning: objtool: mlx5e_mpwrq_mtts_per_wqe() falls through to next function mlx5e_mpwrq_max_num_entries() vmlinux.o: warning: objtool: mlx5e_mpwrq_max_log_rq_size() falls through to next function mlx5e_get_linear_rq_headroom()
LLVM 20 contains an (admittedly problematic [1]) optimization [2] to convert divide by zero into the equivalent of __builtin_unreachable(), which invokes undefined behavior and destroys code generation when it is encountered in a control flow graph.
mlx5e_mpwrq_umr_entry_size() returns 0 in the default case of an unrecognized mlx5e_mpwrq_umr_mode value. mlx5e_mpwrq_mtts_per_wqe(), which is inlined into mlx5e_mpwrq_max_log_rq_size(), uses the result of mlx5e_mpwrq_umr_entry_size() in a divide operation without checking for zero, so LLVM is able to infer there will be a divide by zero in this case and invokes undefined behavior. While there is some proposed work to isolate this undefined behavior and avoid the destructive code generation that results in these objtool warnings, code should still be defensive against divide by zero.
As the WARN_ONCE() implies that an invalid value should be handled gracefully, return 1 instead of 0 in the default case so that the results of this division operation is always valid.
--- drivers/net/ethernet/mellanox/mlx5/core/en/params.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/en/params.c +1 -1
@@ -98,7 +98,7 @@ u8 mlx5e_mpwrq_umr_entry_size(enum mlx5e_mpwrq_umr_mode mode)return sizeof (struct mlx5_ksm ) *4 ; }WARN_ONCE (1 ,"MPWRQ UMR mode %d is not known\n" , mode); -return 0 ; +return 1 ; } u8 mlx5e_mpwrq_log_wqe_sz(struct mlx5_core_dev *mdev, u8 page_shift,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 18/84 rtnetlink: Allow deleting FDB entries in user namespace
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Wiesböck <[email protected]>
[ Upstream commit bf29555f5bdc017bac22ca66fcb6c9f46ec8788f ]
Creating FDB entries is possible from a non-initial user namespace when having CAP_NET_ADMIN, yet, when deleting FDB entries, processes receive an EPERM because the capability is always checked against the initial user namespace. This restricts the FDB management from unprivileged containers.
Drop the netlink_capable check in rtnl_fdb_del as it was originally dropped in c5c351088ae7 and reintroduced in 1690be63a27b without intention.
This patch was tested using a container on GyroidOS, where it was possible to delete FDB entries from an unprivileged user namespace and private network namespace.
--- net/core/rtnetlink.c | 3 --- 1 file changed, 3 deletions(-)
net/core/rtnetlink.c +0 -3
@@ -4383,9 +4383,6 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh,int err;u16 vid; -if (!netlink_capable (skb,CAP_NET_ADMIN )) -return -EPERM ; -if (!del_bulk) { err =nlmsg_parse_deprecated (nlh,sizeof (*ndm), tb,NDA_MAX ,NULL , extack);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 19/84 net: Tree wide: Replace xdp_do_flush_map() with xdp_do_flush().
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
[ Upstream commit 7f04bd109d4c358a12b125bc79a6f0eac2e915ec ]
xdp_do_flush_map() is deprecated and new code should use xdp_do_flush() instead.
Replace xdp_do_flush_map() with xdp_do_flush().
Stable-dep-of: 50bd33f6b392 ("net: enetc: fix the deadlock of enetc_mdio_lock")
--- drivers/net/ethernet/amazon/ena/ena_netdev.c | 2 +- drivers/net/ethernet/freescale/enetc/enetc.c | 2 +- drivers/net/ethernet/freescale/fec_main.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 2 +- drivers/net/ethernet/marvell/mvneta.c | 2 +- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 2 +- drivers/net/ethernet/netronome/nfp/nfd3/xsk.c | 2 +- drivers/net/ethernet/sfc/efx_channels.c | 2 +- drivers/net/ethernet/sfc/siena/efx_channels.c | 2 +- drivers/net/ethernet/socionext/netsec.c | 2 +- drivers/net/ethernet/ti/cpsw_priv.c | 2 +- 16 files changed, 16 insertions(+), 16 deletions(-)
drivers/net/ethernet/amazon/ena/ena_netdev.c +1 -1
@@ -1310,7 +1310,7 @@ static int ena_clean_rx_irq(struct ena_ring *rx_ring, struct napi_struct *napi, }if (xdp_flags &ENA_XDP_REDIRECT ) -xdp_do_flush_map (); +xdp_do_flush ();return work_done;
drivers/net/ethernet/freescale/enetc/enetc.c +1 -1
@@ -1713,7 +1713,7 @@ static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring, rx_ring->stats.bytes += rx_byte_cnt;if (xdp_redirect_frm_cnt) -xdp_do_flush_map (); +xdp_do_flush ();if (xdp_tx_frm_cnt)enetc_update_tx_ring_tail (tx_ring);
drivers/net/ethernet/freescale/fec_main.c +1 -1
@@ -1904,7 +1904,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id) rxq->bd.cur = bdp;if (xdp_result &FEC_ENET_XDP_REDIR ) -xdp_do_flush_map (); +xdp_do_flush ();return pkt_received; }
drivers/net/ethernet/intel/i40e/i40e_txrx.c +1 -1
@@ -2398,7 +2398,7 @@ void i40e_update_rx_stats(struct i40e_ring *rx_ring,void i40e_finalize_xdp_rx (struct i40e_ring *rx_ring,unsigned int xdp_res) {if (xdp_res &I40E_XDP_REDIR ) -xdp_do_flush_map (); +xdp_do_flush ();if (xdp_res &I40E_XDP_TX ) { struct i40e_ring *xdp_ring =
drivers/net/ethernet/intel/ice/ice_txrx_lib.c +1 -1
@@ -450,7 +450,7 @@ void ice_finalize_xdp_rx(struct ice_tx_ring *xdp_ring, unsigned int xdp_res,struct ice_tx_buf *tx_buf = &xdp_ring->tx_buf[first_idx];if (xdp_res &ICE_XDP_REDIR ) -xdp_do_flush_map (); +xdp_do_flush ();if (xdp_res &ICE_XDP_TX ) {if (static_branch_unlikely (&ice_xdp_locking_key))
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +1 -1
@@ -2421,7 +2421,7 @@ static int ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector, }if (xdp_xmit &IXGBE_XDP_REDIR ) -xdp_do_flush_map (); +xdp_do_flush ();if (xdp_xmit &IXGBE_XDP_TX ) {struct ixgbe_ring *ring =ixgbe_determine_xdp_ring (adapter);
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c +1 -1
@@ -351,7 +351,7 @@ int ixgbe_clean_rx_irq_zc(struct ixgbe_q_vector *q_vector, }if (xdp_xmit &IXGBE_XDP_REDIR ) -xdp_do_flush_map (); +xdp_do_flush ();if (xdp_xmit &IXGBE_XDP_TX ) {struct ixgbe_ring *ring =ixgbe_determine_xdp_ring (adapter);
drivers/net/ethernet/marvell/mvneta.c +1 -1
@@ -2520,7 +2520,7 @@ static int mvneta_rx_swbm(struct napi_struct *napi,mvneta_xdp_put_buff (pp, rxq, &xdp_buf,-1 );if (ps.xdp_redirect) -xdp_do_flush_map (); +xdp_do_flush ();if (ps.rx_packets)mvneta_update_stats (pp, &ps);
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +1 -1
@@ -4055,7 +4055,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi, }if (xdp_ret &MVPP2_XDP_REDIR ) -xdp_do_flush_map (); +xdp_do_flush ();if (ps.rx_packets) {struct mvpp2_pcpu_stats *stats =this_cpu_ptr (port->stats);
drivers/net/ethernet/mediatek/mtk_eth_soc.c +1 -1
@@ -2221,7 +2221,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,net_dim (ð->rx_dim, dim_sample);if (xdp_flush) -xdp_do_flush_map (); +xdp_do_flush ();return done; }
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c +1 -1
@@ -895,7 +895,7 @@ void mlx5e_xdp_rx_poll_complete(struct mlx5e_rq *rq)mlx5e_xmit_xdp_doorbell (xdpsq);if (test_bit (MLX5E_RQ_FLAG_XDP_REDIRECT , rq->flags)) { -xdp_do_flush_map (); +xdp_do_flush ();__clear_bit (MLX5E_RQ_FLAG_XDP_REDIRECT , rq->flags); } }
drivers/net/ethernet/netronome/nfp/nfd3/xsk.c +1 -1
@@ -256,7 +256,7 @@ nfp_nfd3_xsk_rx(struct nfp_net_rx_ring *rx_ring, int budget,nfp_net_xsk_rx_ring_fill_freelist (r_vec->rx_ring);if (xdp_redir) -xdp_do_flush_map (); +xdp_do_flush ();if (tx_ring->wr_ptr_add)nfp_net_tx_xmit_more_flush (tx_ring);
drivers/net/ethernet/sfc/efx_channels.c +1 -1
@@ -1260,7 +1260,7 @@ static int efx_poll(struct napi_struct *napi, int budget) spent =efx_process_channel (channel, budget); -xdp_do_flush_map (); +xdp_do_flush ();if (spent < budget) { if (efx_channel_has_rx_queue(channel) &&
drivers/net/ethernet/sfc/siena/efx_channels.c +1 -1
@@ -1285,7 +1285,7 @@ static int efx_poll(struct napi_struct *napi, int budget) spent =efx_process_channel (channel, budget); -xdp_do_flush_map (); +xdp_do_flush ();if (spent < budget) { if (efx_channel_has_rx_queue(channel) &&
drivers/net/ethernet/socionext/netsec.c +1 -1
@@ -780,7 +780,7 @@ static void netsec_finalize_xdp_rx(struct netsec_priv *priv, u32 xdp_res, u16 pkts) {if (xdp_res &NETSEC_XDP_REDIR ) -xdp_do_flush_map (); +xdp_do_flush ();if (xdp_res &NETSEC_XDP_TX )netsec_xdp_ring_tx_db (priv, pkts);
drivers/net/ethernet/ti/cpsw_priv.c +1 -1
@@ -1360,7 +1360,7 @@ int cpsw_run_xdp(struct cpsw_priv *priv, int ch, struct xdp_buff *xdp,* particular hardware is sharing a common queue, so the * incoming device might change per packet. */ -xdp_do_flush_map (); +xdp_do_flush ();break ;default :bpf_warn_invalid_xdp_action (ndev, prog, act);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 20/84 net: enetc: fix the deadlock of enetc_mdio_lock
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jianpeng Chang <[email protected]>
[ Upstream commit 50bd33f6b3922a6b760aa30d409cae891cec8fb5 ]
After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock:
enetc_poll
-> enetc_lock_mdio
-> enetc_clean_rx_ring OR napi_complete_done
-> napi_gro_receive
-> enetc_start_xmit
-> enetc_lock_mdio
-> enetc_map_tx_buffs
-> enetc_unlock_mdio -> enetc_unlock_mdio
After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang.
Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition.
--- drivers/net/ethernet/freescale/enetc/enetc.c | 25 ++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc.c +21 -4
@@ -1246,6 +1246,8 @@ static int enetc_clean_rx_ring(struct enetc_bdr *rx_ring,/* next descriptor to process */ i = rx_ring->next_to_clean; +enetc_lock_mdio (); +while (likely (rx_frm_cnt < work_limit)) {union enetc_rx_bd *rxbd;struct sk_buff *skb;
@@ -1281,7 +1283,9 @@ static int enetc_clean_rx_ring(struct enetc_bdr *rx_ring, rx_byte_cnt += skb->len +ETH_HLEN ; rx_frm_cnt++; +enetc_unlock_mdio ();napi_gro_receive (napi, skb); +enetc_lock_mdio (); } rx_ring->next_to_clean = i;
@@ -1289,6 +1293,8 @@ static int enetc_clean_rx_ring(struct enetc_bdr *rx_ring, rx_ring->stats.packets += rx_frm_cnt; rx_ring->stats.bytes += rx_byte_cnt; +enetc_unlock_mdio (); +return rx_frm_cnt; }
@@ -1598,6 +1604,8 @@ static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring,/* next descriptor to process */ i = rx_ring->next_to_clean; +enetc_lock_mdio (); +while (likely (rx_frm_cnt < work_limit)) {union enetc_rx_bd *rxbd, *orig_rxbd;int orig_i, orig_cleaned_cnt;
@@ -1657,7 +1665,9 @@ static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring,if (unlikely (!skb)) goto out; +enetc_unlock_mdio ();napi_gro_receive (napi, skb); +enetc_lock_mdio ();break ;case XDP_TX : tx_ring = priv->xdp_tx_ring[rx_ring->index];
@@ -1692,7 +1702,9 @@ static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring, }break ;case XDP_REDIRECT : +enetc_unlock_mdio (); err =xdp_do_redirect (rx_ring->ndev, &xdp_buff, prog); +enetc_lock_mdio ();if (unlikely (err)) {enetc_xdp_drop (rx_ring, orig_i, i); rx_ring->stats.xdp_redirect_failures++;
@@ -1712,8 +1724,11 @@ static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring, rx_ring->stats.packets += rx_frm_cnt; rx_ring->stats.bytes += rx_byte_cnt; -if (xdp_redirect_frm_cnt) +if (xdp_redirect_frm_cnt) { +enetc_unlock_mdio ();xdp_do_flush (); +enetc_lock_mdio (); + }if (xdp_tx_frm_cnt)enetc_update_tx_ring_tail (tx_ring);
@@ -1722,6 +1737,8 @@ static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring,enetc_refill_rx_ring (rx_ring,enetc_bd_unused (rx_ring) - rx_ring->xdp.xdp_tx_in_flight); +enetc_unlock_mdio (); +return rx_frm_cnt; }
@@ -1740,6 +1757,7 @@ static int enetc_poll(struct napi_struct *napi, int budget)for (i =0 ; i < v->count_tx_rings; i++)if (!enetc_clean_tx_ring (&v->tx_ring[i], budget)) complete = false; +enetc_unlock_mdio (); prog = rx_ring->xdp.prog;if (prog)
@@ -1751,10 +1769,8 @@ static int enetc_poll(struct napi_struct *napi, int budget)if (work_done) v->rx_napi_work = true; -if (!complete) { -enetc_unlock_mdio (); +if (!complete)return budget; - }napi_complete_done (napi, work_done);
@@ -1763,6 +1779,7 @@ static int enetc_poll(struct napi_struct *napi, int budget) v->rx_napi_work = false; +enetc_lock_mdio ();/* enable interrupts */ enetc_wr_reg_hot (v->rbier,ENETC_RBIER_RXTIE );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 21/84 net: enetc: correct the value of ENETC_RXB_TRUESIZE
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Fang <[email protected]>
[ Upstream commit e59bc32df2e989f034623a580e30a2a72af33b3f ]
The ENETC RX ring uses the page halves flipping mechanism, each page is split into two halves for the RX ring to use. And ENETC_RXB_TRUESIZE is defined to 2048 to indicate the size of half a page. However, the page size is configurable, for ARM64 platform, PAGE_SIZE is default to 4K, but it could be configured to 16K or 64K.
When PAGE_SIZE is set to 16K or 64K, ENETC_RXB_TRUESIZE is not correct, and the RX ring will always use the first half of the page. This is not consistent with the description in the relevant kernel doc and commit messages.
This issue is invisible in most cases, but if users want to increase PAGE_SIZE to receive a Jumbo frame with a single buffer for some use cases, it will not work as expected, because the buffer size of each RX BD is fixed to 2048 bytes.
Based on the above two points, we expect to correct ENETC_RXB_TRUESIZE to (PAGE_SIZE >> 1), as described in the comment.
--- drivers/net/ethernet/freescale/enetc/enetc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/freescale/enetc/enetc.h +1 -1
@@ -41,7 +41,7 @@ struct enetc_tx_swbd { };#define ENETC_RX_MAXFRM_SIZE ENETC_MAC_MAXFRM_SIZE -#define ENETC_RXB_TRUESIZE 2048/* PAGE_SIZE >> 1 */ +#define ENETC_RXB_TRUESIZE (PAGE_SIZE >> 1)#define ENETC_RXB_PAD NET_SKB_PAD/* add extra space if needed */ #define ENETC_RXB_DMA_SIZE \ (SKB_WITH_OVERHEAD(ENETC_RXB_TRUESIZE) - ENETC_RXB_PAD)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 22/84 dpaa2-eth: fix the pointer passed to PTR_ALIGN on Tx path
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ioana Ciornei <[email protected]>
[ Upstream commit 902e81e679d86846a2404630d349709ad9372d0d ]
The blamed commit increased the needed headroom to account for alignment. This means that the size required to always align a Tx buffer was added inside the dpaa2_eth_needed_headroom() function. By doing that, a manual adjustment of the pointer passed to PTR_ALIGN() was no longer correct since the 'buffer_start' variable was already pointing to the start of the skb's memory.
The behavior of the dpaa2-eth driver without this patch was to drop frames on Tx even when the headroom was matching the 128 bytes necessary. Fix this by removing the manual adjust of 'buffer_start' from the PTR_MODE call.
--- drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +1 -2
@@ -1077,8 +1077,7 @@ static int dpaa2_eth_build_single_fd(struct dpaa2_eth_priv *priv,dma_addr_t addr; buffer_start = skb->data -dpaa2_eth_needed_headroom (skb); - aligned_start =PTR_ALIGN (buffer_start -DPAA2_ETH_TX_BUF_ALIGN , -DPAA2_ETH_TX_BUF_ALIGN ); + aligned_start =PTR_ALIGN (buffer_start,DPAA2_ETH_TX_BUF_ALIGN );if (aligned_start >= skb->head) buffer_start = aligned_start;else
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 23/84 can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb() instead of can_dropped_invalid_skb()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Kleine-Budde <[email protected]>
[ Upstream commit 3a20c444cd123e820e10ae22eeaf00e189315aa1 ]
In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly.
Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode.
--- drivers/net/can/bxcan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/bxcan.c +1 -1
@@ -842,7 +842,7 @@ static netdev_tx_t bxcan_start_xmit(struct sk_buff *skb,u32 id;int i, j; -if (can_dropped_invalid_skb (ndev, skb)) +if (can_dev_dropped_skb (ndev, skb))return NETDEV_TX_OK ;if (bxcan_tx_busy (priv))
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 24/84 selftests/net: convert sctp_vrf.sh to run it in unique namespace
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangbin Liu <[email protected]>
[ Upstream commit 90e271f65ee428ae5a75e783f5ba50a10dece09d ]
Here is the test result after conversion.
]# ./sctp_vrf.sh
Testing For SCTP VRF:
TEST 01: nobind, connect from client 1, l3mdev_accept=1, Y [PASS]
...
TEST 12: bind vrf-2 & 1 in server, connect from client 1 & 2, N [PASS] ***v6 Tests Done***
Stable-dep-of: a73ca0449bcb ("selftests: net: fix server bind failure in sctp_vrf.sh")
--- tools/testing/selftests/net/sctp_vrf.sh | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
tools/testing/selftests/net/sctp_vrf.sh +3 -9
@@ -6,13 +6,11 @@ # SERVER_NS # CLIENT_NS2 (veth1) <---> (veth2) -> vrf_s2 -CLIENT_NS1="client-ns1" -CLIENT_NS2="client-ns2" +source lib.sh CLIENT_IP4="10.0.0.1" CLIENT_IP6="2000::1" CLIENT_PORT=1234 -SERVER_NS="server-ns" SERVER_IP4="10.0.0.2" SERVER_IP6="2000::2" SERVER_PORT=1234
@@ -20,9 +18,7 @@ SERVER_PORT=1234 setup() { modprobe sctp modprobe sctp_diag - ip netns add $CLIENT_NS1 - ip netns add $CLIENT_NS2 - ip netns add $SERVER_NS + setup_ns CLIENT_NS1 CLIENT_NS2 SERVER_NS ip net exec $CLIENT_NS1 sysctl -w net.ipv6.conf.default.accept_dad=0 2>&1 >/dev/null ip net exec $CLIENT_NS2 sysctl -w net.ipv6.conf.default.accept_dad=0 2>&1 >/dev/null
@@ -67,9 +63,7 @@ setup() { cleanup() { ip netns exec $SERVER_NS pkill sctp_hello 2>&1 >/dev/null - ip netns del "$CLIENT_NS1" - ip netns del "$CLIENT_NS2" - ip netns del "$SERVER_NS" + cleanup_ns $CLIENT_NS1 $CLIENT_NS2 $SERVER_NS } wait_server() {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 25/84 selftests: net: fix server bind failure in sctp_vrf.sh
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ Upstream commit a73ca0449bcb7c238097cc6a1bf3fd82a78374df ]
sctp_vrf.sh could fail:
TEST 12: bind vrf-2 & 1 in server, connect from client 1 & 2, N [FAIL] not ok 1 selftests: net: sctp_vrf.sh # exit=3
The failure happens when the server bind in a new run conflicts with an existing association from the previous run:
[1] ip netns exec $SERVER_NS ./sctp_hello server ...
[2] ip netns exec $CLIENT_NS ./sctp_hello client ...
[3] ip netns exec $SERVER_NS pkill sctp_hello ...
[4] ip netns exec $SERVER_NS ./sctp_hello server ...
It occurs if the client in [2] sends a message and closes immediately. With the message unacked, no SHUTDOWN is sent. Killing the server in [3] triggers a SHUTDOWN the client also ignores due to the unacked message, leaving the old association alive. This causes the bind at [4] to fail until the message is acked and the client responds to a second SHUTDOWN after the server’s T2 timer expires (3s).
This patch fixes the issue by preventing the client from sending data. Instead, the client blocks on recv() and waits for the server to close. It also waits until both the server and the client sockets are fully released in stop_server and wait_client before restarting.
Additionally, replace 2>&1 >/dev/null with -q in sysctl and grep, and drop other redundant 2>&1 >/dev/null redirections, and fix a typo from N to Y (connect successfully) in the description of the last test.
--- tools/testing/selftests/net/sctp_hello.c | 17 +----- tools/testing/selftests/net/sctp_vrf.sh | 73 +++++++++++++++--------- 2 files changed, 47 insertions(+), 43 deletions(-)
tools/testing/selftests/net/sctp_hello.c +2 -15
@@ -29,7 +29,6 @@ static void set_addr(struct sockaddr_storage *ss, char *ip, char *port, int *lenstatic int do_client (int argc,char *argv[]) {struct sockaddr_storage ss; -char buf[] ="hello" ;int csk, ret, len;if (argc <5 ) {
@@ -56,16 +55,10 @@ static int do_client(int argc, char *argv[])set_addr (&ss, argv[3 ], argv[4 ], &len); ret =connect (csk, (struct sockaddr *)&ss, len); -if (ret <0 ) { -printf ("failed to connect to peer\n" ); +if (ret <0 )return -1 ; - } - ret =send (csk, buf,strlen (buf) +1 ,0 ); -if (ret <0 ) { -printf ("failed to send msg %d\n" , ret); -return -1 ; - } +recv (csk,NULL ,0 ,0 );close (csk);return 0 ;
@@ -75,7 +68,6 @@ int main(int argc, char *argv[]) {struct sockaddr_storage ss;int lsk, csk, ret, len; -char buf[20 ];if (argc <2 || (strcmp (argv[1 ],"server" ) &&strcmp (argv[1 ],"client" ))) {printf ("%s server|client ...\n" , argv[0 ]);
@@ -125,11 +117,6 @@ int main(int argc, char *argv[])return -1 ; } - ret =recv (csk, buf,sizeof (buf),0 ); -if (ret <=0 ) { -printf ("failed to recv msg %d\n" , ret); -return -1 ; - }close (csk);close (lsk);
tools/testing/selftests/net/sctp_vrf.sh +45 -28
124 lines not on this page · raw message
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 26/84 net/mlx5e: Reuse per-RQ XDP buffer to avoid stack zeroing overhead
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Carolina Jubran <[email protected]>
[ Upstream commit b66b76a82c8879d764ab89adc21ee855ffd292d5 ]
CONFIG_INIT_STACK_ALL_ZERO introduces a performance cost by zero-initializing all stack variables on function entry. The mlx5 XDP RX path previously allocated a struct mlx5e_xdp_buff on the stack per received CQE, resulting in measurable performance degradation under this config.
This patch reuses a mlx5e_xdp_buff stored in the mlx5e_rq struct, avoiding per-CQE stack allocations and repeated zeroing.
With this change, XDP_DROP and XDP_TX performance matches that of kernels built without CONFIG_INIT_STACK_ALL_ZERO.
Performance was measured on a ConnectX-6Dx using a single RX channel (1 CPU at 100% usage) at ~50 Mpps. The baseline results were taken from net-next-6.15.
Stack zeroing disabled:
- XDP_DROP:
* baseline: 31.47 Mpps
* baseline + per-RQ allocation: 32.31 Mpps (+2.68%)
- XDP_TX:
* baseline: 12.41 Mpps
* baseline + per-RQ allocation: 12.95 Mpps (+4.30%)
Stack zeroing enabled:
- XDP_DROP:
* baseline: 24.32 Mpps
* baseline + per-RQ allocation: 32.27 Mpps (+32.7%)
- XDP_TX:
* baseline: 11.80 Mpps
* baseline + per-RQ allocation: 12.24 Mpps (+3.72%)
Stable-dep-of: afd5ba577c10 ("net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for legacy RQ")
--- drivers/net/ethernet/mellanox/mlx5/core/en.h | 7 ++ .../net/ethernet/mellanox/mlx5/core/en/xdp.h | 6 -- .../net/ethernet/mellanox/mlx5/core/en_rx.c | 81 ++++++++++--------- 3 files changed, 51 insertions(+), 43 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en.h +7 -0
@@ -519,6 +519,12 @@ struct mlx5e_xdpsq {struct mlx5e_channel *channel; }____cacheline_aligned_in_smp ; +struct mlx5e_xdp_buff { +struct xdp_buff xdp; +struct mlx5_cqe64 *cqe; +struct mlx5e_rq *rq; +}; +struct mlx5e_ktls_resync_resp ;struct mlx5e_icosq {
@@ -717,6 +723,7 @@ struct mlx5e_rq {struct mlx5e_xdpsq *xdpsq;DECLARE_BITMAP (flags,8 );struct page_pool *page_pool; +struct mlx5e_xdp_buff mxbuf;/* AF_XDP zero-copy */ struct xsk_buff_pool *xsk_pool;
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h +0 -6
@@ -44,12 +44,6 @@ (MLX5E_XDP_INLINE_WQE_MAX_DS_CNT *MLX5_SEND_WQE_DS - \sizeof (struct mlx5_wqe_inline_seg )) -struct mlx5e_xdp_buff { -struct xdp_buff xdp; -struct mlx5_cqe64 *cqe; -struct mlx5e_rq *rq; -}; -/* XDP packets can be transmitted in different ways. On completion, we need to * distinguish between them to clean up things in a proper way. */
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +44 -37
204 lines not on this page · raw message
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 27/84 net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for legacy RQ
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amery Hung <[email protected]>
[ Upstream commit afd5ba577c10639f62e8120df67dc70ea4b61176 ]
XDP programs can release xdp_buff fragments when calling bpf_xdp_adjust_tail(). The driver currently assumes the number of fragments to be unchanged and may generate skb with wrong truesize or containing invalid frags. Fix the bug by generating skb according to xdp_buff after the XDP program runs.
--- .../net/ethernet/mellanox/mlx5/core/en_rx.c | 25 ++++++++++++++----- 1 file changed, 19 insertions(+), 6 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +19 -6
@@ -1774,14 +1774,27 @@ mlx5e_skb_from_cqe_nonlinear(struct mlx5e_rq *rq, struct mlx5e_wqe_frag_info *wi } prog =rcu_dereference (rq->xdp_prog); -if (prog &&mlx5e_xdp_handle (rq, prog, mxbuf)) { -if (__test_and_clear_bit (MLX5E_RQ_FLAG_XDP_XMIT , rq->flags)) { -struct mlx5e_wqe_frag_info *pwi; +if (prog) { +u8 nr_frags_free, old_nr_frags = sinfo->nr_frags; + +if (mlx5e_xdp_handle (rq, prog, mxbuf)) { +if (__test_and_clear_bit (MLX5E_RQ_FLAG_XDP_XMIT , + rq->flags)) { +struct mlx5e_wqe_frag_info *pwi; + + wi -= old_nr_frags - sinfo->nr_frags; + +for (pwi = head_wi; pwi < wi; pwi++) + pwi->frag_page->frags++; + } +return NULL ;/* page/packet was consumed by XDP */ + } -for (pwi = head_wi; pwi < wi; pwi++) - pwi->frag_page->frags++; + nr_frags_free = old_nr_frags - sinfo->nr_frags; +if (unlikely (nr_frags_free)) { + wi -= nr_frags_free; + truesize -= nr_frags_free * frag_info->frag_stride; } -return NULL ;/* page/packet was consumed by XDP */ } skb = mlx5e_build_linear_skb(
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 28/84 net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amery Hung <[email protected]>
[ Upstream commit 87bcef158ac1faca1bd7e0104588e8e2956d10be ]
XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run.
Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it.
To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.
--- .../net/ethernet/mellanox/mlx5/core/en_rx.c | 26 ++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +23 -3
@@ -2024,6 +2024,7 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *wu32 byte_cnt = cqe_bcnt;struct skb_shared_info *sinfo;unsigned int truesize =0 ; +u32 pg_consumed_bytes;struct bpf_prog *prog;struct sk_buff *skb;u32 linear_frame_sz;
@@ -2075,7 +2076,8 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *wwhile (byte_cnt) {/* Non-linear mode, hence non-XSK, which always uses PAGE_SIZE. */ -u32 pg_consumed_bytes =min_t (u32,PAGE_SIZE - frag_offset, byte_cnt); + pg_consumed_bytes = +min_t (u32,PAGE_SIZE - frag_offset, byte_cnt);if (test_bit (MLX5E_RQ_STATE_SHAMPO , &rq->state)) truesize += pg_consumed_bytes;
@@ -2091,10 +2093,15 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w }if (prog) { +u8 nr_frags_free, old_nr_frags = sinfo->nr_frags; +u32 len; +if (mlx5e_xdp_handle (rq, prog, mxbuf)) {if (__test_and_clear_bit (MLX5E_RQ_FLAG_XDP_XMIT , rq->flags)) {struct mlx5e_frag_page *pfp; + frag_page -= old_nr_frags - sinfo->nr_frags; +for (pfp = head_page; pfp < frag_page; pfp++) pfp->frags++;
@@ -2104,9 +2111,19 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *wreturn NULL ;/* page/packet was consumed by XDP */ } + nr_frags_free = old_nr_frags - sinfo->nr_frags; +if (unlikely (nr_frags_free)) { + frag_page -= nr_frags_free; + truesize -= (nr_frags_free -1 ) *PAGE_SIZE + +ALIGN (pg_consumed_bytes, +BIT (rq->mpwqe.log_stride_sz)); + } + + len = mxbuf->xdp.data_end - mxbuf->xdp.data; + skb =mlx5e_build_linear_skb ( rq, mxbuf->xdp.data_hard_start, linear_frame_sz, - mxbuf->xdp.data - mxbuf->xdp.data_hard_start,0 , + mxbuf->xdp.data - mxbuf->xdp.data_hard_start, len, mxbuf->xdp.data - mxbuf->xdp.data_meta);if (unlikely (!skb)) {mlx5e_page_release_fragmented (rq, &wi->linear_page);
@@ -2130,8 +2147,11 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *wdo pagep->frags++;while (++pagep < frag_page); + + headlen =min_t (u16,MLX5E_RX_MAX_HEAD - len, + skb->data_len); +__pskb_pull_tail (skb, headlen); } -__pskb_pull_tail (skb, headlen); }else {dma_addr_t addr;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 29/84 arm64, mm: avoid always making PTE dirty in pte_mkwrite()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
[ 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.
--- arch/arm64/include/asm/pgtable.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/arm64/include/asm/pgtable.h +2 -1
@@ -184,7 +184,8 @@ static inline pmd_t set_pmd_bit(pmd_t pmd, pgprot_t prot)static inline pte_t pte_mkwrite_novma (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; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 30/84 sctp: avoid NULL dereference when chunk data buffer is missing
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Simakov <[email protected]>
[ Upstream commit 441f0647f7673e0e64d4910ef61a5fb8f16bfb82 ]
chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only.
chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.
--- net/sctp/inqueue.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
net/sctp/inqueue.c +7 -6
@@ -169,13 +169,14 @@ struct sctp_chunk *sctp_inq_pop(struct sctp_inq *queue) chunk->head_skb = chunk->skb;/* skbs with "cover letter" */ -if (chunk->head_skb && chunk->skb->data_len == chunk->skb->len) +if (chunk->head_skb && chunk->skb->data_len == chunk->skb->len) { +if (WARN_ON (!skb_shinfo (chunk->skb)->frag_list)) { +__SCTP_INC_STATS (dev_net (chunk->skb->dev), +SCTP_MIB_IN_PKT_DISCARDS ); +sctp_chunk_free (chunk); + goto next_chunk; + } chunk->skb =skb_shinfo (chunk->skb)->frag_list; - -if (WARN_ON (!chunk->skb)) { -__SCTP_INC_STATS (dev_net (chunk->skb->dev),SCTP_MIB_IN_PKT_DISCARDS ); -sctp_chunk_free (chunk); - goto next_chunk; } }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 31/84 net: bonding: fix possible peer notify event loss or dup issue
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tonghao Zhang <[email protected]>
commit 10843e1492e474c02b91314963161731fa92af91 upstream.
If the send_peer_notif counter and the peer event notify are not synchronized. It may cause problems such as the loss or dup of peer notify event.
Before this patch:
- If should_notify_peers is true and the lock for send_peer_notif-- fails, peer event may be sent again in next mii_monitor loop, because should_notify_peers is still true.
- If should_notify_peers is true and the lock for send_peer_notif-- succeeded, but the lock for peer event fails, the peer event will be lost.
This patch locks the RTNL for send_peer_notif, events, and commit simultaneously.
--- drivers/net/bonding/bond_main.c | 40 ++++++++++++++++++---------------------- 1 file changed, 18 insertions(+), 22 deletions(-)
drivers/net/bonding/bond_main.c +18 -22
@@ -2874,7 +2874,7 @@ static void bond_mii_monitor(struct work { struct bonding *bond = container_of(work, struct bonding, mii_work.work); -bool should_notify_peers = false; +bool should_notify_peers;bool commit;unsigned long delay;struct slave *slave;
@@ -2886,30 +2886,33 @@ static void bond_mii_monitor(struct work goto re_arm;rcu_read_lock (); + should_notify_peers =bond_should_notify_peers (bond); commit = !!bond_miimon_inspect (bond); -if (bond->send_peer_notif) { -rcu_read_unlock (); -if (rtnl_trylock ()) { - bond->send_peer_notif--; -rtnl_unlock (); - } - }else { -rcu_read_unlock (); - } -if (commit) { +rcu_read_unlock (); + +if (commit || bond->send_peer_notif) {/* Race avoidance with bond_close cancel of workqueue */ if (!rtnl_trylock ()) { delay =1 ; - should_notify_peers = false; goto re_arm; } -bond_for_each_slave (bond, slave, iter) { -bond_commit_link_state (slave,BOND_SLAVE_NOTIFY_LATER ); +if (commit) { +bond_for_each_slave (bond, slave, iter) { +bond_commit_link_state (slave, +BOND_SLAVE_NOTIFY_LATER ); + } +bond_miimon_commit (bond); + } + +if (bond->send_peer_notif) { + bond->send_peer_notif--; +if (should_notify_peers) +call_netdevice_notifiers (NETDEV_NOTIFY_PEERS , + bond->dev); } -bond_miimon_commit (bond);rtnl_unlock ();/* might sleep, hold no other locks */ }
@@ -2917,13 +2920,6 @@ static void bond_mii_monitor(struct work re_arm:if (bond->params.miimon)queue_delayed_work (bond->wq, &bond->mii_work, delay); - -if (should_notify_peers) { -if (!rtnl_trylock ()) -return ; -call_netdevice_notifiers (NETDEV_NOTIFY_PEERS , bond->dev); -rtnl_unlock (); - } } static int bond_upper_dev_walk(struct net_device *upper,
Greg Kroah-Hartman
maintainerPATCH 32/84 dma-debug: dont report false positives with DMA_BOUNCE_UNALIGNED_KMALLOC
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
commit 03521c892bb8d0712c23e158ae9bdf8705897df8 upstream.
Commit 370645f41e6e ("dma-mapping: force bouncing if the kmalloc() size is not cache-line-aligned") introduced DMA_BOUNCE_UNALIGNED_KMALLOC feature and permitted architecture specific code configure kmalloc slabs with sizes smaller than the value of dma_get_cache_alignment().
When that feature is enabled, the physical address of some small kmalloc()-ed buffers might be not aligned to the CPU cachelines, thus not really suitable for typical DMA. To properly handle that case a SWIOTLB buffer bouncing is used, so no CPU cache corruption occurs. When that happens, there is no point reporting a false-positive DMA-API warning that the buffer is not properly aligned, as this is not a client driver fault.
--- kernel/dma/debug.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
kernel/dma/debug.c +4 -1
@@ -23,6 +23,7 @@#include <linux/ctype.h> #include <linux/list.h> #include <linux/slab.h> +#include <linux/swiotlb.h> #include <asm/sections.h> #include "debug.h"
@@ -601,7 +602,9 @@ static void add_dma_entry(struct dma_debif (rc == -ENOMEM ) {pr_err_once ("cacheline tracking ENOMEM, dma-debug disabled\n" ); global_disable = true; - }else if (rc == -EEXIST && !(attrs &DMA_ATTR_SKIP_CPU_SYNC )) { + }else if (rc == -EEXIST && !(attrs &DMA_ATTR_SKIP_CPU_SYNC ) && + !(IS_ENABLED (CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC ) && +is_swiotlb_active (entry->dev))) {err_printk (entry->dev, entry,"cacheline tracking EEXIST, overlapping mappings aren't supported\n" ); }
Greg Kroah-Hartman
maintainerPATCH 33/84 arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kaushlendra Kumar <[email protected]>
commit 2eead19334516c8e9927c11b448fbe512b1f18a1 upstream.
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:
"The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().
--- drivers/base/arch_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/arch_topology.c +1 -1
@@ -326,7 +326,7 @@ bool __init topology_parse_cpu_capacity(* frequency (by keeping the initial capacity_freq_ref value). */ cpu_clk =of_clk_get (cpu_node,0 ); -if (!PTR_ERR_OR_ZERO (cpu_clk)) { +if (!IS_ERR_OR_NULL (cpu_clk)) {per_cpu (capacity_freq_ref, cpu) =clk_get_rate (cpu_clk) /HZ_PER_KHZ ;clk_put (cpu_clk);
Greg Kroah-Hartman
maintainerPATCH 34/84 gpio: pci-idio-16: Define maximum valid register address offset
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Breathitt Gray <[email protected]>
commit d37623132a6347b4ab9e2179eb3f2fa77863c364 upstream.
Attempting to load the pci-idio-16 module fails during regmap initialization with a return error -EINVAL. This is a result of the regmap cache failing initialization. Set the idio_16_regmap_config max_register member to fix this failure.
--- drivers/gpio/gpio-pci-idio-16.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpio/gpio-pci-idio-16.c +1 -0
@@ -41,6 +41,7 @@ static const struct regmap_config idio_16_regmap_config = { .reg_stride = 1, .val_bits = 8, .io_port = true, + .max_register = 0x7, .wr_table = &idio_16_wr_table, .rd_table = &idio_16_rd_table, .volatile_table = &idio_16_rd_table,
Signature · 1 line
2.51.1
Greg Kroah-Hartman
maintainerPATCH 35/84 gpio: 104-idio-16: Define maximum valid register address offset
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Breathitt Gray <[email protected]>
commit c4d35e635f3a65aec291a6045cae8c99cede5bba upstream.
Attempting to load the 104-idio-16 module fails during regmap initialization with a return error -EINVAL. This is a result of the regmap cache failing initialization. Set the idio_16_regmap_config max_register member to fix this failure.
--- drivers/gpio/gpio-104-idio-16.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpio/gpio-104-idio-16.c +1 -0
@@ -59,6 +59,7 @@ static const struct regmap_config idio_16_regmap_config = { .reg_stride = 1, .val_bits = 8, .io_port = true, + .max_register = 0x5, .wr_table = &idio_16_wr_table, .rd_table = &idio_16_rd_table, .volatile_table = &idio_16_rd_table,
Signature · 1 line
2.51.1
Greg Kroah-Hartman
maintainerPATCH 36/84 Revert "cpuidle: menu: Avoid discarding useful information"
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
commit 10fad4012234a7dea621ae17c0c9486824f645a0 upstream.
It is reported that commit 85975daeaa4d ("cpuidle: menu: Avoid discarding useful information") led to a performance regression on Intel Jasper Lake systems because it reduced the time spent by CPUs in idle state C7 which is correlated to the maximum frequency the CPUs can get to because of an average running power limit [1].
Before that commit, get_typical_interval() would have returned UINT_MAX whenever it had been unable to make a high-confidence prediction which had led to selecting the deepest available idle state too often and both power and performance had been inadequate as a result of that on some systems. However, this had not been a problem on systems with relatively aggressive average running power limits, like the Jasper Lake systems in question, because on those systems it was compensated by the ability to run CPUs faster.
It was addressed by causing get_typical_interval() to return a number based on the recent idle duration information available to it even if it could not make a high-confidence prediction, but that clearly did not take the possible correlation between idle power and available CPU capacity into account.
For this reason, revert most of the changes made by commit 85975daeaa4d, except for one cosmetic cleanup, and add a comment explaining the rationale for returning UINT_MAX from get_typical_interval() when it is unable to make a high-confidence prediction.
--- drivers/cpuidle/governors/menu.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-)
drivers/cpuidle/governors/menu.c +9 -12
@@ -230,20 +230,17 @@ again:* * This can deal with workloads that have long pauses interspersed * with sporadic activity with a bunch of short pauses. +* +* However, if the number of remaining samples is too small to exclude +* any more outliers, allow the deepest available idle state to be +* selected because there are systems where the time spent by CPUs in +* deep idle states is correlated to the maximum frequency the CPUs +* can get to. On those systems, shallow idle states should be avoided +* unless there is a clear indication that the given CPU is most likley +* going to be woken up shortly. */ -if (divisor *4 <=INTERVALS *3 ) { -/* -* If there are sufficiently many data points still under -* consideration after the outliers have been eliminated, -* returning without a prediction would be a mistake because it -* is likely that the next interval will not exceed the current -* maximum, so return the latter in that case. -*/ -if (divisor >=INTERVALS /2 ) -return max; - +if (divisor *4 <=INTERVALS *3 )return UINT_MAX ; - } thresh = max -1 ; goto again;
Greg Kroah-Hartman
maintainerPATCH 37/84 ACPICA: Work around bogus -Wstringop-overread warning since GCC 11
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xi Ruoyao <[email protected]>
commit 6e3a4754717a74e931a9f00b5f953be708e07acb upstream.
When ACPI_MISALIGNMENT_NOT_SUPPORTED is set, GCC can produce a bogus -Wstringop-overread warning, see [1].
To me, it's very clear that we have a compiler bug here, thus just disable the warning.
--- drivers/acpi/acpica/tbprint.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/acpi/acpica/tbprint.c +6 -0
@@ -95,6 +95,11 @@ acpi_tb_print_table_header(acpi_physical {struct acpi_table_header local_header; +#pragma GCC diagnostic push +#if defined(__GNUC__) && __GNUC__ >=11 +#pragma GCC diagnostic ignored "-Wstringop-overread" +#endif +if (ACPI_COMPARE_NAMESEG (header->signature,ACPI_SIG_FACS )) {/* FACS only has signature and length fields */
@@ -135,4 +140,5 @@ acpi_tb_print_table_header(acpi_physical local_header.asl_compiler_id, local_header.asl_compiler_revision)); } +#pragma GCC diagnostic pop }
Greg Kroah-Hartman
maintainerPATCH 38/84 can: netlink: can_changelink(): allow disabling of automatic restart
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Kleine-Budde <[email protected]>
commit 8e93ac51e4c6dc399fad59ec21f55f2cfb46d27c upstream.
Since the commit c1f3f9797c1f ("can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode"), the automatic restart delay can only be set for devices that implement the restart handler struct can_priv::do_set_mode. As it makes no sense to configure a automatic restart for devices that doesn't support it.
However, since systemd commit 13ce5d4632e3 ("network/can: properly handle CAN.RestartSec=0") [1], systemd-networkd correctly handles a restart delay of "0" (i.e. the restart is disabled). Which means that a disabled restart is always configured in the kernel.
On systems with both changes active this causes that CAN interfaces that don't implement a restart handler cannot be brought up by systemd-networkd.
Solve this problem by allowing a delay of "0" to be configured, even if the device does not implement a restart handler.
[1] https://github.com/systemd/systemd/commit/13ce5d4632e395521e6205c954493c7fc1c4c6e0
--- drivers/net/can/dev/netlink.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/can/dev/netlink.c +4 -2
@@ -285,7 +285,9 @@ static int can_changelink(struct net_dev }if (data[IFLA_CAN_RESTART_MS ]) { -if (!priv->do_set_mode) { +unsigned int restart_ms =nla_get_u32 (data[IFLA_CAN_RESTART_MS ]); + +if (restart_ms !=0 && !priv->do_set_mode) {NL_SET_ERR_MSG (extack,"Device doesn't support restart from Bus Off" );return -EOPNOTSUPP ;
@@ -294,7 +296,7 @@ static int can_changelink(struct net_dev/* Do not allow changing restart delay while running */ if (dev->flags &IFF_UP )return -EBUSY ; - priv->restart_ms =nla_get_u32 (data[IFLA_CAN_RESTART_MS ]); + priv->restart_ms = restart_ms; }if (data[IFLA_CAN_RESTART ]) {
Greg Kroah-Hartman
maintainerPATCH 39/84 cifs: Fix TCP_Server_Info::credits to be signed
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit 5b2ff4873aeab972f919d5aea11c51393322bf58 upstream.
Fix TCP_Server_Info::credits to be signed, just as echo_credits and oplock_credits are. This also fixes what ought to get at least a compilation warning if not an outright error in *get_credits_field() as a pointer to the unsigned server->credits field is passed back as a pointer to a signed int.
--- fs/smb/client/cifsglob.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/smb/client/cifsglob.h +1 -1
@@ -703,7 +703,7 @@ struct TCP_Server_Info {bool nosharesock;bool tcp_nodelay;bool terminate; -unsigned int credits;/* send no more requests at once */ +int credits;/* send no more requests at once */ unsigned int max_credits;/* can override large 32000 default at mnt */ unsigned int in_flight;/* number of requests on the wire to server */ unsigned int max_in_flight;/* max number of requests that were on wire */
Greg Kroah-Hartman
maintainerPATCH 40/84 MIPS: Malta: Fix keyboard resource preventing i8042 driver from registering
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej W. Rozycki <[email protected]>
commit bf5570590a981d0659d0808d2d4bcda21b27a2a5 upstream.
MIPS Malta platform code registers the PCI southbridge legacy port I/O PS/2 keyboard range as a standard resource marked as busy. It prevents the i8042 driver from registering as it fails to claim the resource in a call to i8042_platform_init(). Consequently PS/2 keyboard and mouse devices cannot be used with this platform.
Fix the issue by removing the busy marker from the standard reservation, making the driver register successfully:
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
and the resource show up as expected among the legacy devices:
00000000-00ffffff : MSC PCI I/O
00000000-0000001f : dma1
00000020-00000021 : pic1
00000040-0000005f : timer
00000060-0000006f : keyboard
00000060-0000006f : i8042
00000070-00000077 : rtc0
00000080-0000008f : dma page reg
000000a0-000000a1 : pic2
000000c0-000000df : dma2
[...]If the i8042 driver has not been configured, then the standard resource will remain there preventing any conflicting dynamic assignment of this PCI port I/O address range.
--- arch/mips/mti-malta/malta-setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/mti-malta/malta-setup.c +1 -1
@@ -47,7 +47,7 @@ static struct resource standard_io_resou .name = "keyboard", .start = 0x60, .end = 0x6f, - .flags =IORESOURCE_IO |IORESOURCE_BUSY + .flags =IORESOURCE_IO }, { .name = "dma page reg",
Greg Kroah-Hartman
maintainerPATCH 41/84 ocfs2: clear extent cache after moving/defragmenting extents
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
commit 78a63493f8e352296dbc7cb7b3f4973105e8679e upstream.
The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().
The problem occurs when:
1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED
2. ioctl(FITRIM) triggers ocfs2_move_extents()
3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)
4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)
5. The extent map cache is not invalidated after the move
6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch
7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers
Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk.
--- fs/ocfs2/move_extents.c | 5 +++++ 1 file changed, 5 insertions(+)
fs/ocfs2/move_extents.c +5 -0
@@ -868,6 +868,11 @@ static int __ocfs2_move_extents_range(stmlog_errno (ret); goto out; } +/* +* Invalidate extent cache after moving/defragging to prevent +* stale cached data with outdated extent flags. +*/ +ocfs2_extent_map_trunc (inode, cpos); context->clusters_moved += alloc_size; next:
Greg Kroah-Hartman
maintainerPATCH 42/84 vsock: fix lock inversion in vsock_assign_transport()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Garzarella <[email protected]>
commit f7c877e7535260cc7a21484c994e8ce7e8cb6780 upstream.
Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.
The issue was introduced by commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created.
Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().
--- net/vmw_vsock/af_vsock.c | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-)
net/vmw_vsock/af_vsock.c +19 -19
@@ -486,12 +486,26 @@ int vsock_assign_transport(struct vsock_ goto err; } -if (vsk->transport) { -if (vsk->transport == new_transport) { - ret =0 ; - goto err; - } +if (vsk->transport && vsk->transport == new_transport) { + ret =0 ; + goto err; + } + +/* We increase the module refcnt to prevent the transport unloading +* while there are open sockets assigned to it. +*/ +if (!new_transport || !try_module_get (new_transport->module)) { + ret = -ENODEV ; + goto err; + } + +/* It's safe to release the mutex after a successful try_module_get(). +* Whichever transport `new_transport` points at, it won't go away until +* the last module_put() below or in vsock_deassign_transport(). +*/ +mutex_unlock (&vsock_register_mutex); +if (vsk->transport) {/* transport->release() must be called with sock lock acquired. * This path can only be taken during vsock_connect(), where we * have already held the sock lock. In the other cases, this
@@ -511,20 +525,6 @@ int vsock_assign_transport(struct vsock_ vsk->peer_shutdown =0 ; } -/* We increase the module refcnt to prevent the transport unloading -* while there are open sockets assigned to it. -*/ -if (!new_transport || !try_module_get (new_transport->module)) { - ret = -ENODEV ; - goto err; - } - -/* It's safe to release the mutex after a successful try_module_get(). -* Whichever transport `new_transport` points at, it won't go away until -* the last module_put() below or in vsock_deassign_transport(). -*/ -mutex_unlock (&vsock_register_mutex); -if (sk->sk_type ==SOCK_SEQPACKET ) {if (!new_transport->seqpacket_allow || !new_transport->seqpacket_allow (remote_cid)) {
Greg Kroah-Hartman
maintainerPATCH 43/84 net: stmmac: dwmac-rk: Fix disabling set_clock_selection
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Reichel <[email protected]>
commit 7f864458e9a6d2000b726d14b3d3a706ac92a3b0 upstream.
On all platforms set_clock_selection() writes to a GRF register. This requires certain clocks running and thus should happen before the clocks are disabled.
This has been noticed on RK3576 Sige5, which hangs during system suspend when trying to suspend the second network interface. Note, that suspending the first interface works, because the second device ensures that the necessary clocks for the GRF are enabled.
--- drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c +5 -4
@@ -1565,14 +1565,15 @@ static int gmac_clk_enable(struct rk_pri } }else {if (bsp_priv->clk_enabled) { +if (bsp_priv->ops && bsp_priv->ops->set_clock_selection) { + bsp_priv->ops->set_clock_selection (bsp_priv, + bsp_priv->clock_input, false); + } +clk_bulk_disable_unprepare (bsp_priv->num_clks, bsp_priv->clks);clk_disable_unprepare (bsp_priv->clk_phy); -if (bsp_priv->ops && bsp_priv->ops->set_clock_selection) - bsp_priv->ops->set_clock_selection (bsp_priv, - bsp_priv->clock_input, false); - bsp_priv->clk_enabled = false; } }
Greg Kroah-Hartman
maintainerPATCH 44/84 net: usb: rtl8150: Fix frame padding
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Pecio <[email protected]>
commit 75cea9860aa6b2350d90a8d78fed114d27c7eca2 upstream.
TX frames aren't padded and unknown memory is sent into the ether.
Theoretically, it isn't even guaranteed that the extra memory exists and can be sent out, which could cause further problems. In practice, I found that plenty of tailroom exists in the skb itself (in my test with ping at least) and skb_padto() easily succeeds, so use it here.
In the event of -ENOMEM drop the frame like other drivers do.
The use of one more padding byte instead of a USB zero-length packet is retained to avoid regression. I have a dodgy Etron xHCI controller which doesn't seem to support sending ZLPs at all.
--- drivers/net/usb/rtl8150.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/net/usb/rtl8150.c +9 -2
@@ -685,9 +685,16 @@ static netdev_tx_t rtl8150_start_xmit(strtl8150_t *dev =netdev_priv (netdev);int count, res; +/* pad the frame and ensure terminating USB packet, datasheet 9.2.3 */ + count =max (skb->len,ETH_ZLEN ); +if (count %64 ==0 ) + count++; +if (skb_padto (skb, count)) { + netdev->stats.tx_dropped++; +return NETDEV_TX_OK ; + } +netif_stop_queue (netdev); - count = (skb->len <60 ) ?60 : skb->len; - count = (count &0x3f ) ? count : count +1 ; dev->tx_skb = skb;usb_fill_bulk_urb (dev->tx_urb, dev->udev,usb_sndbulkpipe (dev->udev,2 ), skb->data, count, write_bulk_callback, dev);
Greg Kroah-Hartman
maintainerPATCH 45/84 net: ravb: Enforce descriptor type ordering
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lad Prabhakar <[email protected]>
commit 5370c31e84b0e0999c7b5ff949f4e104def35584 upstream.
Ensure the TX descriptor type fields are published in a safe order so the DMA engine never begins processing a descriptor chain before all descriptor fields are fully initialised.
For multi-descriptor transmits the driver writes DT_FEND into the last descriptor and DT_FSTART into the first. The DMA engine begins processing when it observes DT_FSTART. Move the dma_wmb() barrier so it executes immediately after DT_FEND and immediately before writing DT_FSTART (and before DT_FSINGLE in the single-descriptor case). This guarantees that all prior CPU writes to the descriptor memory are visible to the device before DT_FSTART is seen.
This avoids a situation where compiler/CPU reordering could publish DT_FSTART ahead of DT_FEND or other descriptor fields, allowing the DMA to start on a partially initialised chain and causing corrupted transmissions or TX timeouts. Such a failure was observed on RZ/G2L with an RT kernel as transmit queue timeouts and device resets.
--- drivers/net/ethernet/renesas/ravb_main.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
drivers/net/ethernet/renesas/ravb_main.c +14 -2
@@ -2038,13 +2038,25 @@ static netdev_tx_t ravb_start_xmit(strucskb_tx_timestamp (skb); } -/* Descriptor type must be set after all the above writes */ -dma_wmb (); +if (num_tx_desc >1 ) { desc->die_dt =DT_FEND ; desc--; +/* When using multi-descriptors, DT_FEND needs to get written +* before DT_FSTART, but the compiler may reorder the memory +* writes in an attempt to optimize the code. +* Use a dma_wmb() barrier to make sure DT_FEND and DT_FSTART +* are written exactly in the order shown in the code. +* This is particularly important for cases where the DMA engine +* is already running when we are running this code. If the DMA +* sees DT_FSTART without the corresponding DT_FEND it will enter +* an error condition. +*/ +dma_wmb (); desc->die_dt =DT_FSTART ; }else { +/* Descriptor type must be set after all the above writes */ +dma_wmb (); desc->die_dt =DT_FSINGLE ; }ravb_modify (ndev,TCCR ,TCCR_TSRQ0 << q,TCCR_TSRQ0 << q);
Greg Kroah-Hartman
maintainerPATCH 46/84 net: ravb: Ensure memory write completes before ringing TX doorbell
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lad Prabhakar <[email protected]>
commit 706136c5723626fcde8dd8f598a4dcd251e24927 upstream.
Add a final dma_wmb() barrier before triggering the transmit request (TCCR_TSRQ) to ensure all descriptor and buffer writes are visible to the DMA engine.
According to the hardware manual, a read-back operation is required before writing to the doorbell register to guarantee completion of previous writes. Instead of performing a dummy read, a dma_wmb() is used to both enforce the same ordering semantics on the CPU side and also to ensure completion of writes.
--- drivers/net/ethernet/renesas/ravb_main.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/net/ethernet/renesas/ravb_main.c +8 -0
@@ -2059,6 +2059,14 @@ static netdev_tx_t ravb_start_xmit(strucdma_wmb (); desc->die_dt =DT_FSINGLE ; } + +/* Before ringing the doorbell we need to make sure that the latest +* writes have been committed to memory, otherwise it could delay +* things until the doorbell is rang again. +* This is in replacement of the read operation mentioned in the HW +* manuals. +*/ +dma_wmb ();ravb_modify (ndev,TCCR ,TCCR_TSRQ0 << q,TCCR_TSRQ0 << q); priv->cur_tx[q] += num_tx_desc;
Greg Kroah-Hartman
maintainerPATCH 47/84 selftests: mptcp: join: mark flush re-add as skipped if not supported
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit d68460bc31f9c8c6fc81fbb56ec952bec18409f1 upstream.
The call to 'continue_if' was missing: it properly marks a subtest as 'skipped' if the attached condition is not valid.
Without that, the test is wrongly marked as passed on older kernels.
--- tools/testing/selftests/net/mptcp/mptcp_join.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/net/mptcp/mptcp_join.sh +1 -1
@@ -3910,7 +3910,7 @@ endpoint_tests() # flush and re-add if reset_with_tcp_filter "flush re-add" ns2 10.0.3.2 REJECT OUTPUT && - mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then pm_nl_set_limits $ns1 0 2 pm_nl_set_limits $ns2 1 2 # broadcast IP: no packet for this address will be received on ns1
Greg Kroah-Hartman
maintainerPATCH 48/84 selftests: mptcp: join: mark implicit tests as skipped if not supported
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 973f80d715bd2504b4db6e049f292e694145cd79 upstream.
The call to 'continue_if' was missing: it properly marks a subtest as 'skipped' if the attached condition is not valid.
Without that, the test is wrongly marked as passed on older kernels.
--- tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/testing/selftests/net/mptcp/mptcp_join.sh +2 -2
@@ -3737,7 +3737,7 @@ endpoint_tests() # subflow_rebuild_header is needed to support the implicit flag # userspace pm type prevents add_addr if reset "implicit EP" && - mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then pm_nl_set_limits $ns1 2 2 pm_nl_set_limits $ns2 2 2 pm_nl_add_endpoint $ns1 10.0.2.1 flags signal
@@ -3762,7 +3762,7 @@ endpoint_tests() fi if reset_with_tcp_filter "delete and re-add" ns2 10.0.3.2 REJECT OUTPUT && - mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then start_events pm_nl_set_limits $ns1 0 3 pm_nl_set_limits $ns2 0 3
Greg Kroah-Hartman
maintainerPATCH 49/84 spi: spi-nxp-fspi: add extra delay after dll locked
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Han Xu <[email protected]>
[ Upstream commit b93b4269791fdebbac2a9ad26f324dc2abb9e60f ]
Due to the erratum ERR050272, the DLL lock status register STS2 [xREFLOCK, xSLVLOCK] bit may indicate DLL is locked before DLL is actually locked. Add an extra 4us delay as a workaround.
refer to ERR050272, on Page 20.
https://www.nxp.com/docs/en/errata/IMX8_1N94W.pdf
--- drivers/spi/spi-nxp-fspi.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/spi/spi-nxp-fspi.c +6 -0
@@ -665,6 +665,12 @@ static void nxp_fspi_dll_calibration(struct nxp_fspi *f) 0, POLL_TOUT, true);if (ret)dev_warn (f->dev,"DLL lock failed, please fix it!\n" ); + +/* +* For ERR050272, DLL lock status bit is not accurate, +* wait for 4us more as a workaround. +*/ +udelay (4 ); }/*
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 50/84 firmware: arm_scmi: Account for failed debug initialization
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cristian Marussi <[email protected]>
[ Upstream commit 2290ab43b9d8eafb8046387f10a8dfa2b030ba46 ]
When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL.
Handle this fault condition in the SCMI debug helpers that maintain metrics counters.
Message-Id: <[email protected]>
--- drivers/firmware/arm_scmi/common.h | 24 ++++++++++++++-- drivers/firmware/arm_scmi/driver.c | 44 ++++++++++-------------------- 2 files changed, 35 insertions(+), 33 deletions(-)
drivers/firmware/arm_scmi/common.h +21 -3
@@ -321,10 +321,28 @@ enum debug_counters {SCMI_DEBUG_COUNTERS_LAST }; -static inline void scmi_inc_count (atomic_t *arr,int stat) +/** +* struct scmi_debug_info - Debug common info +* @top_dentry: A reference to the top debugfs dentry +* @name: Name of this SCMI instance +* @type: Type of this SCMI instance +* @is_atomic: Flag to state if the transport of this instance is atomic +* @counters: An array of atomic_c's used for tracking statistics (if enabled) +*/ +struct scmi_debug_info { +struct dentry *top_dentry; +const char *name; +const char *type; +bool is_atomic; +atomic_t counters[SCMI_DEBUG_COUNTERS_LAST ]; +}; + +static inline void scmi_inc_count (struct scmi_debug_info *dbg,int stat) { -if (IS_ENABLED (CONFIG_ARM_SCMI_DEBUG_COUNTERS )) -atomic_inc (&arr[stat]); +if (IS_ENABLED (CONFIG_ARM_SCMI_DEBUG_COUNTERS )) { +if (dbg) +atomic_inc (&dbg->counters[stat]); + } }enum scmi_bad_msg {
drivers/firmware/arm_scmi/driver.c +14 -30
127 lines not on this page · raw message
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 51/84 firmware: arm_scmi: Fix premature SCMI_XFER_FLAG_IS_RAW clearing in raw mode
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Shimko <[email protected]>
[ Upstream commit 20b93a0088a595bceed4a026d527cbbac4e876c5 ]
The SCMI_XFER_FLAG_IS_RAW flag was being cleared prematurely in scmi_xfer_raw_put() before the transfer completion was properly acknowledged by the raw message handlers.
Move the clearing of SCMI_XFER_FLAG_IS_RAW and SCMI_XFER_FLAG_CHAN_SET from scmi_xfer_raw_put() to __scmi_xfer_put() to ensure the flags remain set throughout the entire raw message processing pipeline until the transfer is returned to the free pool.
Message-Id: <[email protected]>
--- drivers/firmware/arm_scmi/driver.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/firmware/arm_scmi/driver.c +1 -2
@@ -627,6 +627,7 @@ __scmi_xfer_put(struct scmi_xfers_info *minfo, struct scmi_xfer *xfer)hash_del (&xfer->node); xfer->pending = false; } + xfer->flags =0 ;hlist_add_head (&xfer->node, &minfo->free_xfers); }spin_unlock_irqrestore (&minfo->xfer_lock, flags);
@@ -645,8 +646,6 @@ void scmi_xfer_raw_put(const struct scmi_handle *handle, struct scmi_xfer *xfer) {struct scmi_info *info =handle_to_scmi_info (handle); - xfer->flags &= ~SCMI_XFER_FLAG_IS_RAW ; - xfer->flags &= ~SCMI_XFER_FLAG_CHAN_SET ;return __scmi_xfer_put (&info->tx_minfo, xfer); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 52/84 RISC-V: Define pgprot_dmacoherent() for non-coherent devices
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anup Patel <[email protected]>
[ Upstream commit ca525d53f994d45c8140968b571372c45f555ac1 ]
The pgprot_dmacoherent() is used when allocating memory for non-coherent devices and by default pgprot_dmacoherent() is same as pgprot_noncached() unless architecture overrides it.
Currently, there is no pgprot_dmacoherent() definition for RISC-V hence non-coherent device memory is being mapped as IO thereby making CPU access to such memory slow.
Define pgprot_dmacoherent() to be same as pgprot_writecombine() for RISC-V so that CPU access non-coherent device memory as NOCACHE which is better than accessing it as IO.
--- arch/riscv/include/asm/pgtable.h | 2 ++ 1 file changed, 2 insertions(+)
arch/riscv/include/asm/pgtable.h +2 -0
@@ -618,6 +618,8 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot)return __pgprot (prot); } +#define pgprot_dmacoherent pgprot_writecombine +/* * THP functions */
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 53/84 RISC-V: Dont print details of CPUs disabled in DT
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anup Patel <[email protected]>
[ Upstream commit d2721bb165b3ee00dd23525885381af07fec852a ]
Early boot stages may disable CPU DT nodes for unavailable CPUs based on SKU, pinstraps, eFuse, etc. Currently, the riscv_early_of_processor_hartid() prints details of a CPU if it is disabled in DT which has no value and gives a false impression to the users that there some issue with the CPU.
--- arch/riscv/kernel/cpu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
arch/riscv/kernel/cpu.c +1 -3
@@ -61,10 +61,8 @@ int __init riscv_early_of_processor_hartid(struct device_node *node, unsigned loreturn -ENODEV ; } -if (!of_device_is_available (node)) { -pr_info ("CPU with hartid=%lu is not available\n" , *hart); +if (!of_device_is_available (node))return -ENODEV ; - }if (of_property_read_string (node,"riscv,isa-base" , &isa)) goto old_interface;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 54/84 hwmon: (sht3x) Fix error handling
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit 8dcc66ad379ec0642fb281c45ccfd7d2d366e53f ]
Handling of errors when reading status, temperature, and humidity returns the error number as negative attribute value. Fix it up by returning the error as return value.
--- drivers/hwmon/sht3x.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-)
drivers/hwmon/sht3x.c +17 -10
@@ -288,24 +288,26 @@ static struct sht3x_data *sht3x_update_client(struct device *dev)return data; } -static int temp1_input_read (struct device *dev) +static int temp1_input_read (struct device *dev,long *temp) {struct sht3x_data *data =sht3x_update_client (dev);if (IS_ERR (data))return PTR_ERR (data); -return data->temperature; + *temp = data->temperature; +return 0 ; } -static int humidity1_input_read (struct device *dev) +static int humidity1_input_read (struct device *dev,long *humidity) {struct sht3x_data *data =sht3x_update_client (dev);if (IS_ERR (data))return PTR_ERR (data); -return data->humidity; + *humidity = data->humidity; +return 0 ; }/*
@@ -703,6 +705,7 @@ static int sht3x_read(struct device *dev, enum hwmon_sensor_types type, u32 attr, int channel, long *val) { enum sht3x_limits index; +int ret;switch (type) {case hwmon_chip:
@@ -717,10 +720,12 @@ static int sht3x_read(struct device *dev, enum hwmon_sensor_types type,case hwmon_temp:switch (attr) {case hwmon_temp_input: - *val =temp1_input_read (dev); -break ; +return temp1_input_read (dev, val);case hwmon_temp_alarm: - *val =temp1_alarm_read (dev); + ret =temp1_alarm_read (dev); +if (ret <0 ) +return ret; + *val = ret;break ;case hwmon_temp_max: index = limit_max;
@@ -745,10 +750,12 @@ static int sht3x_read(struct device *dev, enum hwmon_sensor_types type,case hwmon_humidity:switch (attr) {case hwmon_humidity_input: - *val =humidity1_input_read (dev); -break ; +return humidity1_input_read (dev, val);case hwmon_humidity_alarm: - *val =humidity1_alarm_read (dev); + ret =humidity1_alarm_read (dev); +if (ret <0 ) +return ret; + *val = ret;break ;case hwmon_humidity_max: index = limit_max;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 55/84 gpio: update Intel LJCA USB GPIO driver
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wentong Wu <[email protected]>
[ Upstream commit 1034cc423f1b4a7a9a56d310ca980fcd2753e11d ]
This driver communicate with LJCA GPIO module with specific protocol through interfaces exported by LJCA USB driver. Update the driver according to LJCA USB driver's changes.
Stable-dep-of: 4c4e6ea4a120 ("gpio: ljca: Fix duplicated IRQ mapping")
--- drivers/gpio/Kconfig | 4 +- drivers/gpio/gpio-ljca.c | 246 +++++++++++++++++++++++---------------- 2 files changed, 145 insertions(+), 105 deletions(-)
drivers/gpio/Kconfig +2 -2
@@ -1313,9 +1313,9 @@ config GPIO_KEMPLD config GPIO_LJCA tristate "INTEL La Jolla Cove Adapter GPIO support" - depends on MFD_LJCA + depends on USB_LJCA select GPIOLIB_IRQCHIP - default MFD_LJCA + default USB_LJCA help Select this option to enable GPIO driver for the INTEL La Jolla Cove Adapter (LJCA) board.
drivers/gpio/gpio-ljca.c +143 -103
473 lines not on this page · raw message
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 56/84 gpio: ljca: Fix duplicated IRQ mapping
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haotian Zhang <[email protected]>
[ Upstream commit 4c4e6ea4a120cc5ab58e437c6ba123cbfc357d45 ]
The generic_handle_domain_irq() function resolves the hardware IRQ internally. The driver performed a duplicative mapping by calling irq_find_mapping() first, which could lead to an RCU stall.
Delete the redundant irq_find_mapping() call and pass the hardware IRQ directly to generic_handle_domain_irq().
--- drivers/gpio/gpio-ljca.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-)
drivers/gpio/gpio-ljca.c +3 -11
@@ -281,22 +281,14 @@ static void ljca_gpio_event_cb(void *context, u8 cmd, const void *evt_data, {const struct ljca_gpio_packet *packet = evt_data;struct ljca_gpio_dev *ljca_gpio = context; -int i, irq; +int i;if (cmd !=LJCA_GPIO_INT_EVENT )return ;for (i =0 ; i < packet->num; i++) { - irq =irq_find_mapping (ljca_gpio->gc.irq.domain, - packet->item[i].index); -if (!irq) { -dev_err (ljca_gpio->gc.parent, -"gpio_id %u does not mapped to IRQ yet\n" , - packet->item[i].index); -return ; - } - -generic_handle_domain_irq (ljca_gpio->gc.irq.domain, irq); +generic_handle_domain_irq (ljca_gpio->gc.irq.domain, + packet->item[i].index);set_bit (packet->item[i].index, ljca_gpio->reenable_irqs); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 57/84 io_uring: correct __must_hold annotation in io_install_fixed_file
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alok Tiwari <[email protected]>
[ Upstream commit c5efc6a0b3940381d67887302ddb87a5cf623685 ]
The __must_hold annotation references &req->ctx->uring_lock, but req is not in scope in io_install_fixed_file. This change updates the annotation to reference the correct ctx->uring_lock. improving code clarity.
--- io_uring/filetable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
io_uring/filetable.c +1 -1
@@ -62,7 +62,7 @@ void io_free_file_tables(struct io_file_table *table)static int io_install_fixed_file (struct io_ring_ctx *ctx,struct file *file,u32 slot_index) - __must_hold(&req->ctx->uring_lock) + __must_hold(&ctx->uring_lock) {struct io_fixed_file *file_slot;int ret;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 58/84 sched: Remove never used code in mm_cid_get()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit 53abe3e1c154628cc74e33a1bfcd865656e433a5 ]
Clang is not happy with set but unused variable (this is visible with make W=1 build:
kernel/sched/sched.h:3744:18: error: variable 'cpumask' set but not used [-Werror,-Wunused-but-set-variable]
It seems like the variable was never used along with the assignment that does not have side effects as far as I can see. Remove those altogether.
--- kernel/sched/sched.h | 2 -- 1 file changed, 2 deletions(-)
kernel/sched/sched.h +0 -2
@@ -3435,11 +3435,9 @@ static inline int __mm_cid_get(struct rq *rq, struct mm_struct *mm)static inline int mm_cid_get (struct rq *rq,struct mm_struct *mm) {struct mm_cid __percpu *pcpu_cid = mm->pcpu_cid; -struct cpumask *cpumask;int cid;lockdep_assert_rq_held (rq); - cpumask =mm_cidmask (mm); cid =__this_cpu_read (pcpu_cid->cid);if (mm_cid_is_valid (cid)) {mm_cid_snapshot_time (rq, mm);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 59/84 USB: serial: option: add UNISOC UIS7720
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Renjun Wang <[email protected]>
commit 71c07570b918f000de5d0f7f1bf17a2887e303b5 upstream.
Add support for UNISOC (Spreadtrum) UIS7720 (A7720) module.
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4064 Rev=04.04 S: Manufacturer=Unisoc-phone S: Product=Unisoc-phone S: SerialNumber=0123456789ABCDEF C: #Ifs= 9 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
0&1: RNDIS, 2: LOG, 3: DIAG, 4&5: AT Ports, 6&7: AT2 Ports, 8: ADB
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -617,6 +617,7 @@ static void option_instat_callback(struc#define UNISOC_VENDOR_ID 0x1782/* TOZED LT70-C based on UNISOC SL8563 uses UNISOC's vendor ID */ #define TOZED_PRODUCT_LT70C 0x4055 +#define UNISOC_PRODUCT_UIS7720 0x4064/* Luat Air72*U series based on UNISOC UIS8910 uses UNISOC's vendor ID */ #define LUAT_PRODUCT_AIR720U 0x4e00
@@ -2466,6 +2467,7 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9291, 0xff, 0xff, 0x30) }, { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9291, 0xff, 0xff, 0x40) }, { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, TOZED_PRODUCT_LT70C, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, UNISOC_PRODUCT_UIS7720, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, LUAT_PRODUCT_AIR720U, 0xff, 0, 0) }, { USB_DEVICE_INTERFACE_CLASS(0x1bbb, 0x0530, 0xff), /* TCL IK512 MBIM */ .driver_info = NCTRL(1) },
Greg Kroah-Hartman
maintainerPATCH 60/84 USB: serial: option: add Quectel RG255C
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Reinhard Speyerer <[email protected]>
commit 89205c60c0fc96b73567a2e9fe27ee3f59d01193 upstream.
Add support for Quectel RG255C devices to complement commit 5c964c8a97c1 ("net: usb: qmi_wwan: add Quectel RG255C").
The composition is DM / NMEA / AT / QMI.
T: Bus=01 Lev=02 Prnt=99 Port=01 Cnt=02 Dev#=110 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0316 Rev= 5.15 S: Manufacturer=Quectel S: Product=RG255C-GL S: SerialNumber=xxxxxxxx C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -273,6 +273,7 @@ static void option_instat_callback(struc#define QUECTEL_PRODUCT_EM05CN 0x0312#define QUECTEL_PRODUCT_EM05G_GR 0x0313#define QUECTEL_PRODUCT_EM05G_RS 0x0314 +#define QUECTEL_PRODUCT_RG255C 0x0316#define QUECTEL_PRODUCT_EM12 0x0512#define QUECTEL_PRODUCT_RM500Q 0x0800#define QUECTEL_PRODUCT_RM520N 0x0801
@@ -1271,6 +1272,9 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM500K, 0xff, 0x00, 0x00) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0xff, 0x30) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0xff, 0x30) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0xff, 0x40) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
Greg Kroah-Hartman
maintainerPATCH 61/84 USB: serial: option: add Telit FN920C04 ECM compositions
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: LI Qingwu <[email protected]>
commit 622865c73ae30f254abdf182f4b66cccbe3e0f10 upstream.
Add support for the Telit Cinterion FN920C04 module when operating in ECM (Ethernet Control Model) mode. The following USB product IDs are used by the module when AT#USBCFG is set to 3 or 7.
0x10A3: ECM + tty (NMEA) + tty (DUN) [+ tty (DIAG)]
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a3 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
0x10A8: ECM + tty (DUN) + tty (AUX) [+ tty (DIAG)]
T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a8 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Adding these IDs allows the option driver to automatically create the corresponding /dev/ttyUSB* ports under ECM mode.
Tested with FN920C04 under ECM configuration (USBCFG=3 and 7).
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -1403,10 +1403,14 @@ static const struct usb_device_id option .driver_info = RSVD(0) | NCTRL(3) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a2, 0xff), /* Telit FN920C04 (MBIM) */ .driver_info = NCTRL(4) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a3, 0xff), /* Telit FN920C04 (ECM) */ + .driver_info = NCTRL(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a4, 0xff), /* Telit FN20C04 (rmnet) */ .driver_info = RSVD(0) | NCTRL(3) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a7, 0xff), /* Telit FN920C04 (MBIM) */ .driver_info = NCTRL(4) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a8, 0xff), /* Telit FN920C04 (ECM) */ + .driver_info = NCTRL(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a9, 0xff), /* Telit FN20C04 (rmnet) */ .driver_info = RSVD(0) | NCTRL(2) | RSVD(3) | RSVD(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10aa, 0xff), /* Telit FN920C04 (MBIM) */
Greg Kroah-Hartman
maintainerPATCH 62/84 usb/core/quirks: Add Huawei ME906S to wakeup quirk
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tim Guttzeit <[email protected]>
commit dfc2cf4dcaa03601cd4ca0f7def88b2630fca6ab upstream.
The list of Huawei LTE modules needing the quirk fixing spurious wakeups was missing the IDs of the Huawei ME906S module, therefore suspend did not work.
--- drivers/usb/core/quirks.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/core/quirks.c +2 -0
@@ -464,6 +464,8 @@ static const struct usb_device_id usb_qu/* Huawei 4G LTE module */ { USB_DEVICE(0x12d1, 0x15bb), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND }, + { USB_DEVICE(0x12d1, 0x15c1), .driver_info = + USB_QUIRK_DISCONNECT_SUSPEND }, { USB_DEVICE(0x12d1, 0x15c3), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND },
Greg Kroah-Hartman
maintainerPATCH 63/84 usb: raw-gadget: do not limit transfer length
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Konovalov <[email protected]>
commit 37b9dd0d114a0e38c502695e30f55a74fb0c37d0 upstream.
Drop the check on the maximum transfer length in Raw Gadget for both control and non-control transfers.
Limiting the transfer length causes a problem with emulating USB devices whose full configuration descriptor exceeds PAGE_SIZE in length.
Overall, there does not appear to be any reason to enforce any kind of transfer length limit on the Raw Gadget side for either control or non-control transfers, so let's just drop the related check.
--- drivers/usb/gadget/legacy/raw_gadget.c | 2 -- 1 file changed, 2 deletions(-)
drivers/usb/gadget/legacy/raw_gadget.c +0 -2
@@ -620,8 +620,6 @@ static void *raw_alloc_io_data(struct usreturn ERR_PTR (-EINVAL );if (!usb_raw_io_flags_valid (io->flags))return ERR_PTR (-EINVAL ); -if (io->length >PAGE_SIZE ) -return ERR_PTR (-EINVAL );if (get_from_user) data =memdup_user (ptr +sizeof (*io), io->length);else {
Greg Kroah-Hartman
maintainerPATCH 64/84 xhci: dbc: enable back DbC in resume if it was enabled before suspend
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 2bbd38fcd29670e46c0fdb9cd0e90507a8a1bf6a upstream.
DbC is currently only enabled back if it's in configured state during suspend.
If system is suspended after DbC is enabled, but before the device is properly enumerated by the host, then DbC would not be enabled back in resume.
Always enable DbC back in resume if it's suspended in enabled, connected, or configured state
--- drivers/usb/host/xhci-dbgcap.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-dbgcap.c +8 -1
@@ -1319,8 +1319,15 @@ int xhci_dbc_suspend(struct xhci_hcd *xhif (!dbc)return 0 ; -if (dbc->state ==DS_CONFIGURED ) +switch (dbc->state) { +case DS_ENABLED : +case DS_CONNECTED : +case DS_CONFIGURED : dbc->resume_required =1 ; +break ; +default : +break ; + }xhci_dbc_stop (dbc);
Greg Kroah-Hartman
maintainerPATCH 65/84 x86/microcode: Fix Entrysign revision check for Zen1/Naples
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Cooper <[email protected]>
commit 876f0d43af78639790bee0e57b39d498ae35adcf upstream.
... to match AMD's statement here:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
--- arch/x86/kernel/cpu/microcode/amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/microcode/amd.c +1 -1
@@ -184,7 +184,7 @@ static bool need_sha_check(u32 cur_rev) }switch (cur_rev >>8 ) { -case 0x80012 :return cur_rev <=0x800126f ;break ; +case 0x80012 :return cur_rev <=0x8001277 ;break ;case 0x80082 :return cur_rev <=0x800820f ;break ;case 0x83010 :return cur_rev <=0x830107c ;break ;case 0x86001 :return cur_rev <=0x860010e ;break ;
Greg Kroah-Hartman
maintainerPATCH 66/84 binder: remove "invalid inc weak" check
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alice Ryhl <[email protected]>
commit d90eeb8ecd227c204ab6c34a17b372bd950b7aa2 upstream.
There are no scenarios where a weak increment is invalid on binder_node. The only possible case where it could be invalid is if the kernel delivers BR_DECREFS to the process that owns the node, and then increments the weak refcount again, effectively "reviving" a dead node.
However, that is not possible: when the BR_DECREFS command is delivered, the kernel removes and frees the binder_node. The fact that you were able to call binder_inc_node_nilocked() implies that the node is not yet destroyed, which implies that BR_DECREFS has not been delivered to userspace, so incrementing the weak refcount is valid.
Note that it's currently possible to trigger this condition if the owner calls BINDER_THREAD_EXIT while node->has_weak_ref is true. This causes BC_INCREFS on binder_ref instances to fail when they should not.
--- drivers/android/binder.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-)
drivers/android/binder.c +1 -10
@@ -846,17 +846,8 @@ static int binder_inc_node_nilocked(stru }else {if (!internal) node->local_weak_refs++; -if (!node->has_weak_ref &&list_empty (&node->work.entry)) { -if (target_list ==NULL ) { -pr_err ("invalid inc weak node for %d\n" , - node->debug_id); -return -EINVAL ; - } -/* -* See comment above -*/ +if (!node->has_weak_ref && target_list &&list_empty (&node->work.entry))binder_enqueue_work_ilocked (&node->work, target_list); - } }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 67/84 comedi: fix divide-by-zero in comedi_buf_munge()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
commit 87b318ba81dda2ee7b603f4f6c55e78ec3e95974 upstream.
The comedi_buf_munge() function performs a modulo operation async->munge_chan %= async->cmd.chanlist_len without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path.
Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging.
This prevents potential kernel panics from malformed user commands.
--- drivers/comedi/comedi_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/comedi/comedi_buf.c +1 -1
@@ -368,7 +368,7 @@ static unsigned int comedi_buf_munge(strunsigned int count =0 ;const unsigned int num_sample_bytes =comedi_bytes_per_sample (s); -if (!s->munge || (async->cmd.flags &CMDF_RAWDATA )) { +if (!s->munge || (async->cmd.flags &CMDF_RAWDATA ) || async->cmd.chanlist_len ==0 ) { async->munge_count += num_bytes;return num_bytes; }
Greg Kroah-Hartman
maintainerPATCH 68/84 mei: me: add wildcat lake P DID
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Usyskin <[email protected]>
commit 410d6c2ad4d1a88efa0acbb9966693725b564933 upstream.
Add Wildcat Lake P device id.
--- drivers/misc/mei/hw-me-regs.h | 2 ++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 4 insertions(+)
drivers/misc/mei/hw-me-regs.h +2 -0
@@ -120,6 +120,8 @@#define MEI_DEV_ID_PTL_H 0xE370/* Panther Lake H */ #define MEI_DEV_ID_PTL_P 0xE470/* Panther Lake P */ +#define MEI_DEV_ID_WCL_P 0x4D70/* Wildcat Lake P */ +/* * MEI HW Section */
drivers/misc/mei/pci-me.c +2 -0
@@ -127,6 +127,8 @@ static const struct pci_device_id mei_me {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_H, MEI_ME_PCH15_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_P, MEI_ME_PCH15_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_WCL_P, MEI_ME_PCH15_CFG)}, +/* required last entry */ {0, } };
Greg Kroah-Hartman
maintainerPATCH 69/84 misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junhao Xie <[email protected]>
commit fff111bf45cbeeb659324316d68554e35d350092 upstream.
In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to the dma_buf for comparison purposes. However, this reference is never released when the function returns, leading to a dma_buf memory leak.
Fix this by adding dma_buf_put before returning from the function, ensuring that the temporarily acquired reference is properly released regardless of whether a matching map is found.
--- drivers/misc/fastrpc.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/misc/fastrpc.c +2 -0
@@ -383,6 +383,8 @@ static int fastrpc_map_lookup(struct fas }spin_unlock (&fl->lock); +dma_buf_put (buf); +return ret; }
Greg Kroah-Hartman
maintainerPATCH 70/84 most: usb: Fix use-after-free in hdm_disconnect
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victoria Votokina <[email protected]>
commit 4b1270902609ef0d935ed2faa2ea6d122bd148f5 upstream.
hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing.
The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts).
Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface().
This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.
--- drivers/most/most_usb.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
drivers/most/most_usb.c +4 -7
@@ -929,6 +929,10 @@ static void release_mdev(struct device * {struct most_dev *mdev =to_mdev_from_dev (dev); +kfree (mdev->busy_urbs); +kfree (mdev->cap); +kfree (mdev->conf); +kfree (mdev->ep_address);kfree (mdev); }/**
@@ -1121,13 +1125,6 @@ static void hdm_disconnect(struct usb_inif (mdev->dci)device_unregister (&mdev->dci->dev);most_deregister_interface (&mdev->iface); - -kfree (mdev->busy_urbs); -kfree (mdev->cap); -kfree (mdev->conf); -kfree (mdev->ep_address); -put_device (&mdev->dci->dev); -put_device (&mdev->dev); }static int hdm_suspend (struct usb_interface *interface,pm_message_t message)
Greg Kroah-Hartman
maintainerPATCH 71/84 most: usb: hdm_probe: Fix calling put_device() before device initialization
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victoria Votokina <[email protected]>
commit a8cc9e5fcb0e2eef21513a4fec888f5712cb8162 upstream.
The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject.
In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device.
This removes the WARNING and fixes the pre-initialization error path.
--- drivers/most/most_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/most/most_usb.c +1 -1
@@ -1097,7 +1097,7 @@ err_free_cap: err_free_conf:kfree (mdev->conf); err_free_mdev: -put_device (&mdev->dev); +kfree (mdev);return ret; }
Greg Kroah-Hartman
maintainerPATCH 72/84 tcpm: switch check for role_sw device with fw_node
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Grzeschik <[email protected]>
commit 2d8713f807a49b8a67c221670e50ae04967e915d upstream.
When there is no port entry in the tcpci entry itself, the driver will trigger an error message "OF: graph: no port node found in /...../typec" .
It is documented that the dts node should contain an connector entry with ports and several port pointing to devices with usb-role-switch property set. Only when those connector entry is missing, it should check for port entries in the main node.
We switch the search order for looking after ports, which will avoid the failure message while there are explicit connector entries.
--- drivers/usb/typec/tcpm/tcpm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/typec/tcpm/tcpm.c +2 -2
@@ -6636,9 +6636,9 @@ struct tcpm_port *tcpm_register_port(str port->partner_desc.identity = &port->partner_ident; port->port_type = port->typec_caps.type; - port->role_sw =usb_role_switch_get (port->dev); + port->role_sw =fwnode_usb_role_switch_get (tcpc->fwnode);if (!port->role_sw) - port->role_sw =fwnode_usb_role_switch_get (tcpc->fwnode); + port->role_sw =usb_role_switch_get (port->dev);if (IS_ERR (port->role_sw)) { err =PTR_ERR (port->role_sw); goto out_destroy_wq;
Greg Kroah-Hartman
maintainerPATCH 73/84 dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xu Yang <[email protected]>
commit 268eb6fb908bc82ce479e4dba9a2cad11f536c9c upstream.
Only i.MX8MP need dma-range property to let USB controller work properly. Remove dma-range from required list and add limitation for imx8mp.
--- Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +9 -1
@@ -85,13 +85,21 @@ required: - reg - "#address-cells" - "#size-cells" - - dma-ranges - ranges - clocks - clock-names - interrupts - power-domains +allOf: + - if: + properties: + compatible: + const: fsl,imx8mp-dwc3 + then: + required: + - dma-ranges + additionalProperties: false examples:
Greg Kroah-Hartman
maintainerPATCH 74/84 serial: 8250_dw: handle reset control deassert error
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Shimko <[email protected]>
commit daeb4037adf7d3349b4a1fb792f4bc9824686a4b upstream.
Check the return value of reset_control_deassert() in the probe function to prevent continuing probe when reset deassertion fails.
Previously, reset_control_deassert() was called without checking its return value, which could lead to probe continuing even when the device reset wasn't properly deasserted.
The fix checks the return value and returns an error with dev_err_probe() if reset deassertion fails, providing better error handling and diagnostics.
--- drivers/tty/serial/8250/8250_dw.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/tty/serial/8250/8250_dw.c +3 -1
@@ -653,7 +653,9 @@ static int dw8250_probe(struct platform_if (IS_ERR (data->rst))return PTR_ERR (data->rst); -reset_control_deassert (data->rst); + err =reset_control_deassert (data->rst); +if (err) +return dev_err_probe (dev, err,"failed to deassert resets\n" ); err =devm_add_action_or_reset (dev, dw8250_reset_control_assert, data->rst);if (err)
Greg Kroah-Hartman
maintainerPATCH 75/84 serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Eckert <[email protected]>
commit e7cbce761fe3fcbcb49bcf30d4f8ca5e1a9ee2a0 upstream.
The Advantech 2-port serial card with PCI vendor=0x13fe and device=0x0018 has a 'XR17V35X' chip installed on the circuit board. Therefore, this driver can be used instead of theu outdated out-of-tree driver from the manufacturer.
--- drivers/tty/serial/8250/8250_exar.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/tty/serial/8250/8250_exar.c +11 -0
@@ -33,6 +33,8 @@#define PCI_DEVICE_ID_ACCESSIO_COM_4SM 0x10db#define PCI_DEVICE_ID_ACCESSIO_COM_8SM 0x10ea +#define PCI_DEVICE_ID_ADVANTECH_XR17V352 0x0018 +#define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002#define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004#define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
@@ -845,6 +847,12 @@ static const struct exar8250_board pbn_f .exit = pci_xr17v35x_exit, }; +static const struct exar8250_board pbn_adv_XR17V352 = { + .num_ports =2 , + .setup = pci_xr17v35x_setup, + .exit = pci_xr17v35x_exit, +}; +static const struct exar8250_board pbn_exar_XR17V4358 = { .num_ports =12 , .setup = pci_xr17v35x_setup,
@@ -914,6 +922,9 @@ static const struct pci_device_id exar_pUSR_DEVICE (XR17C152 ,2980 , pbn_exar_XR17C15x),USR_DEVICE (XR17C152 ,2981 , pbn_exar_XR17C15x), +/* ADVANTECH devices */ +EXAR_DEVICE (ADVANTECH ,XR17V352 , pbn_adv_XR17V352), +/* Exar Corp. XR17C15[248] Dual/Quad/Octal UART */ EXAR_DEVICE (EXAR ,XR17C152 , pbn_exar_XR17C15x), EXAR_DEVICE(EXAR, XR17C154, pbn_exar_XR17C15x),
Greg Kroah-Hartman
maintainerPATCH 76/84 serial: 8250_mtk: Enable baud clock and manage in runtime PM
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Golle <[email protected]>
commit d518314a1fa4e980a227d1b2bda1badf433cb932 upstream.
Some MediaTek SoCs got a gated UART baud clock, which currently gets disabled as the clk subsystem believes it would be unused. This results in the uart freezing right after "clk: Disabling unused clocks" on those platforms.
Request the baud clock to be prepared and enabled during probe, and to restore run-time power management capabilities to what it was before commit e32a83c70cf9 ("serial: 8250-mtk: modify mtk uart power and clock management") disable and unprepare the baud clock when suspending the UART, prepare and enable it again when resuming it.
--- drivers/tty/serial/8250/8250_mtk.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_mtk.c +4 -2
@@ -435,6 +435,7 @@ static int __maybe_unused mtk8250_runtimwhile (serial_in (up,MTK_UART_DEBUG0 )); +clk_disable_unprepare (data->uart_clk);clk_disable_unprepare (data->bus_clk);return 0 ;
@@ -445,6 +446,7 @@ static int __maybe_unused mtk8250_runtimstruct mtk8250_data *data =dev_get_drvdata (dev);clk_prepare_enable (data->bus_clk); +clk_prepare_enable (data->uart_clk);return 0 ; }
@@ -475,13 +477,13 @@ static int mtk8250_probe_of(struct platfint dmacnt;#endif - data->uart_clk =devm_clk_get (&pdev->dev,"baud" ); + data->uart_clk =devm_clk_get_enabled (&pdev->dev,"baud" );if (IS_ERR (data->uart_clk)) {/* * For compatibility with older device trees try unnamed * clk when no baud clk can be found. */ - data->uart_clk =devm_clk_get (&pdev->dev,NULL ); + data->uart_clk =devm_clk_get_enabled (&pdev->dev,NULL );if (IS_ERR (data->uart_clk)) {dev_warn (&pdev->dev,"Can't get uart clock\n" );return PTR_ERR (data->uart_clk);
Greg Kroah-Hartman
maintainerPATCH 77/84 devcoredump: Fix circular locking dependency with devcd->mutex.
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maarten Lankhorst <[email protected]>
[ 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.
--- drivers/base/devcoredump.c | 138 +++++++++++++++++++++++++++------------------ 1 file changed, 84 insertions(+), 54 deletions(-)
drivers/base/devcoredump.c +84 -54
@@ -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 devkfree (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 fstruct 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(const struc* 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.
@@ -352,7 +369,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);
@@ -361,8 +378,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;
@@ -379,13 +402,20 @@ void dev_coredumpm(struct device *dev, sdev_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:
Greg Kroah-Hartman
maintainerPATCH 78/84 xfs: always warn about deprecated mount options
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Darrick J. Wong" <[email protected]>
[ Upstream commit 630785bfbe12c3ee3ebccd8b530a98d632b7e39d ]
The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs.
Fix this by making it complain all the time.
--- fs/xfs/xfs_super.c | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-)
fs/xfs/xfs_super.c +21 -12
@@ -1230,16 +1230,25 @@ suffix_kstrtoint(static inline void xfs_fs_warn_deprecated (struct fs_context *fc, -struct fs_parameter *param, -uint64_t flag, -bool value) +struct fs_parameter *param) { -/* Don't print the warning if reconfiguring and current mount point -* already had the flag set +/* +* Always warn about someone passing in a deprecated mount option. +* Previously we wouldn't print the warning if we were reconfiguring +* and current mount point already had the flag set, but that was not +* the right thing to do. +* +* Many distributions mount the root filesystem with no options in the +* initramfs and rely on mount -a to remount the root fs with the +* options in fstab. However, the old behavior meant that there would +* never be a warning about deprecated mount options for the root fs in +* /etc/fstab. On a single-fs system, that means no warning at all. +* +* Compounding this problem are distribution scripts that copy +* /proc/mounts to fstab, which means that we can't remove mount +* options unless we're 100% sure they have only ever been advertised +* in /proc/mounts in response to explicitly provided mount options. */ -if ((fc->purpose &FS_CONTEXT_FOR_RECONFIGURE ) && - !!(XFS_M (fc->root->d_sb)->m_features & flag) == value) -return ;xfs_warn (fc->s_fs_info,"%s mount option is deprecated." , param->key); }
@@ -1378,19 +1387,19 @@ xfs_fs_parse_param(#endif /* Following mount options will be removed in September 2025 */ case Opt_ikeep: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_IKEEP , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_IKEEP ;return 0 ;case Opt_noikeep: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_IKEEP , false); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features &= ~XFS_FEAT_IKEEP ;return 0 ;case Opt_attr2: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_ATTR2 , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_ATTR2 ;return 0 ;case Opt_noattr2: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_NOATTR2 , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_NOATTR2 ;return 0 ;default :
Greg Kroah-Hartman
maintainerPATCH 79/84 fs/notify: call exportfs_encode_fid with s_umount
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Acs <[email protected]>
[ Upstream commit a7c4bb43bfdc2b9f06ee9d036028ed13a83df42a ]
Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr.
This issue was found by syzkaller.
Race Condition Diagram:
Thread 1 Thread 2
-------- --------
generic_shutdown_super()
shrink_dcache_for_umount
sb->s_root = NULL
|
| vfs_read()
| inotify_fdinfo()
| * inode get from mark *
| show_mark_fhandle(m, inode)
| exportfs_encode_fid(inode, ..)
| ovl_encode_fh(inode, ..)
| ovl_check_encode_origin(inode)
| * deref i_sb->s_root *
|
| v
fsnotify_sb_delete(sb)
Which then leads to:
[ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)
<snip registers, unreliable trace>
[ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240
IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path.
Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock.
This form of fix was suggested by Amir in [1].
[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/
--- fs/notify/fdinfo.c | 6 ++++++ 1 file changed, 6 insertions(+)
fs/notify/fdinfo.c +6 -0
@@ -17,6 +17,7 @@#include "fanotify/fanotify.h" #include "fdinfo.h" #include "fsnotify.h" +#include "../internal.h" #if defined(CONFIG_PROC_FS )
@@ -50,7 +51,12 @@ static void show_mark_fhandle(struct seq f.handle.handle_bytes =sizeof (f.pad); size = f.handle.handle_bytes >>2 ; +if (!super_trylock_shared (inode->i_sb)) +return ; + ret =exportfs_encode_fid (inode, (struct fid *)f.handle.f_handle, &size); +up_read (&inode->i_sb->s_umount); +if ((ret ==FILEID_INVALID ) || (ret <0 ))return ;
Greg Kroah-Hartman
maintainerPATCH 80/84 x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Babu Moger <[email protected]>
commit 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 upstream.
Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state.
When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked.
resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked.
This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter).
Reset the stored value (arch_mbm_state::prev_msr) of MSR_IA32_QM_CTR to zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again.
Example scenario that results in mistaken overflow
==================================================
1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group.
$mount -t resctrl resctrl /sys/fs/resctrl $mkdir /sys/fs/resctrl/mon_groups/test1/ $echo 1234 > /sys/fs/resctrl/mon_groups/test1/tasks
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
21323 <- Total bytes on domain 0
"Unavailable" <- Total bytes on domain 1
Task is running on domain 0. Counter on domain 1 is "Unavailable".
2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1.
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
7345357 <- Total bytes on domain 0
4545 <- Total bytes on domain 1
3. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain.
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
"Unavailable" <- Total bytes on domain 0
434341 <- Total bytes on domain 1
4. Since the task continues to migrate between domains, it may eventually return to domain 0.
$cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 17592178699059 <- Overflow on domain 0
3232332 <- Total bytes on domain 1
In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0.
Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta.
In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state.
Here is the text from APM [1] available from [2].
"In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first QM_CTR read when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, a QM_CTR read with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read."
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM).
[ bp: Split commit message into smaller paragraph chunks for better
consumption. ]
--- arch/x86/kernel/cpu/resctrl/monitor.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/resctrl/monitor.c +6 -2
@@ -241,11 +241,15 @@ int resctrl_arch_rmid_read(struct rdt_reif (!cpumask_test_cpu (smp_processor_id (), &d->cpu_mask))return -EINVAL ; + am =get_arch_mbm_state (hw_dom, rmid, eventid); + ret =__rmid_read (rmid, eventid, &msr_val); -if (ret) +if (ret) { +if (am && ret == -EINVAL ) + am->prev_msr =0 ;return ret; + } - am =get_arch_mbm_state (hw_dom, rmid, eventid);if (am) { am->chunks +=mbm_overflow_count (am->prev_msr, msr_val, hw_res->mbm_width);
Re: [PATCH 6.6 80/84] x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID
Quoted 99 lines · Greg Kroah-Hartman
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Babu Moger <[email protected]>
commit
15292f1b4c55a3a7c940dbcb6cb8793871ed3d92upstream.Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state.
When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked.
resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked.
This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter).
Reset the stored value (
arch_mbm_state::prev_msr) ofMSR_IA32_QM_CTRto zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again.Example scenario that results in mistaken overflow
==================================================
1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group.$mount -t resctrl resctrl
/sys/fs/resctrl$mkdir/sys/fs/resctrl/mon_groups/test1/$echo 1234 >/sys/fs/resctrl/mon_groups/test1/tasks$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
21323 <- Total bytes on domain 0
"Unavailable" <- Total bytes on domain 1Task is running on domain 0. Counter on domain 1 is "Unavailable".
2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1.
$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
7345357 <- Total bytes on domain 0
4545 <- Total bytes on domain 13. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain.
$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
"Unavailable" <- Total bytes on domain 0
434341 <- Total bytes on domain 14. Since the task continues to migrate between domains, it may eventually return to domain 0.
$cat
/sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes17592178699059 <- Overflow on domain 0
3232332 <- Total bytes on domain 1In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0.
Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta.
In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state.
Here is the text from APM [1] available from [2].
"In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first
QM_CTRread when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, aQM_CTRread with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read."[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM).
[ bp: Split commit message into smaller paragraph chunks for better
consumption. ]
Quoted 9 lines
Fixes 4d05bf71f157d ("x86/resctrl: Introduce AMD QOS feature")Signed-off-by Babu Moger <[email protected]>Signed-off-by Borislav Petkov (AMD) <[email protected]>Reviewed-by Reinette Chatre <[email protected]>Tested-by Reinette Chatre <[email protected]>Cc [email protected] # needs adjustments for <= v6.17[[email protected]: Fix conflict for v6.6 stable]Signed-off-by Greg Kroah-Hartman <[email protected]>
Thanks
Babu Moger
Greg Kroah-Hartman
maintainerPATCH 81/84 s390/cio: Update purge function to unregister the unused subchannels
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vineeth Vijayan <[email protected]>
commit 9daa5a8795865f9a3c93d8d1066785b07ded6073 upstream.
Starting with 'commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")', cio no longer unregisters subchannels when the attached device is invalid or unavailable.
As an unintended side-effect, the cio_ignore purge function no longer removes subchannels for devices on the cio_ignore list if no CCW device is attached. This situation occurs when a CCW device is non-operational or unavailable
To ensure the same outcome of the purge function as when the current cio_ignore list had been active during boot, update the purge function to remove I/O subchannels without working CCW devices if the associated device number is found on the cio_ignore list.
--- drivers/s390/cio/device.c | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-)
drivers/s390/cio/device.c +25 -14
@@ -1318,23 +1318,34 @@ void ccw_device_schedule_recovery(void)spin_unlock_irqrestore (&recovery_lock, flags); } -static int purge_fn (struct device *dev,void *data) +static int purge_fn (struct subchannel *sch,void *data) { -struct ccw_device *cdev =to_ccwdev (dev); -struct ccw_dev_id *id = &cdev->private->dev_id; -struct subchannel *sch =to_subchannel (cdev->dev.parent); - -spin_lock_irq (cdev->ccwlock); -if (is_blacklisted (id->ssid, id->devno) && - (cdev->private->state ==DEV_STATE_OFFLINE ) && - (atomic_cmpxchg (&cdev->private->onoff,0 ,1 ) ==0 )) { -CIO_MSG_EVENT (3 ,"ccw: purging 0.%x.%04x\n" , id->ssid, - id->devno); +struct ccw_device *cdev; + +spin_lock_irq (sch->lock); +if (sch->st !=SUBCHANNEL_TYPE_IO || !sch->schib.pmcw.dnv) + goto unlock; + +if (!is_blacklisted (sch->schid.ssid, sch->schib.pmcw.dev)) + goto unlock; + + cdev =sch_get_cdev (sch); +if (cdev) { +if (cdev->private->state !=DEV_STATE_OFFLINE ) + goto unlock; + +if (atomic_cmpxchg (&cdev->private->onoff,0 ,1 ) !=0 ) + goto unlock;ccw_device_sched_todo (cdev,CDEV_TODO_UNREG ); -css_sched_sch_todo (sch,SCH_TODO_UNREG );atomic_set (&cdev->private->onoff,0 ); } -spin_unlock_irq (cdev->ccwlock); + +css_sched_sch_todo (sch,SCH_TODO_UNREG ); +CIO_MSG_EVENT (3 ,"ccw: purging 0.%x.%04x%s\n" , sch->schid.ssid, + sch->schib.pmcw.dev, cdev ?"" :" (no cdev)" ); + +unlock: +spin_unlock_irq (sch->lock);/* Abort loop in case of pending signal. */ if (signal_pending (current))return -EINTR ;
@@ -1350,7 +1361,7 @@ static int purge_fn(struct device *dev,int ccw_purge_blacklisted (void ) {CIO_MSG_EVENT (2 ,"ccw: purging blacklisted devices\n" ); -bus_for_each_dev (&ccw_bus_type,NULL ,NULL , purge_fn); +for_each_subchannel_staged (purge_fn,NULL ,NULL );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 82/84 fuse: allocate ff->release_args only if release is needed
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amir Goldstein <[email protected]>
[ Upstream commit e26ee4efbc79610b20e7abe9d96c87f33dacc1ff ]
This removed the need to pass isdir argument to fuse_put_file().
Stable-dep-of: 26e5c67deb2e ("fuse: fix livelock in synchronous file put from fuseblk workers")
--- fs/fuse/dir.c | 2 - fs/fuse/file.c | 69 +++++++++++++++++++++++++++++++------------------------ fs/fuse/fuse_i.h | 2 - 3 files changed, 41 insertions(+), 32 deletions(-)
fs/fuse/dir.c +1 -1
@@ -634,7 +634,7 @@ static int fuse_create_open(struct inode goto out_err; err = -ENOMEM ; - ff =fuse_file_alloc (fm); + ff =fuse_file_alloc (fm, true);if (!ff) goto out_put_forget_req;
fs/fuse/file.c +39 -30
177 lines not on this page · raw message
fs/fuse/fuse_i.h +1 -1
@@ -1036,7 +1036,7 @@ void fuse_read_args_fill(struct fuse_io_*/ int fuse_open_common (struct inode *inode,struct file *file,bool isdir); -struct fuse_file *fuse_file_alloc (struct fuse_mount *fm); +struct fuse_file *fuse_file_alloc (struct fuse_mount *fm,bool release);void fuse_file_free (struct fuse_file *ff);void fuse_finish_open (struct inode *inode,struct file *file);
Greg Kroah-Hartman
maintainerPATCH 83/84 fuse: fix livelock in synchronous file put from fuseblk workers
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Darrick J. Wong" <[email protected]>
[ Upstream commit 26e5c67deb2e1f42a951f022fdf5b9f7eb747b01 ]
I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server:
# cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
But the /weird/ part is that the fuseblk server threads are waiting for responses from itself:
# cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that:
"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.
--- fs/fuse/file.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
fs/fuse/file.c +7 -1
@@ -339,8 +339,14 @@ void fuse_file_release(struct inode *ino* Make the release synchronous if this is a fuseblk mount, * synchronous RELEASE is allowed (and desirable) in this case * because the server can be trusted not to screw up. +* +* Always use the asynchronous file put because the current thread +* might be the fuse server. This can happen if a process starts some +* aio and closes the fd before the aio completes. Since aio takes its +* own ref to the file, the IO completion has to drop the ref, which is +* how the fuse server can end up closing its clients' files. */ -fuse_file_put (ff, ff->fm->fc->destroy); +fuse_file_put (ff, false); }void fuse_release_common (struct file *file,bool isdir)
Greg Kroah-Hartman
maintainerPATCH 84/84 gpio: ljca: Initialize num before accessing item in ljca_gpio_config
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoyu Li <[email protected]>
commit 3396995f9fb6bcbe0004a68118a22f98bab6e2b9 upstream.
With the new __counted_by annocation in ljca_gpio_packet, the "num" struct member must be set before accessing the "item" array. Failing to do so will trigger a runtime warning when enabling CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE.
--- drivers/gpio/gpio-ljca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-ljca.c +1 -1
@@ -82,9 +82,9 @@ static int ljca_gpio_config(struct ljca_int ret;mutex_lock (&ljca_gpio->trans_lock); + packet->num =1 ; packet->item[0 ].index = gpio_id; packet->item[0 ].value = config | ljca_gpio->connect_mode[gpio_id]; - packet->num =1 ; ret =ljca_transfer (ljca_gpio->ljca,LJCA_GPIO_CONFIG , (u8 *)packet,struct_size (packet, item, packet->num),NULL ,0 );
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.115-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.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:
Signature · 1 line
Florian
Am 27.10.2025 um 19:35 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.115-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.6:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.6.115-rc1-g6de03dd48e80
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-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.115-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.115-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.6.115-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 6de03dd48e80ed63781bdc986cd9895c1172a6b1
* git describe: v6.6.113-190-g6de03dd48e80
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.113-190-g6de03dd48e80
## Test Regressions (compared to v6.6.113-106-g8ed83e981d68)
## Metric Regressions (compared to v6.6.113-106-g8ed83e981d68)
## Test Fixes (compared to v6.6.113-106-g8ed83e981d68)
## Metric Fixes (compared to v6.6.113-106-g8ed83e981d68)
## Test result summary
total: 105308, pass: 89135, fail: 2925, skip: 13018, xfail: 230
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 129 total, 128 passed, 1 failed
* arm64: 44 total, 40 passed, 4 failed
* i386: 23 total, 23 passed, 0 failed
* mips: 26 total, 25 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 32 total, 31 passed, 1 failed
* riscv: 15 total, 14 passed, 1 failed
* s390: 14 total, 13 passed, 1 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 7 total, 7 passed, 0 failed
* x86_64: 37 total, 34 passed, 3 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.6.115-rc1-g6de03dd48e80 #120 SMP PREEMPT_DYNAMIC Tue Oct 28 13:31:36 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.115-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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.
6.6.115-rc1 built and run on x86_64 test system with no errors or regressions:
Thanks,
Slade
Quoted 8 lines · On Mon, 27 Oct 2025 19:35:49 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.6.115 release. There are 84 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.
Boot-tested under QEMU for Rust x86_64:
Thanks!
Cheers,
Miguel