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

[PATCH] net: usb: asix_devices: add phy_mask for ax88772 mdio bus

by PetarStepanvoic

From: Xu Yang <xu.yang_2(a)nxp.com> Without setting phy_mask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phy_polling_mode() in phy_state_machine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoud the issue. Closes: https://lore.kernel.org/netdev/20250806082931.3289134-1-xu.yang_2@nxp.com Fixes: e532a096be0e ("net: usb: asix: ax88772: add phylib support") Cc: stable(a)vger.kernel.org Signed-off-by: Xu Yang <xu.yang_2(a)nxp.com> Tested-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Reviewed-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Link: https://patch.msgid.link/20250811092931.860333-1-xu.yang_2@nxp.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Petar Stepanovic <axiado-2557(a)axiado.com> --- drivers/net/usb/asix_devices.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c index 9b0318fb50b5..d9f5942ccc44 100644 --- a/drivers/net/usb/asix_devices.c +++ b/drivers/net/usb/asix_devices.c @@ -676,6 +676,7 @@ static int ax88772_init_mdio(struct usbnet *dev) priv->mdio->read = &asix_mdio_bus_read; priv->mdio->write = &asix_mdio_bus_write; priv->mdio->name = "Asix MDIO Bus"; + priv->mdio->phy_mask = ~(BIT(priv->phy_addr) | BIT(AX_EMBD_PHY_ADDR)); /* mii bus name is usb-<usb bus number>-<usb device number> */ snprintf(priv->mdio->id, MII_BUS_ID_SIZE, "usb-%03d:%03d", dev->udev->bus->busnum, dev->udev->devnum); -- 2.25.1

1 day, 21 hours

1
1
0 0

Fruit Attraction 2025 B2B Contact Package — Now Available

by Juanita Garcia

Hi, We’re offering verified business contact data for the upcoming Fruit Attraction 2025 (FA), tailored for effective outreach before and after the event. Place:  Madrid, Spain Date:SEP 30 - OCT 02, 2025 Contact Overview: 1,01,351 Attendees 2,179 Exhibiting Companies 6,537 Verified Exhibitor Contacts Total: 107,885 Business Contacts Each entry includes: Name, Job Title, Company, Website, Address, Phone, Official Email, LinkedIn Profile, and more. Get your list in just 48 hours—100% GDPR-compliant Data. If you'd like more details, just reply: “Send me pricing” Best regards, Juanita Garcia Sr. Marketing Manager To opt out reply “Not Interested.”

1 day, 21 hours

1
0
0 0

[PATCH CANDIDATE 5.15, 6.1, 6.6] xfs: Increase XFS_QM_TRANS_MAXDQS to 5

by Amir Goldstein

