* Re: [PATCH net] mptcp: upgrade network refcount before socket lock
2026-08-09 9:19 [PATCH net] mptcp: upgrade network refcount before socket lock Runyu Xiao
@ 2026-08-09 10:24 ` MPTCP CI
2026-08-10 1:59 ` gang.yan
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: MPTCP CI @ 2026-08-09 10:24 UTC (permalink / raw)
To: Runyu Xiao; +Cc: mptcp
Hi Runyu,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/31306413386
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/08ac228c62fe
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1142867
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-normal
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net] mptcp: upgrade network refcount before socket lock
2026-08-09 9:19 [PATCH net] mptcp: upgrade network refcount before socket lock Runyu Xiao
2026-08-09 10:24 ` MPTCP CI
@ 2026-08-10 1:59 ` gang.yan
2026-08-10 10:01 ` Matthieu Baerts
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: gang.yan @ 2026-08-10 1:59 UTC (permalink / raw)
To: Runyu Xiao, Matthieu Baerts, Mat Martineau
Cc: Geliang Tang, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, mptcp, netdev, linux-kernel,
runyu.xiao, jianhao.xu, stable
August 9, 2026 at 5:19 PM, "Runyu Xiao" <runyu.xiao@seu.edu.cn mailto:runyu.xiao@seu.edu.cn?to=%22Runyu%20Xiao%22%20%3Crunyu.xiao%40seu.edu.cn%3E > wrote:
Hi,
Thanks for your patch.
>
> sk_net_refcnt_upgrade() calls get_net_track() with GFP_KERNEL and can enter
> direct reclaim. Calling it while holding the newly created subflow socket
> lock can create a reclaim-to-socket-lock dependency cycle.
>
> Upgrade the network reference before taking the socket lock. The socket is
> newly created and has not been exposed to other code at this point, so the
> fields changed by sk_net_refcnt_upgrade() are not accessed concurrently.
> The error path still releases the socket normally after the upgrade.
>
> The PatchProof static-analysis tool detected a GFP_KERNEL allocation while
> the socket lock is held. Manual source review of v7.1.5 and current
> mainline confirmed the lock and allocation ordering.
>
> A source-level check found `sk_net_refcnt_upgrade()` after
> `lock_sock_nested()` in the original function and before it after this
> change. A POSIX-thread lock-order model made the reclaim lock unavailable
> while the socket lock was held, observed `EBUSY` for the reclaim lock, and
> then completed with the reclaim-first order. The model checks the ordering
> invariant only; it does not execute the kernel MPTCP path. No live lockdep
> MPTCP test or reclaim fault injection was run.
>
Maybe the commit message seems too long. Could you please send a v2 with a more
concise commit message? For your reference, here is a suggested simplified version:
'''
sk_net_refcnt_upgrade() performs a GFP_KERNEL allocation (via get_net_track()
→ ref_tracker_alloc()), which can enter direct reclaim and establish a
socket_lock → fs_reclaim dependency. Move it before lock_sock_nested(), mirroring
the convention documented in net/rds/tcp.c:rds_tcp_tune().
The socket is freshly created and unpublished at this point, so sk_net_refcnt/
ns_tracker are not touched by any concurrent path; the error path still releases
via sock_release() which handles both refcounted and non-refcounted trackers.
'''
Please note that this suggested text is generated by AI, so please review it
carefully before adopting it. Also, the next patch can only be sent to mptcp@lists.linux.dev,
no need to cc to others.
> Fixes: 1d2f3d3c6268 ("mptcp: adjust to use netns refcount tracker")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> ---
> net/mptcp/subflow.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index e1f20ff8fdb4..a9f951cc6a0e 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -1786,6 +1786,12 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
> if (err)
> return err;
>
> + /* kernel sockets do not by default acquire net ref, but TCP timer
> + * needs it.
> + * Update ns_tracker to current stack trace and refcounted tracker.
> + */
> + sk_net_refcnt_upgrade(sf->sk);
> +
> lock_sock_nested(sf->sk, SINGLE_DEPTH_NESTING);
>
> err = security_mptcp_add_subflow(sk, sf->sk);
> @@ -1795,11 +1801,6 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
> /* the newly created socket has to be in the same cgroup as its parent */
> mptcp_attach_cgroup(sk, sf->sk);
>
> - /* kernel sockets do not by default acquire net ref, but TCP timer
> - * needs it.
> - * Update ns_tracker to current stack trace and refcounted tracker.
> - */
> - sk_net_refcnt_upgrade(sf->sk);
> err = tcp_set_ulp(sf->sk, "mptcp");
> if (err)
> goto err_free;
LKGM!
You can add 'Acked-by: Gang Yan <gang.yan@linux.dev>' in your next patch.
Thanks
Gang
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net] mptcp: upgrade network refcount before socket lock
2026-08-09 9:19 [PATCH net] mptcp: upgrade network refcount before socket lock Runyu Xiao
2026-08-09 10:24 ` MPTCP CI
2026-08-10 1:59 ` gang.yan
@ 2026-08-10 10:01 ` Matthieu Baerts
2026-08-10 17:02 ` Kuniyuki Iwashima
2026-08-11 5:35 ` [PATCH net v2] " Runyu Xiao
4 siblings, 0 replies; 6+ messages in thread
From: Matthieu Baerts @ 2026-08-10 10:01 UTC (permalink / raw)
To: Runyu Xiao, Mat Martineau
Cc: Geliang Tang, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, mptcp, netdev, linux-kernel,
jianhao.xu, stable
Hi Runyu,
On 09/08/2026 11:19, Runyu Xiao wrote:
> sk_net_refcnt_upgrade() calls get_net_track() with GFP_KERNEL and can enter
> direct reclaim. Calling it while holding the newly created subflow socket
> lock can create a reclaim-to-socket-lock dependency cycle.
>
> Upgrade the network reference before taking the socket lock. The socket is
> newly created and has not been exposed to other code at this point, so the
> fields changed by sk_net_refcnt_upgrade() are not accessed concurrently.
> The error path still releases the socket normally after the upgrade.
Thank you for the patch! Even if I agree with Gang that the commit
message could be improved, the code looks good to me, and probably best
not to increase the traffic on the netdev list. So it looks good to me:
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
@Net maintainers: this patch can be applied to net directly.
> The PatchProof static-analysis tool detected a GFP_KERNEL allocation while
> the socket lock is held. Manual source review of v7.1.5 and current
> mainline confirmed the lock and allocation ordering.
>
> A source-level check found `sk_net_refcnt_upgrade()` after
> `lock_sock_nested()` in the original function and before it after this
> change. A POSIX-thread lock-order model made the reclaim lock unavailable
> while the socket lock was held, observed `EBUSY` for the reclaim lock, and
> then completed with the reclaim-first order. The model checks the ordering
> invariant only; it does not execute the kernel MPTCP path. No live lockdep
> MPTCP test or reclaim fault injection was run.
Interesting. By chance, any reproducer to share?
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] mptcp: upgrade network refcount before socket lock
2026-08-09 9:19 [PATCH net] mptcp: upgrade network refcount before socket lock Runyu Xiao
` (2 preceding siblings ...)
2026-08-10 10:01 ` Matthieu Baerts
@ 2026-08-10 17:02 ` Kuniyuki Iwashima
2026-08-11 5:35 ` [PATCH net v2] " Runyu Xiao
4 siblings, 0 replies; 6+ messages in thread
From: Kuniyuki Iwashima @ 2026-08-10 17:02 UTC (permalink / raw)
To: runyu.xiao
Cc: davem, edumazet, geliang, horms, jianhao.xu, kuba, linux-kernel,
martineau, matttbe, mptcp, netdev, pabeni, stable
From: Runyu Xiao <runyu.xiao@seu.edu.cn>
Date: Sun, 9 Aug 2026 17:19:49 +0800
> sk_net_refcnt_upgrade() calls get_net_track() with GFP_KERNEL and can enter
> direct reclaim. Calling it while holding the newly created subflow socket
> lock can create a reclaim-to-socket-lock dependency cycle.
I guess this involves NBD, and then it should be false-positive.
It makes lockdep complain about all sleepable memory allocation
under lock_sock() for TCP/AF_UNIX-SOCK_STREAM sockets.
NBD must process TX requests asynchronously to remove the dependency.
>
> Upgrade the network reference before taking the socket lock. The socket is
> newly created and has not been exposed to other code at this point, so the
> fields changed by sk_net_refcnt_upgrade() are not accessed concurrently.
> The error path still releases the socket normally after the upgrade.
>
> The PatchProof static-analysis tool detected a GFP_KERNEL allocation while
> the socket lock is held. Manual source review of v7.1.5 and current
> mainline confirmed the lock and allocation ordering.
>
> A source-level check found `sk_net_refcnt_upgrade()` after
> `lock_sock_nested()` in the original function and before it after this
> change. A POSIX-thread lock-order model made the reclaim lock unavailable
> while the socket lock was held, observed `EBUSY` for the reclaim lock, and
> then completed with the reclaim-first order. The model checks the ordering
> invariant only; it does not execute the kernel MPTCP path. No live lockdep
> MPTCP test or reclaim fault injection was run.
>
> Fixes: 1d2f3d3c6268 ("mptcp: adjust to use netns refcount tracker")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> ---
> net/mptcp/subflow.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index e1f20ff8fdb4..a9f951cc6a0e 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -1786,6 +1786,12 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
> if (err)
> return err;
>
> + /* kernel sockets do not by default acquire net ref, but TCP timer
> + * needs it.
> + * Update ns_tracker to current stack trace and refcounted tracker.
> + */
> + sk_net_refcnt_upgrade(sf->sk);
> +
> lock_sock_nested(sf->sk, SINGLE_DEPTH_NESTING);
>
> err = security_mptcp_add_subflow(sk, sf->sk);
> @@ -1795,11 +1801,6 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
> /* the newly created socket has to be in the same cgroup as its parent */
> mptcp_attach_cgroup(sk, sf->sk);
>
> - /* kernel sockets do not by default acquire net ref, but TCP timer
> - * needs it.
> - * Update ns_tracker to current stack trace and refcounted tracker.
> - */
> - sk_net_refcnt_upgrade(sf->sk);
> err = tcp_set_ulp(sf->sk, "mptcp");
> if (err)
> goto err_free;
> --
> 2.34.1
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH net v2] mptcp: upgrade network refcount before socket lock
2026-08-09 9:19 [PATCH net] mptcp: upgrade network refcount before socket lock Runyu Xiao
` (3 preceding siblings ...)
2026-08-10 17:02 ` Kuniyuki Iwashima
@ 2026-08-11 5:35 ` Runyu Xiao
4 siblings, 0 replies; 6+ messages in thread
From: Runyu Xiao @ 2026-08-11 5:35 UTC (permalink / raw)
To: mptcp
Cc: Matthieu Baerts, Mat Martineau, Geliang Tang, Gang Yan,
Eric Dumazet, Runyu Xiao, Jianhao Xu
sk_net_refcnt_upgrade() is called after lock_sock_nested() in
mptcp_subflow_create_socket(), while other callers perform the upgrade
before taking the socket lock.
Move sk_net_refcnt_upgrade() before lock_sock_nested(). The subflow
socket is newly created and unpublished at this point, so sk_net_refcnt
and ns_tracker are not accessed concurrently, and the existing error
path via sock_release() remains unchanged.
Acked-by: Gang Yan <gang.yan@linux.dev>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
Changes in v2:
- Shorten the commit message and remove the validation-method details.
- Describe the change in terms of the pre-lock upgrade ordering.
- Add Acked-by from Gang Yan.
- Add Reviewed-by from Matthieu Baerts.
net/mptcp/subflow.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index e1f20ff8fdb4..a9f951cc6a0e 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -1786,6 +1786,12 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
if (err)
return err;
+ /* kernel sockets do not by default acquire net ref, but TCP timer
+ * needs it.
+ * Update ns_tracker to current stack trace and refcounted tracker.
+ */
+ sk_net_refcnt_upgrade(sf->sk);
+
lock_sock_nested(sf->sk, SINGLE_DEPTH_NESTING);
err = security_mptcp_add_subflow(sk, sf->sk);
@@ -1795,11 +1801,6 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family,
/* the newly created socket has to be in the same cgroup as its parent */
mptcp_attach_cgroup(sk, sf->sk);
- /* kernel sockets do not by default acquire net ref, but TCP timer
- * needs it.
- * Update ns_tracker to current stack trace and refcounted tracker.
- */
- sk_net_refcnt_upgrade(sf->sk);
err = tcp_set_ulp(sf->sk, "mptcp");
if (err)
goto err_free;
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread