From: Kuniyuki Iwashima <kuniyu@google.com>
To: runyu.xiao@seu.edu.cn
Cc: davem@davemloft.net, edumazet@google.com, geliang@kernel.org,
horms@kernel.org, jianhao.xu@seu.edu.cn, kuba@kernel.org,
linux-kernel@vger.kernel.org, martineau@kernel.org,
matttbe@kernel.org, mptcp@lists.linux.dev,
netdev@vger.kernel.org, pabeni@redhat.com,
stable@vger.kernel.org
Subject: Re: [PATCH net] mptcp: upgrade network refcount before socket lock
Date: Mon, 10 Aug 2026 17:02:13 +0000 [thread overview]
Message-ID: <20260810170249.3669017-1-kuniyu@google.com> (raw)
In-Reply-To: <20260809091949.3618191-1-runyu.xiao@seu.edu.cn>
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
prev parent reply other threads:[~2026-08-10 17:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260810170249.3669017-1-kuniyu@google.com \
--to=kuniyu@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=jianhao.xu@seu.edu.cn \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=runyu.xiao@seu.edu.cn \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.