From: Allison Henderson <allison.henderson(a)oracle.com> [ Upstream commit f103df763563ad6849307ed5985d1513acc586dd ] With parent pointers enabled, a rename operation can update up to 5 inodes: src_dp, target_dp, src_ip, target_ip and wip. This causes their dquots to a be attached to the transaction chain, so we need to increase XFS_QM_TRANS_MAXDQS. This patch also add a helper function xfs_dqlockn to lock an arbitrary number of dquots. Signed-off-by: Allison Henderson <allison.henderson(a)oracle.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> [amir: backport to kernels prior to parent pointers to fix an old bug] A rename operation of a directory (i.e. mv A/C/ B/) may end up changing three different dquot accounts under the following conditions: 1. user (or group) quotas are enabled 2. A/ B/ and C/ have different owner uids (or gids) 3. A/ blocks shrinks after remove of entry C/ 4. B/ blocks grows before adding of entry C/ 5. A/ ino <= XFS_DIR2_MAX_SHORT_INUM 6. B/ ino > XFS_DIR2_MAX_SHORT_INUM 7. C/ is converted from sf to block format, because its parent entry needs to be stored as 8 bytes (see xfs_dir2_sf_replace_needblock) When all conditions are met (observed in the wild) we get this assertion: XFS: Assertion failed: qtrx, file: fs/xfs/xfs_trans_dquot.c, line: 207 The upstream commit fixed this bug as a side effect, so decided to apply it as is rather than changing XFS_QM_TRANS_MAXDQS to 3 in stable kernels. The Fixes commit below is NOT the commit that introduced the bug, but for some reason, which is not explained in the commit message, it fixes the comment to state that highest number of dquots of one type is 3 and not 2 (which leads to the assertion), without actually fixing it. The change of wording from "usr, grp OR prj" to "usr, grp and prj" suggests that there may have been a confusion between "the number of dquote of one type" and "the number of dquot types" (which is also 3), so the comment change was only accidentally correct. Fixes: 10f73d27c8e9 ("xfs: fix the comment explaining xfs_trans_dqlockedjoin") Cc: stable(a)vger.kernel.org Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> --- Christoph, This is a cognitive challenge. can you say what you where thinking in 2013 when making the comment change in the Fixes commit? Is my speculation above correct? Catherine and Leah, I decided that cherry-pick this upstream commit as is with a commit message addendum was the best stable tree strategy. The commit applies cleanly to 5.15.y, so I assume it does for 6.6 and 6.1 as well. I ran my tests on 5.15.y and nothing fell out, but did not try to reproduce these complex assertion in a test. Could you take this candidate backport patch to a spin on your test branch? What do you all think about this? Thanks, Amir. fs/xfs/xfs_dquot.c | 41 ++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_dquot.h | 1 + fs/xfs/xfs_qm.h | 2 +- fs/xfs/xfs_trans_dquot.c | 15 ++++++++++----- 4 files changed, 53 insertions(+), 6 deletions(-) diff --git a/fs/xfs/xfs_dquot.c b/fs/xfs/xfs_dquot.c index c15d61d47a06..6b05d47aa19b 100644 --- a/fs/xfs/xfs_dquot.c +++ b/fs/xfs/xfs_dquot.c @@ -1360,6 +1360,47 @@ xfs_dqlock2( } } +static int +xfs_dqtrx_cmp( + const void *a, + const void *b) +{ + const struct xfs_dqtrx *qa = a; + const struct xfs_dqtrx *qb = b; + + if (qa->qt_dquot->q_id > qb->qt_dquot->q_id) + return 1; + if (qa->qt_dquot->q_id < qb->qt_dquot->q_id) + return -1; + return 0; +} + +void +xfs_dqlockn( + struct xfs_dqtrx *q) +{ + unsigned int i; + + BUILD_BUG_ON(XFS_QM_TRANS_MAXDQS > MAX_LOCKDEP_SUBCLASSES); + + /* Sort in order of dquot id, do not allow duplicates */ + for (i = 0; i < XFS_QM_TRANS_MAXDQS && q[i].qt_dquot != NULL; i++) { + unsigned int j; + + for (j = 0; j < i; j++) + ASSERT(q[i].qt_dquot != q[j].qt_dquot); + } + if (i == 0) + return; + + sort(q, i, sizeof(struct xfs_dqtrx), xfs_dqtrx_cmp, NULL); + + mutex_lock(&q[0].qt_dquot->q_qlock); + for (i = 1; i < XFS_QM_TRANS_MAXDQS && q[i].qt_dquot != NULL; i++) + mutex_lock_nested(&q[i].qt_dquot->q_qlock, + XFS_QLOCK_NESTED + i - 1); +} + int __init xfs_qm_init(void) { diff --git a/fs/xfs/xfs_dquot.h b/fs/xfs/xfs_dquot.h index 6b5e3cf40c8b..0e954f88811f 100644 --- a/fs/xfs/xfs_dquot.h +++ b/fs/xfs/xfs_dquot.h @@ -231,6 +231,7 @@ int xfs_qm_dqget_uncached(struct xfs_mount *mp, void xfs_qm_dqput(struct xfs_dquot *dqp); void xfs_dqlock2(struct xfs_dquot *, struct xfs_dquot *); +void xfs_dqlockn(struct xfs_dqtrx *q); void xfs_dquot_set_prealloc_limits(struct xfs_dquot *); diff --git a/fs/xfs/xfs_qm.h b/fs/xfs/xfs_qm.h index 442a0f97a9d4..f75c12c4c6a0 100644 --- a/fs/xfs/xfs_qm.h +++ b/fs/xfs/xfs_qm.h @@ -121,7 +121,7 @@ enum { XFS_QM_TRANS_PRJ, XFS_QM_TRANS_DQTYPES }; -#define XFS_QM_TRANS_MAXDQS 2 +#define XFS_QM_TRANS_MAXDQS 5 struct xfs_dquot_acct { struct xfs_dqtrx dqs[XFS_QM_TRANS_DQTYPES][XFS_QM_TRANS_MAXDQS]; }; diff --git a/fs/xfs/xfs_trans_dquot.c b/fs/xfs/xfs_trans_dquot.c index 955c457e585a..99a03acd4488 100644 --- a/fs/xfs/xfs_trans_dquot.c +++ b/fs/xfs/xfs_trans_dquot.c @@ -268,24 +268,29 @@ xfs_trans_mod_dquot( /* * Given an array of dqtrx structures, lock all the dquots associated and join - * them to the transaction, provided they have been modified. We know that the - * highest number of dquots of one type - usr, grp and prj - involved in a - * transaction is 3 so we don't need to make this very generic. + * them to the transaction, provided they have been modified. */ STATIC void xfs_trans_dqlockedjoin( struct xfs_trans *tp, struct xfs_dqtrx *q) { + unsigned int i; ASSERT(q[0].qt_dquot != NULL); if (q[1].qt_dquot == NULL) { xfs_dqlock(q[0].qt_dquot); xfs_trans_dqjoin(tp, q[0].qt_dquot); - } else { - ASSERT(XFS_QM_TRANS_MAXDQS == 2); + } else if (q[2].qt_dquot == NULL) { xfs_dqlock2(q[0].qt_dquot, q[1].qt_dquot); xfs_trans_dqjoin(tp, q[0].qt_dquot); xfs_trans_dqjoin(tp, q[1].qt_dquot); + } else { + xfs_dqlockn(q); + for (i = 0; i < XFS_QM_TRANS_MAXDQS; i++) { + if (q[i].qt_dquot == NULL) + break; + xfs_trans_dqjoin(tp, q[i].qt_dquot); + } } } -- 2.47.1

1 day, 23 hours

2
4
0 0

+ mm-damon-lru_sort-use-param_ctx-for-damon_attrs-staging.patch added to mm-unstable branch

by Andrew Morton

The patch titled Subject: mm/damon/lru_sort: use param_ctx for damon_attrs staging has been added to the -mm mm-unstable branch. Its filename is mm-damon-lru_sort-use-param_ctx-for-damon_attrs-staging.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-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: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/lru_sort: use param_ctx for damon_attrs staging Date: Mon, 15 Sep 2025 20:15:49 -0700 damon_lru_sort_apply_parameters() allocates a new DAMON context, stages user-specified DAMON parameters on it, and commits to running DAMON context at once, using damon_commit_ctx(). The code is, however, directly updating the monitoring attributes of the running context. And the attributes are over-written by later damon_commit_ctx() call. This means that the monitoring attributes parameters are not really working. Fix the wrong use of the parameter context. Link: https://lkml.kernel.org/r/20250916031549.115326-1-sj@kernel.org Fixes: a30969436428 ("mm/damon/lru_sort: use damon_commit_ctx()") Signed-off-by: SeongJae Park <sj(a)kernel.org> Reviewed-by: Joshua Hahn <joshua.hahnjy(a)gmail.com> Cc: Joshua Hahn <joshua.hahnjy(a)gmail.com> Cc: <stable(a)vger.kernel.org> [6.11+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/lru_sort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/damon/lru_sort.c~mm-damon-lru_sort-use-param_ctx-for-damon_attrs-staging +++ a/mm/damon/lru_sort.c @@ -219,7 +219,7 @@ static int damon_lru_sort_apply_paramete goto out; } - err = damon_set_attrs(ctx, &damon_lru_sort_mon_attrs); + err = damon_set_attrs(param_ctx, &damon_lru_sort_mon_attrs); if (err) goto out; _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-lru_sort-use-param_ctx-for-damon_attrs-staging.patch mm-damon-core-reset-age-if-nr_accesses-changes-between-non-zero-and-zero.patch mm-damon-core-set-effective-quota-on-first-charge-window.patch mm-damon-lru_sort-use-param_ctx-correctly.patch docs-mm-damon-maintainer-profile-update-community-meetup-for-reservation-requirements.patch docs-admin-guide-mm-damon-start-add-target_pid-to-damos-example-command.patch maintainers-rename-damon-section.patch

2 days, 1 hour

1
0
0 0

+ fix-the-racy-usage-of-task_locktsk-group_leader-in-sys_prlimit64-paths.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths has been added to the -mm mm-nonmm-unstable branch. Its filename is fix-the-racy-usage-of-task_locktsk-group_leader-in-sys_prlimit64-paths.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: Oleg Nesterov <oleg(a)redhat.com> Subject: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths Date: Mon, 15 Sep 2025 14:09:17 +0200 The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable. Link: https://lkml.kernel.org/r/20250915120917.GA27702@redhat.com Fixes: 18c91bb2d872 ("prlimit: do not grab the tasklist_lock") Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jiri Slaby <jirislaby(a)kernel.org> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/sys.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) --- a/kernel/sys.c~fix-the-racy-usage-of-task_locktsk-group_leader-in-sys_prlimit64-paths +++ a/kernel/sys.c @@ -1734,6 +1734,7 @@ SYSCALL_DEFINE4(prlimit64, pid_t, pid, u struct rlimit old, new; struct task_struct *tsk; unsigned int checkflags = 0; + bool need_tasklist; int ret; if (old_rlim) @@ -1760,8 +1761,25 @@ SYSCALL_DEFINE4(prlimit64, pid_t, pid, u get_task_struct(tsk); rcu_read_unlock(); - ret = do_prlimit(tsk, resource, new_rlim ? &new : NULL, - old_rlim ? &old : NULL); + need_tasklist = !same_thread_group(tsk, current); + if (need_tasklist) { + /* + * Ensure we can't race with group exit or de_thread(), + * so tsk->group_leader can't be freed or changed until + * read_unlock(tasklist_lock) below. + */ + read_lock(&tasklist_lock); + if (!pid_alive(tsk)) + ret = -ESRCH; + } + + if (!ret) { + ret = do_prlimit(tsk, resource, new_rlim ? &new : NULL, + old_rlim ? &old : NULL); + } + + if (need_tasklist) + read_unlock(&tasklist_lock); if (!ret && old_rlim) { rlim_to_rlim64(&old, &old64); _ Patches currently in -mm which might be from oleg(a)redhat.com are fix-the-wrong-comment-on-task_lock-nesting-with-tasklist_lock.patch fix-the-racy-usage-of-task_locktsk-group_leader-in-sys_prlimit64-paths.patch

2 days, 1 hour

1
0
0 0

[PATCH] mm/damon/lru_sort: use param_ctx for damon_attrs staging

by SeongJae Park

damon_lru_sort_apply_parameters() allocates a new DAMON context, stages user-specified DAMON parameters on it, and commits to running DAMON context at once, using damon_commit_ctx(). The code is, however, directly updating the monitoring attributes of the running context. And the attributes are over-written by later damon_commit_ctx() call. This means that the monitoring attributes parameters are not really working. Fix the wrong use of the parameter context. Fixes: a30969436428 ("mm/damon/lru_sort: use damon_commit_ctx()") Cc: <stable(a)vger.kernel.org> # 6.11.x Signed-off-by: SeongJae Park <sj(a)kernel.org> Reviewed-by: Joshua Hahn <joshua.hahnjy(a)gmail.com> --- This was a part of misc fixes and improvements for 6.18 [1], but Joshua thankfully found this is fixing a real user visible bug. So sending this separately as a hotfix. [1] https://lore.kernel.org/20250915015807.101505-4-sj@kernel.org mm/damon/lru_sort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c index 14d31009c09e..ab6173a646bd 100644 --- a/mm/damon/lru_sort.c +++ b/mm/damon/lru_sort.c @@ -219,7 +219,7 @@ static int damon_lru_sort_apply_parameters(void) goto out; } - err = damon_set_attrs(ctx, &damon_lru_sort_mon_attrs); + err = damon_set_attrs(param_ctx, &damon_lru_sort_mon_attrs); if (err) goto out; base-commit: ea93a9235c1c6e61cfa6e5612b7b6b3fc41e79e1 -- 2.39.5

2 days, 2 hours

1
0
0 0

[PATCH] cpufreq: cap the default transition delay at 10 ms

by Shawn Guo

From: Shawn Guo <shawnguo(a)kernel.org> A regression is seen with 6.6 -> 6.12 kernel upgrade on platforms where cpufreq-dt driver sets cpuinfo.transition_latency as CPUFREQ_ETERNAL (-1), due to that platform's DT doesn't provide the optional property 'clock-latency-ns'. The dbs sampling_rate was 10000 us on 6.6 and suddently becomes 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these platforms, because that the 10 ms cap for transition_delay_us was accidentally dropped by the commits below. commit 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER") commit a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us") commit e13aa799c2a6 ("cpufreq: Change default transition delay to 2ms") It slows down dbs governor's reacting to CPU loading change dramatically. Also, as transition_delay_us is used by schedutil governor as rate_limit_us, it shows a negative impact on device idle power consumption, because the device gets slightly less time in the lowest OPP. Fix the regressions by adding the 10 ms cap on transition delay back. Cc: stable(a)vger.kernel.org Fixes: 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER") Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> --- drivers/cpufreq/cpufreq.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index fc7eace8b65b..36e0c85cb4e0 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -551,8 +551,13 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy) latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC; if (latency) - /* Give a 50% breathing room between updates */ - return latency + (latency >> 1); + /* + * Give a 50% breathing room between updates. + * And cap the transition delay to 10 ms for platforms + * where the latency is too high to be reasonable for + * reevaluating frequency. + */ + return min(latency + (latency >> 1), 10 * MSEC_PER_SEC); return USEC_PER_MSEC; } -- 2.43.0

2 days, 3 hours

3
9
0 0

[PATCH net 0/5] selftests: mptcp: avoid spurious errors on TCP disconnect

by Matthieu Baerts (NGI0)

This series should fix the recent instabilities seen by MPTCP and NIPA CIs where the 'mptcp_connect.sh' tests fail regularly when running the 'disconnect' subtests with "plain" TCP sockets, e.g. # INFO: disconnect # 63 ns1 MPTCP -> ns1 (10.0.1.1:20001 ) MPTCP (duration 996ms) [ OK ] # 64 ns1 MPTCP -> ns1 (10.0.1.1:20002 ) TCP (duration 851ms) [ OK ] # 65 ns1 TCP -> ns1 (10.0.1.1:20003 ) MPTCP Unexpected revents: POLLERR/POLLNVAL(19) # (duration 896ms) [FAIL] file received by server does not match (in, out): # -rw-r--r-- 1 root root 11112852 Aug 19 09:16 /tmp/tmp.hlJe5DoMoq.disconnect # Trailing bytes are: # /{ga 6@=#.8:-rw------- 1 root root 10085368 Aug 19 09:16 /tmp/tmp.blClunilxx # Trailing bytes are: # /{ga 6@=#.8:66 ns1 MPTCP -> ns1 (dead:beef:1::1:20004) MPTCP (duration 987ms) [ OK ] # 67 ns1 MPTCP -> ns1 (dead:beef:1::1:20005) TCP (duration 911ms) [ OK ] # 68 ns1 TCP -> ns1 (dead:beef:1::1:20006) MPTCP (duration 980ms) [ OK ] # [FAIL] Tests of the full disconnection have failed These issues started to be visible after some behavioural changes in TCP, where too quick re-connections after a shutdown() can now be more easily rejected. Patch 3 modifies the selftests to wait, but this resolution revealed an issue in MPTCP which is fixed by patch 1 (a fix for v5.9 kernel). Patches 2 and 4 improve some errors reported by the selftests, and patch 5 helps with the debugging of such issues. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Note: The last two patches are not strictly fixes, but they are useful in case similar issues happen again. That's why they have been added here in this series for -net. If that's an issue, please drop them, and I can re-send them later on. --- Matthieu Baerts (NGI0) (5): mptcp: propagate shutdown to subflows when possible selftests: mptcp: connect: catch IO errors on listen side selftests: mptcp: avoid spurious errors on TCP disconnect selftests: mptcp: print trailing bytes with od selftests: mptcp: connect: print pcap prefix net/mptcp/protocol.c | 16 ++++++++++++++++ tools/testing/selftests/net/mptcp/mptcp_connect.c | 11 ++++++----- tools/testing/selftests/net/mptcp/mptcp_connect.sh | 6 +++++- tools/testing/selftests/net/mptcp/mptcp_lib.sh | 2 +- 4 files changed, 28 insertions(+), 7 deletions(-) --- base-commit: 2690cb089502b80b905f2abdafd1bf2d54e1abef change-id: 20250912-net-mptcp-fix-sft-connect-f095ad7a6e36 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

2 days, 4 hours

2
4
0 0

[PATCH] ksmbd: Fix race condition in RPC handle list access

by Yunseong Kim

The 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd session. Access to this list is intended to be protected by 'sess->rpc_lock' (an rw_semaphore). However, the locking implementation was flawed, leading to potential race conditions. In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock before calling xa_store() and xa_erase(). Since these operations modify the XArray structure, a write lock is required to ensure exclusive access and prevent data corruption from concurrent modifications. Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load() without holding any lock at all. This could lead to reading inconsistent data or a potential use-after-free if an entry is concurrently removed and the pointer is dereferenced. Fix these issues by: 1. Using down_write() and up_write() in ksmbd_session_rpc_open() to ensure exclusive access during XArray modification, and ensuring the lock is correctly released on error paths. 2. Adding down_read() and up_read() in ksmbd_session_rpc_method() to safely protect the lookup. Fixes: a1f46c99d9ea ("ksmbd: fix use-after-free in ksmbd_session_rpc_open") Fixes: b685757c7b08 ("ksmbd: Implements sess->rpc_handle_list as xarray") Cc: stable(a)vger.kernel.org Signed-off-by: Yunseong Kim <ysk(a)kzalloc.com> --- fs/smb/server/mgmt/user_session.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/fs/smb/server/mgmt/user_session.c b/fs/smb/server/mgmt/user_session.c index 9dec4c2940bc..b36d0676dbe5 100644 --- a/fs/smb/server/mgmt/user_session.c +++ b/fs/smb/server/mgmt/user_session.c @@ -104,29 +104,32 @@ int ksmbd_session_rpc_open(struct ksmbd_session *sess, char *rpc_name) if (!entry) return -ENOMEM; - down_read(&sess->rpc_lock); entry->method = method; entry->id = id = ksmbd_ipc_id_alloc(); if (id < 0) goto free_entry; + + down_write(&sess->rpc_lock); old = xa_store(&sess->rpc_handle_list, id, entry, KSMBD_DEFAULT_GFP); - if (xa_is_err(old)) + if (xa_is_err(old)) { + up_write(&sess->rpc_lock); goto free_id; + } resp = ksmbd_rpc_open(sess, id); - if (!resp) - goto erase_xa; + if (!resp) { + xa_erase(&sess->rpc_handle_list, entry->id); + up_write(&sess->rpc_lock); + goto free_id; + } - up_read(&sess->rpc_lock); + up_write(&sess->rpc_lock); kvfree(resp); return id; -erase_xa: - xa_erase(&sess->rpc_handle_list, entry->id); free_id: ksmbd_rpc_id_free(entry->id); free_entry: kfree(entry); - up_read(&sess->rpc_lock); return -EINVAL; } @@ -144,9 +147,14 @@ void ksmbd_session_rpc_close(struct ksmbd_session *sess, int id) int ksmbd_session_rpc_method(struct ksmbd_session *sess, int id) { struct ksmbd_session_rpc *entry; + int method; + down_read(&sess->rpc_lock); entry = xa_load(&sess->rpc_handle_list, id); - return entry ? entry->method : 0; + method = entry ? entry->method : 0; + up_read(&sess->rpc_lock); + + return method; } void ksmbd_session_destroy(struct ksmbd_session *sess) -- 2.51.0

2 days, 4 hours

2
1
0 0

[PATCHSET RFC v5 1/8] fuse: general bug fixes

by Darrick J. Wong

Hi all, Here's a collection of fixes that I *think* are bugs in fuse, along with some scattered improvements. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. This has been running on the djcloud for months with no problems. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=fu… --- Commits in this patchset: * fuse: fix livelock in synchronous file put from fuseblk workers * fuse: flush pending fuse events before aborting the connection * fuse: capture the unique id of fuse commands being sent * fuse: signal that a fuse filesystem should exhibit local fs behaviors * fuse: implement file attributes mask for statx * fuse: update file mode when updating acls * fuse: propagate default and file acls on creation * fuse: enable FUSE_SYNCFS for all fuseblk servers --- fs/fuse/fuse_i.h | 55 +++++++++++++++++++++++++++ fs/fuse/acl.c | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++ fs/fuse/dev.c | 60 +++++++++++++++++++++++++++-- fs/fuse/dev_uring.c | 4 +- fs/fuse/dir.c | 96 +++++++++++++++++++++++++++++++++++------------ fs/fuse/file.c | 8 +++- fs/fuse/inode.c | 17 ++++++++ fs/fuse/virtio_fs.c | 3 - 8 files changed, 314 insertions(+), 34 deletions(-)

2 days, 5 hours

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror