- Linux-stable-mirror - lists.linaro.org

[PATCH] perf: arm_cspmu: fix error handling in arm_cspmu_impl_unregister()

by Ma Ke

driver_find_device() calls get_device() to increment the reference count once a matching device is found. device_release_driver() releases the driver, but it does not decrease the reference count that was incremented by driver_find_device(). At the end of the loop, there is no put_device() to balance the reference count. To avoid reference count leakage, add put_device() to decrease the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: bfc653aa89cb ("perf: arm_cspmu: Separate Arm and vendor module") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/perf/arm_cspmu/arm_cspmu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c index efa9b229e701..e0d4293f06f9 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c @@ -1365,8 +1365,10 @@ void arm_cspmu_impl_unregister(const struct arm_cspmu_impl_match *impl_match) /* Unbind the driver from all matching backend devices. */ while ((dev = driver_find_device(&arm_cspmu_driver.driver, NULL, - match, arm_cspmu_match_device))) + match, arm_cspmu_match_device))) { device_release_driver(dev); + put_device(dev); + } mutex_lock(&arm_cspmu_lock); -- 2.17.1

1 month

2
1
0 0

Qualcomm Inventory Updated

by Alan Ye

The following are all Qualcomm's stock, original and authentic. If you need them, please contact us. Snapdragon骁龙 WIFI-5G/6G MPN QTY date code MPN QTY date code SM-6225-0-PSP807-TR-00-0-AB 8000 22+ IPQ5018-0-MRQFN232-MT-01-0 36000 22+ PM-6225-0-FOWNSP144-TR-01-0 8000 22+ QCN6102-0-DRQFN116-TR-01-0 30000 22+ WCD9375-0-WLPSP55-TR-01-3 8000 22+ QCA8337-AL3C 25000 22+ WTR3925-2-106BWLPSP-TR-03-1 8000 22+ WCN-3950-0-58WLPSP-TR-05-2 8000 22+ IPQ-6000-0-FCBGA570-TR-00-0 10000 22+ QCA-8072-0-108DRQFN-MT-00-0 10000 22+ QCM-6490-1-PSP1287-TR-00-0-AA E 12000 23+ QCN-5022-0-DRQFN100B-TR-00-0 10000 22+ PMK-7325-1-1-FOWPSP36-MT-01-0 12000 23+ QCN-5052-0-DRQFN100B-TR-00-0 10000 22+ PM-7325-0-WLNSP120B-TR-00-0 12000 23+ PM-7350C-0-FOWNSP143-MT-02-0 12000 23+ IPQ-6010-0-FCBGA570-TR-00-0 8000 22+ PM-7250B-2-FOWPSP110-TR-00-0 12000 23+ QCA-8075-0-108DRQFN-MT-01-0 8000 22+ WCD-9370-0-WLPSP55-TR-01-0 12000 23+ QCN-5052-0-DRQFN100B-TR-00-0 8000 22+ PM-8008-0-WLPSP20-TR-X0-0 12000 23+ QCN-5021-0-DRQFN100B-TR-03-0 8000 22+ SDR-735-0-PSP219B-TR-001-0 12000 23+ WCN-6750-0-PSP229-TR-01-0 12000 23+ QCA-9886-0-100DRQFN-MT-04-0 14000 22+ QCA9563-AL3A 14000 22+ SDM-450-B-792NSP-TR-01-0-AA 20000 24+ QCA8334-AL3C 14000 22+ WTR-2965-0-59F0WNSP-TR-07-1 20000 24+ PMI-8952-0-144WLNSP-TR-02-0-00 20000 24+ IPQ-5322-0-MRQFN251-MT-00-0 6000 24+ WCN-3680B-0-79BWLNSP-TR-05-1 20000 24+ QCN-6274-0-MSP264-MT-01-0 6000 24+ PM-8953-0-187F0WNSP-TR-01-1 20000 24+ QCA-8385-0-DRQFN172-MT-00-0 6000 24 SDM-660-3-692NSP-TR-01-0-A 28000 23+ IPQ-4018-0-180DRQFN-MT-00-0 150000 22+ PM-660-0-219WLPSP-TR-01-1-01 28000 23+ QCA-8072-0-108DRQFN-MT-00-0 100000 22+ PM-660L-0-196WLPSP-TR-04-0-01 28000 23+ SDR-660-0-180WLPSP-TR-03-0 28000 23+ QCN-9024-0-MSP234-TR-01-0 5000 23+ QET-4101-0-12WLNSP-HR-00-0 28000 23+ QCN-6024-0-MSP234-MT-01-0 20000 22+ WCN-3980-0-82BWLPSP-TR-0B-0 28000 23+ QCA-8081-0-56MQFN-MT-02-0 28000 22+ QCN-9074-0-MSP234-TR-01-0 8000 23+ QCM-2290-0-NSP752-TR-00-0 10000 24+ QCA-9377-3-115WLNSP-TR-03-0 10000 22+ PM-8008-0-WLPSP20-TR-X0-0 10000 24+ QCA-1023-0-115WLNSP-TR-03-0 20000 24+ WCN-3950-0-58WLPSP-TR-05-3 10000 24+ QCC-5181-0-WLNSP99-TR-05-0 10000 24+ PM-4125-3-NSP194-TR-01-0 10000 24+ QCC-5127-0-124CSP-TR-00-0 8000 23+ CSR8670C-ICXT-R 10000 23+ MSM-8909-2-504NSP-TR-01-1-AA 50000 22+ CSR8675C-IBBH-R 10000 23+ WCN-3660B-0-79BWLNSP-TR-05-1 50000 22+ AR8033-AL1A 25000 23+ PM-8909-0-152NSP-TR-01-0-02 50000 22+ AR8035-AL1A 45000 22+ WTR-4905-1-60WLNSP-TR-01-1 50000 22+ AR8031-AL1B 15000 22+ If you have other MPN requirements, please let me know and I will check the latest inventory status for you. We also recycle Qualcomm's excess inventory to help you solve the depreciation risk faced by electronic components Best Secure your updates and feature insights at . Continue Product News Wish to step back? Quickly hit Control Contact Settings.

