[PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets

[PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets

[Geliang Tang]

From: Geliang Tang <tanggeliang@kylinos.cn>

The mptcp_nvme.sh selftest reports lockdep "possible recursive locking"
warnings when running NVMe over MPTCP. The issue occurs because MPTCP
sockets and their subflows share the same k-sk_lock-AF_INET lockdep class,
causing lockdep to flag false warnings in paths that hold the MPTCP socket
lock and then lock a subflow (setsockopt, connect, bind, worker send-ack).

This series fixes the issue by giving MPTCP sockets their own distinct
lockdep class (sk_lock-AF_INET-MPTCP for IPv4, sk_lock-AF_INET6-MPTCP for
IPv6), similar to how nvme-tcp handles it. This approach is more efficient
than reclassifying each subflow individually, properly supports IPv6, and
follows existing kernel patterns.

A KUnit test is included to verify the fix works correctly.

v2:
 - Move reclassification to __mptcp_init_sock() to cover cloned sockets,
   as Matt suggested
 - Extract mptcp_reclassify_socket() helper for reuse in PM listener socket
   creation
 - Remove #ifdef CONFIG_DEBUG_LOCK_ALLOC wrapper as suggested by Matt
 - Update lock class names to msk_lock-AF_INET/msk_lock-AF_INET6
 - Note: checkpatch.pl warns about line length > 80 columns in pm_kernel.c,
   but kept for consistency with existing code style

v1:
 - https://patchwork.kernel.org/project/mptcp/cover/cover.1792060837.git.tanggeliang@kylinos.cn/

Geliang Tang (2):
  mptcp: give MPTCP sockets a distinct lockdep class
  mptcp: kunit: add sockopt test for subflow socket locking

 net/mptcp/Makefile       |  4 +++-
 net/mptcp/pm_kernel.c    | 18 ++++++++++++------
 net/mptcp/protocol.c     |  3 +++
 net/mptcp/protocol.h     |  2 ++
 net/mptcp/sockopt_test.c | 37 +++++++++++++++++++++++++++++++++++++
 5 files changed, 57 insertions(+), 7 deletions(-)
 create mode 100644 net/mptcp/sockopt_test.c

-- 
2.55.0

[PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class

[Geliang Tang]

From: Geliang Tang <tanggeliang@kylinos.cn>

MPTCP sockets and their subflows share the same k-sk_lock-AF_INET
lockdep class. When both are kernel sockets, lockdep flags every path
that holds the MPTCP socket lock and then locks a subflow (setsockopt,
connect, bind, worker send-ack) as "possible recursive locking".

Extract the lock reclassification logic from PM listener socket creation
into mptcp_reclassify_socket() helper to reclassify MPTCP socket locks
to a distinct class (msk_lock-AF_INET for IPv4, msk_lock-AF_INET6 for
IPv6). Call it from __mptcp_init_sock() to cover both active (connect)
and passive (accept/clone) socket creation paths.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 net/mptcp/pm_kernel.c | 18 ++++++++++++------
 net/mptcp/protocol.c  |  3 +++
 net/mptcp/protocol.h  |  2 ++
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
index d3014bf57bf3..5e8792ad38ca 100644
--- a/net/mptcp/pm_kernel.c
+++ b/net/mptcp/pm_kernel.c
@@ -849,10 +849,20 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
 static struct lock_class_key mptcp_slock_keys[2];
 static struct lock_class_key mptcp_keys[2];
 
+void mptcp_reclassify_socket(struct sock *sk)
+{
+	bool is_ipv6 = sk->sk_family == AF_INET6;
+
+	sock_lock_init_class_and_name(sk,
+				      is_ipv6 ? "mlock-AF_INET6" : "mlock-AF_INET",
+				      &mptcp_slock_keys[is_ipv6],
+				      is_ipv6 ? "msk_lock-AF_INET6" : "msk_lock-AF_INET",
+				      &mptcp_keys[is_ipv6]);
+}
+
 static int mptcp_pm_nl_create_listen_socket(struct sock *sk,
 					    struct mptcp_pm_addr_entry *entry)
 {
-	bool is_ipv6 = entry->addr.family == AF_INET6;
 	int addrlen = sizeof(struct sockaddr_in);
 	struct sockaddr_storage addr;
 	struct sock *newsk, *ssk;
@@ -874,11 +884,7 @@ static int mptcp_pm_nl_create_listen_socket(struct sock *sk,
 	 * modifiers in several places, re-init the lock class for the msk
 	 * socket to an mptcp specific one.
 	 */
-	sock_lock_init_class_and_name(newsk,
-				      is_ipv6 ? "mlock-AF_INET6" : "mlock-AF_INET",
-				      &mptcp_slock_keys[is_ipv6],
-				      is_ipv6 ? "msk_lock-AF_INET6" : "msk_lock-AF_INET",
-				      &mptcp_keys[is_ipv6]);
+	mptcp_reclassify_socket(newsk);
 
 	lock_sock(newsk);
 	ssk = __mptcp_nmpc_sk(mptcp_sk(newsk));
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 60cbd91be632..68f339311993 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3245,6 +3245,9 @@ static void __mptcp_init_sock(struct sock *sk)
 	/* re-use the csk retrans timer for MPTCP-level retrans */
 	timer_setup(&sk->mptcp_retransmit_timer, mptcp_retransmit_timer, 0);
 	timer_setup(&msk->sk.mptcp_tout_timer, mptcp_tout_timer, 0);
+
+	if (sk->sk_socket)
+		mptcp_reclassify_socket(sk);
 }
 
 static void mptcp_ca_reset(struct sock *sk)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index ed2f363bb915..325499e65236 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -1265,6 +1265,8 @@ u8 mptcp_pm_get_endp_fullmesh_max(const struct mptcp_sock *msk);
 u8 mptcp_pm_get_limit_add_addr_accepted(const struct mptcp_sock *msk);
 u8 mptcp_pm_get_limit_extra_subflows(const struct mptcp_sock *msk);
 
+void mptcp_reclassify_socket(struct sock *sk);
+
 /* called under PM lock */
 static inline void __mptcp_pm_close_subflow(struct mptcp_sock *msk)
 {
-- 
2.55.0

Re: [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mptcp: lockdep warning fix bypassed for passive sockets
--

commit 554f965b1a52d1d1bbbc1a03f3a216e91642e81f
Author: Geliang Tang <geliang@kernel.org>

mptcp: give MPTCP sockets a distinct lockdep class

This commit extracts lock reclassification logic into mptcp_reclassify_socket()
and calls it from __mptcp_init_sock() to fix a lockdep "possible recursive
locking" warning. It aims to cover both active and passive socket creation
paths.

> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 60cbd91be6320..68f339311993e 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
[ ... ]
> @@ -3245,6 +3245,9 @@ static void __mptcp_init_sock(struct sock *sk)
>  	/* re-use the csk retrans timer for MPTCP-level retrans */
>  	timer_setup(&sk->mptcp_retransmit_timer, mptcp_retransmit_timer, 0);
>  	timer_setup(&msk->sk.mptcp_tout_timer, mptcp_tout_timer, 0);
> +
> +	if (sk->sk_socket)
> +		mptcp_reclassify_socket(sk);

[Severity: Medium]
Does this check evaluate to false for cloned passive sockets, bypassing the
lock reclassification entirely?

During passive socket creation, mptcp_sk_clone_init() calls sk_clone_lock(),
which clones the socket, acquires its spinlock, and explicitly clears sk_socket:

net/core/sock.c:sk_clone() {
    ...
    sk_set_socket(newsk, NULL);
    ...
}

When mptcp_sk_clone_init() then calls __mptcp_init_sock(), sk->sk_socket
is NULL, causing the intended lockdep fix to be bypassed for passive sockets.

Additionally, if mptcp_reclassify_socket() were called unconditionally here
without the sk_socket check, would it re-initialize the actively held spinlock
from sk_clone_lock() and cause a BUG on unlock?

>  }
>  
>  static void mptcp_ca_reset(struct sock *sk)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1792114102.git.tanggeliang@kylinos.cn?part=1

Re: [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class

[Matthieu Baerts]

Hi Geliang,

Thank you for the new version.

On 16/10/2026 03:35, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> MPTCP sockets and their subflows share the same k-sk_lock-AF_INET
> lockdep class. When both are kernel sockets, lockdep flags every path
> that holds the MPTCP socket lock and then locks a subflow (setsockopt,
> connect, bind, worker send-ack) as "possible recursive locking".
> 
> Extract the lock reclassification logic from PM listener socket creation
> into mptcp_reclassify_socket() helper to reclassify MPTCP socket locks
> to a distinct class (msk_lock-AF_INET for IPv4, msk_lock-AF_INET6 for
> IPv6). Call it from __mptcp_init_sock() to cover both active (connect)
> and passive (accept/clone) socket creation paths.
> 
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
>  net/mptcp/pm_kernel.c | 18 ++++++++++++------
>  net/mptcp/protocol.c  |  3 +++
>  net/mptcp/protocol.h  |  2 ++
>  3 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
> index d3014bf57bf3..5e8792ad38ca 100644
> --- a/net/mptcp/pm_kernel.c
> +++ b/net/mptcp/pm_kernel.c
> @@ -849,10 +849,20 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
>  static struct lock_class_key mptcp_slock_keys[2];
>  static struct lock_class_key mptcp_keys[2];
>  
> +void mptcp_reclassify_socket(struct sock *sk)
> +{
> +	bool is_ipv6 = sk->sk_family == AF_INET6;
> +
> +	sock_lock_init_class_and_name(sk,
> +				      is_ipv6 ? "mlock-AF_INET6" : "mlock-AF_INET",
> +				      &mptcp_slock_keys[is_ipv6],
> +				      is_ipv6 ? "msk_lock-AF_INET6" : "msk_lock-AF_INET",
> +				      &mptcp_keys[is_ipv6]);
> +}

Good idea to share this code here, but then I think it should be better
in net/mptcp/protocol.c than in the in-kernel PM.

>  static int mptcp_pm_nl_create_listen_socket(struct sock *sk,
>  					    struct mptcp_pm_addr_entry *entry)
>  {
> -	bool is_ipv6 = entry->addr.family == AF_INET6;
>  	int addrlen = sizeof(struct sockaddr_in);
>  	struct sockaddr_storage addr;
>  	struct sock *newsk, *ssk;
> @@ -874,11 +884,7 @@ static int mptcp_pm_nl_create_listen_socket(struct sock *sk,
>  	 * modifiers in several places, re-init the lock class for the msk
>  	 * socket to an mptcp specific one.
>  	 */
> -	sock_lock_init_class_and_name(newsk,
> -				      is_ipv6 ? "mlock-AF_INET6" : "mlock-AF_INET",
> -				      &mptcp_slock_keys[is_ipv6],
> -				      is_ipv6 ? "msk_lock-AF_INET6" : "msk_lock-AF_INET",
> -				      &mptcp_keys[is_ipv6]);
> +	mptcp_reclassify_socket(newsk);
>  
>  	lock_sock(newsk);
>  	ssk = __mptcp_nmpc_sk(mptcp_sk(newsk));
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 60cbd91be632..68f339311993 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -3245,6 +3245,9 @@ static void __mptcp_init_sock(struct sock *sk)
>  	/* re-use the csk retrans timer for MPTCP-level retrans */
>  	timer_setup(&sk->mptcp_retransmit_timer, mptcp_retransmit_timer, 0);
>  	timer_setup(&msk->sk.mptcp_tout_timer, mptcp_tout_timer, 0);
> +
> +	if (sk->sk_socket)

If you need this check here, that means the reclassification is not
always done, thus this new helper is certainly called from the wrong place.

> +		mptcp_reclassify_socket(sk);
>  }
>  
>  static void mptcp_ca_reset(struct sock *sk)
> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index ed2f363bb915..325499e65236 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -1265,6 +1265,8 @@ u8 mptcp_pm_get_endp_fullmesh_max(const struct mptcp_sock *msk);
>  u8 mptcp_pm_get_limit_add_addr_accepted(const struct mptcp_sock *msk);
>  u8 mptcp_pm_get_limit_extra_subflows(const struct mptcp_sock *msk);
>  
> +void mptcp_reclassify_socket(struct sock *sk);
> +
>  /* called under PM lock */
>  static inline void __mptcp_pm_close_subflow(struct mptcp_sock *msk)
>  {

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

[PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking

[Geliang Tang]

From: Geliang Tang <tanggeliang@kylinos.cn>

Add a KUnit test to verify that MPTCP sockets have a distinct lockdep
class from their subflows. The test creates a kernel MPTCP socket and
sets SO_REUSEADDR, which triggers the code path where
mptcp_setsockopt_sol_socket() locks the MPTCP socket and then calls
sk_setsockopt() on the subflow.

Without the lockdep fix (distinct MPTCP socket class), this triggers a
"possible recursive locking" warning:

'''
  kunit_try_catch/355 is trying to acquire lock:
  ffff888115c99c58 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: \
					sk_setsockopt+0x1132/0x3b30

  but task is already holding lock:
  ffff88811ac80e98 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: \
				mptcp_setsockopt_sol_socket+0xed/0x910

  Possible unsafe locking scenario:
         CPU0
         ----
    lock(k-sk_lock-AF_INET);
    lock(k-sk_lock-AF_INET);

  *** DEADLOCK ***
'''

With the fix, the MPTCP socket has its own msk_lock-AF_INET class (or
msk_lock-AF_INET6 for IPv6) and no warning appears.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 net/mptcp/Makefile       |  4 +++-
 net/mptcp/sockopt_test.c | 37 +++++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 net/mptcp/sockopt_test.c

diff --git a/net/mptcp/Makefile b/net/mptcp/Makefile
index bd72b300a0f6..e9ae91cff940 100644
--- a/net/mptcp/Makefile
+++ b/net/mptcp/Makefile
@@ -10,7 +10,9 @@ obj-$(CONFIG_INET_MPTCP_DIAG) += mptcp_diag.o
 
 mptcp_crypto_test-objs := crypto_test.o
 mptcp_token_test-objs := token_test.o
-obj-$(CONFIG_MPTCP_KUNIT_TEST) += mptcp_crypto_test.o mptcp_token_test.o
+mptcp_sockopt_test-objs := sockopt_test.o
+obj-$(CONFIG_MPTCP_KUNIT_TEST) += mptcp_crypto_test.o mptcp_token_test.o \
+				  mptcp_sockopt_test.o
 
 obj-$(CONFIG_BPF_SYSCALL) += bpf.o
 
diff --git a/net/mptcp/sockopt_test.c b/net/mptcp/sockopt_test.c
new file mode 100644
index 000000000000..ebd43de02543
--- /dev/null
+++ b/net/mptcp/sockopt_test.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <kunit/test.h>
+
+#include "protocol.h"
+
+static void mptcp_sockopt_reuseaddr(struct kunit *test)
+{
+	struct socket *sock;
+	int err, reuse = 1;
+
+	err = sock_create_kern(&init_net, AF_INET, SOCK_STREAM, IPPROTO_MPTCP,
+			       &sock);
+	KUNIT_ASSERT_EQ(test, err, 0);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, sock);
+
+	err = sock_common_setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
+				     KERNEL_SOCKPTR(&reuse), sizeof(reuse));
+
+	KUNIT_EXPECT_EQ(test, err, 0);
+
+	sock_release(sock);
+}
+
+static struct kunit_case mptcp_sockopt_test_cases[] = {
+	KUNIT_CASE(mptcp_sockopt_reuseaddr),
+	{}
+};
+
+static struct kunit_suite mptcp_sockopt_suite = {
+	.name = "mptcp-sockopt",
+	.test_cases = mptcp_sockopt_test_cases,
+};
+
+kunit_test_suite(mptcp_sockopt_suite);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("KUnit tests for MPTCP sockopt");
-- 
2.55.0

Re: [PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking

[Matthieu Baerts]

Hi Geliang,

On 16/10/2026 03:35, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> Add a KUnit test to verify that MPTCP sockets have a distinct lockdep
> class from their subflows. The test creates a kernel MPTCP socket and
> sets SO_REUSEADDR, which triggers the code path where
> mptcp_setsockopt_sol_socket() locks the MPTCP socket and then calls
> sk_setsockopt() on the subflow.
Good idea to add this test. Could we also have a test for passive
connections? (Or is it something that doesn't make sense to support with
a kernel socket?)


Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets

[MPTCP CI]

Hi Geliang,

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! ✅
- Perf: Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/38837878897

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/107f77088af0
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1186840


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)