1 month

1
0
0 0

[PATCH net-next 00/15] mptcp: pm: special case for c-flag + luminar endp

by Matthieu Baerts (NGI0)

Here are some patches for the MPTCP PM, including some refactoring that I thought it would be best to send at the end of a cycle to avoid conflicts between net and net-next that could last a few weeks. The most interesting changes are in the first and last patch, the rest are patches refactoring the code & tests to validate the modifications. - Patches 1 & 2: When servers set the C-flag in their MP_CAPABLE to tell clients not to create subflows to the initial address and port -- e.g. a deployment behind a L4 load balancer like a typical CDN deployment -- clients will not use their other endpoints when default settings are used. That's because the in-kernel path-manager uses the 'subflow' endpoints to create subflows only to the initial address and port. The first patch fixes that (for >=v5.14), and the second one validates it. - Patches 3-14: various patches refactoring the code around the in-kernel PM (mainly): split too long functions, rename variables and functions to avoid confusions, reduce structure size, and compare IDs instead of IP addresses. Note that one patch modifies one internal variable used in one BPF selftest. - Patch 15: ability to control endpoints that are used in reaction to a new address announced by the other peer. With that, endpoints can be used only once. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Notes: - Patches 1 & 2 are sent to net-next on purpose: to delay a bit the backports, just in case. Plus we are at the end of a cycle, and not to delay the other refactoring patches. - Sorry, I wanted to send this series earlier on, but due to some unrelated issues (and holiday), it got delayed. Most patches are pure refactoring ones. --- Matthieu Baerts (NGI0) (15): mptcp: pm: in-kernel: usable client side with C-flag selftests: mptcp: join: validate C-flag + def limit mptcp: pm: in-kernel: refactor fill_local_addresses_vec mptcp: pm: in-kernel: refactor fill_remote_addresses_vec mptcp: pm: rename 'subflows' to 'extra_subflows' mptcp: pm: in-kernel: rename 'subflows_max' to 'limit_extra_subflows' mptcp: pm: in-kernel: rename 'add_addr_signal_max' to 'endp_signal_max' mptcp: pm: in-kernel: rename 'add_addr_accept_max' to 'limit_add_addr_accepted' mptcp: pm: in-kernel: rename 'local_addr_max' to 'endp_subflow_max' mptcp: pm: in-kernel: rename 'local_addr_list' to 'endp_list' mptcp: pm: in-kernel: rename 'addrs' to 'endpoints' mptcp: pm: in-kernel: remove stale_loss_cnt mptcp: pm: in-kernel: reduce pernet struct size mptcp: pm: in-kernel: compare IDs instead of addresses mptcp: pm: in-kernel: add laminar endpoints include/uapi/linux/mptcp.h | 11 +- net/mptcp/pm.c | 32 +- net/mptcp/pm_kernel.c | 569 ++++++++++++++-------- net/mptcp/pm_userspace.c | 2 +- net/mptcp/protocol.h | 21 +- net/mptcp/sockopt.c | 22 +- tools/testing/selftests/bpf/progs/mptcp_subflow.c | 2 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 11 + 8 files changed, 441 insertions(+), 229 deletions(-) --- base-commit: a1f1f2422e098485b09e55a492de05cf97f9954d change-id: 20250925-net-next-mptcp-c-flag-laminar-f8442e4d4bd9 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

1 month

2
3
0 0

+ squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: Squashfs: reject negative file sizes in squashfs_read_inode() has been added to the -mm mm-nonmm-unstable branch. Its filename is squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Phillip Lougher <phillip(a)squashfs.org.uk> Subject: Squashfs: reject negative file sizes in squashfs_read_inode() Date: Fri, 26 Sep 2025 22:59:35 +0100 Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. Link: https://lkml.kernel.org/r/20250926215935.107233-1-phillip@squashfs.org.uk Fixes: 6545b246a2c8 ("Squashfs: inode operations") Signed-off-by: Phillip Lougher <phillip(a)squashfs.org.uk> Reported-by: syzbot+f754e01116421e9754b9(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68d580e5.a00a0220.303701.0019.GAE@google.com/ Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/squashfs/inode.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) --- a/fs/squashfs/inode.c~squashfs-reject-negative-file-sizes-in-squashfs_read_inode +++ a/fs/squashfs/inode.c @@ -145,6 +145,10 @@ int squashfs_read_inode(struct inode *in goto failed_read; inode->i_size = le32_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } frag = le32_to_cpu(sqsh_ino->fragment); if (frag != SQUASHFS_INVALID_FRAG) { /* @@ -197,6 +201,10 @@ int squashfs_read_inode(struct inode *in goto failed_read; inode->i_size = le64_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } frag = le32_to_cpu(sqsh_ino->fragment); if (frag != SQUASHFS_INVALID_FRAG) { /* @@ -249,8 +257,12 @@ int squashfs_read_inode(struct inode *in if (err < 0) goto failed_read; - set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); inode->i_size = le16_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } + set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); inode->i_op = &squashfs_dir_inode_ops; inode->i_fop = &squashfs_dir_ops; inode->i_mode |= S_IFDIR; @@ -273,9 +285,13 @@ int squashfs_read_inode(struct inode *in if (err < 0) goto failed_read; + inode->i_size = le32_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } xattr_id = le32_to_cpu(sqsh_ino->xattr); set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); - inode->i_size = le32_to_cpu(sqsh_ino->file_size); inode->i_op = &squashfs_dir_inode_ops; inode->i_fop = &squashfs_dir_ops; inode->i_mode |= S_IFDIR; @@ -302,7 +318,7 @@ int squashfs_read_inode(struct inode *in goto failed_read; inode->i_size = le32_to_cpu(sqsh_ino->symlink_size); - if (inode->i_size > PAGE_SIZE) { + if (inode->i_size < 0 || inode->i_size > PAGE_SIZE) { ERROR("Corrupted symlink\n"); return -EINVAL; } _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are squashfs-fix-uninit-value-in-squashfs_get_parent.patch squashfs-add-additional-inode-sanity-checking.patch squashfs-add-seek_data-seek_hole-support.patch squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch

1 month

1
0
0 0

[PATCH] drm: mipi-dsi: Fix an API misuse in mipi_dsi_device_register_full()

by Haoxiang Li

mipi_dsi_device_alloc() calls device_initialize() to initialize value "&dsi->dev". Thus "dsi" should be freed using put_device() in error handling path. Fixes: 068a00233969 ("drm: Add MIPI DSI bus support") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- drivers/gpu/drm/drm_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index 3a9b3278a6e3..21d9aa29ac34 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -233,7 +233,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host, ret = mipi_dsi_device_add(dsi); if (ret) { dev_err(host->dev, "failed to add DSI device %d\n", ret); - kfree(dsi); + put_device(&dsi->dev); return ERR_PTR(ret); } -- 2.25.1

1 month

2
1
0 0

[PATCH v2 0/3] ext4: Add support for mounted updates to the superblock via an ioctl

by Theodore Ts'o via B4 Relay

This patch series enables a future version of tune2fs to be able to modify certain parts of the ext4 superblock without to write to the block device. The first patch fixes a potential buffer overrun caused by a maliciously moified superblock. The second patch adds support for 32-bit uid and gid's which can have access to the reserved blocks pool. The last patch adds the ioctl's which will be used by tune2fs. Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> --- Changes in v2: - fix bugs that were detected using sparse - remove tune (unsafe) ability to clear certain compat faatures - add the ability to set the encoding and encoding flags for case folding - Link to v1: https://lore.kernel.org/r/20250908-tune2fs-v1-0-e3a6929f3355@mit.edu --- Theodore Ts'o (3): ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() ext4: add support for 32-bit default reserved uid and gid values ext4: implemet new ioctls to set and get superblock parameters fs/ext4/ext4.h | 16 +++- fs/ext4/ioctl.c | 312 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- fs/ext4/super.c | 25 +++---- include/uapi/linux/ext4.h | 53 +++++++++++++ 4 files changed, 382 insertions(+), 24 deletions(-) --- base-commit: b320789d6883cc00ac78ce83bccbfe7ed58afcf0 change-id: 20250830-tune2fs-3376beb72403 Best regards, -- Theodore Ts'o <tytso(a)mit.edu>

1 month

4
4
0 0

[PATCH 1/2] soc: qcom: ocmem: fix device leak on lookup

by Johan Hovold

Make sure to drop the reference taken to the ocmem platform device when looking up its driver data. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Also note that commit 0ff027027e05 ("soc: qcom: ocmem: Fix missing put_device() call in of_get_ocmem") fixed the leak in a lookup error path, but the reference is still leaking on success. Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Cc: stable(a)vger.kernel.org # 5.5: 0ff027027e05 Cc: Brian Masney <bmasney(a)redhat.com> Cc: Miaoqian Lin <linmq006(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/soc/qcom/ocmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c index 9c3bd37b6579..71130a2f62e9 100644 --- a/drivers/soc/qcom/ocmem.c +++ b/drivers/soc/qcom/ocmem.c @@ -202,9 +202,9 @@ struct ocmem *of_get_ocmem(struct device *dev) } ocmem = platform_get_drvdata(pdev); + put_device(&pdev->dev); if (!ocmem) { dev_err(dev, "Cannot get ocmem\n"); - put_device(&pdev->dev); return ERR_PTR(-ENODEV); } return ocmem; -- 2.49.1

1 month

3
2
0 0

You have a donation of two Million Five Hundred Thousand

by Dr Leonard Valentinovic Blavatnik.

1 month

1
0
0 0

[REGRESSION] workqueue/writeback: Severe CPU hang due to kworker proliferation during I/O flush and cgroup cleanup

by Chenglong Tang

Hello, This is Chenglong from Google Container Optimized OS. I'm reporting a severe CPU hang regression that occurs after a high volume of file creation and subsequent cgroup cleanup. Through bisection, the issue appears to be caused by a chain reaction between three commits related to writeback, unbound workqueues, and CPU-hogging detection. The issue is greatly alleviated on the latest mainline kernel but is not fully resolved, still occurring intermittently (~1 in 10 runs). How to reproduce The kernel v6.1 is good. The hang is reliably triggered(over 80% chance) on kernels v6.6 and 6.12 and intermittently on mainline(6.17-rc7) with the following steps: Environment: A machine with a fast SSD and a high core count (e.g., Google Cloud's N2-standard-128). Workload: Concurrently generate a large number of files (e.g., 2 million) using multiple services managed by systemd-run. This creates significant I/O and cgroup churn. Trigger: After the file generation completes, terminate the systemd-run services. Result: Shortly after the services are killed, the system's CPU load spikes, leading to a massive number of kworker/+inode_switch_wbs threads and a system-wide hang/livelock where the machine becomes unresponsive (20s - 300s). Analysis and Problematic Commits 1. The initial commit: The process begins with a worker that can get stuck busy-waiting on a spinlock. Commit: ("writeback, cgroup: release dying cgwbs by switching attached inodes") Effect: This introduced the inode_switch_wbs_work_fn worker to clean up cgroup writeback structures. Under our test load, this worker appears to hit a highly contended wb->list_lock spinlock, causing it to burn 100% CPU without sleeping. 2. The Kworker Explosion: A subsequent change misinterprets the spinning worker from Stage 1, leading to a runaway feedback loop of worker creation. Commit: 616db8779b1e ("workqueue: Automatically mark CPU-hogging work items CPU_INTENSIVE") Effect: This logic sees the spinning worker, marks it as CPU_INTENSIVE, and excludes it from concurrency management. To handle the work backlog, it spawns a new kworker, which then also gets stuck on the same lock, repeating the cycle. This directly causes the kworker count to explode from <50 to 100-2000+. 3. The System-Wide Lockdown: The final piece allows this localized worker explosion to saturate the entire system. Commit: 8639ecebc9b1 ("workqueue: Implement non-strict affinity scope for unbound workqueues") Effect: This change introduced non-strict affinity as the default. It allows the hundreds of kworkers created in Stage 2 to be spread by the scheduler across all available CPU cores, turning the problem into a system-wide hang. Current Status and Mitigation Mainline Status: On the latest mainline kernel, the hang is far less frequent and the kworker counts are reduced back to normal (<50), suggesting other changes have partially mitigated the issue. However, the hang still occurs, and when it does, the kworker count still explodes (e.g., 300+), indicating the underlying feedback loop remains. Workaround: A reliable mitigation is to revert to the old workqueue behavior by setting affinity_strict to 1. This contains the kworker proliferation to a single CPU pod, preventing the system-wide hang. Questions Given that the issue is not fully resolved, could you please provide some guidance? 1. Is this a known issue, and are there patches in development that might fully address the underlying spinlock contention or the kworker feedback loop? 2. Is there a better long-term mitigation we can apply other than forcing strict affinity? Thank you for your time and help. Best regards, Chenglong

1 month

2
3
0 0

Re: [REGRESSION] workqueue/writeback: Severe CPU hang due to kworker proliferation during I/O flush and cgroup cleanup

by Tejun Heo

On Wed, Sep 24, 2025 at 05:24:15PM -0700, Chenglong Tang wrote: > The kernel v6.1 is good. The hang is reliably triggered(over 80% chance) on > kernels v6.6 and 6.12 and intermittently on mainline(6.17-rc7) with the > following steps: > - > > *Environment:* A machine with a fast SSD and a high core count (e.g., > Google Cloud's N2-standard-128). > - > > *Workload:* Concurrently generate a large number of files (e.g., 2 million) > using multiple services managed by systemd-run. This creates significant > I/O and cgroup churn. > - > > *Trigger:* After the file generation completes, terminate the systemd-run > services. > - > > *Result:* Shortly after the services are killed, the system's CPU load > spikes, leading to a massive number of kworker/+inode_switch_wbs threads > and a system-wide hang/livelock where the machine becomes unresponsive (20s > - 300s). Sounds like: http://lkml.kernel.org/r/20250912103522.2935-1-jack@suse.cz Can you see whether those patches resolve the problem? Thanks. -- tejun

1 month

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror