* [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets
@ 2026-10-16 1:35 Geliang Tang
2026-10-16 1:35 ` [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Geliang Tang @ 2026-10-16 1:35 UTC (permalink / raw)
To: mptcp; +Cc: 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class
2026-10-16 1:35 [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets Geliang Tang
@ 2026-10-16 1:35 ` Geliang Tang
2026-10-16 1:46 ` sashiko-bot
2026-10-16 8:03 ` Matthieu Baerts
2026-10-16 1:35 ` [PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking Geliang Tang
2026-10-16 2:49 ` [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets MPTCP CI
2 siblings, 2 replies; 7+ messages in thread
From: Geliang Tang @ 2026-10-16 1:35 UTC (permalink / raw)
To: mptcp; +Cc: 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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking
2026-10-16 1:35 [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets Geliang Tang
2026-10-16 1:35 ` [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
@ 2026-10-16 1:35 ` Geliang Tang
2026-10-16 8:05 ` Matthieu Baerts
2026-10-16 2:49 ` [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets MPTCP CI
2 siblings, 1 reply; 7+ messages in thread
From: Geliang Tang @ 2026-10-16 1:35 UTC (permalink / raw)
To: mptcp; +Cc: 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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class
2026-10-16 1:35 ` [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
@ 2026-10-16 1:46 ` sashiko-bot
2026-10-16 8:03 ` Matthieu Baerts
1 sibling, 0 replies; 7+ messages in thread
From: sashiko-bot @ 2026-10-16 1:46 UTC (permalink / raw)
To: Geliang Tang, mptcp
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets
2026-10-16 1:35 [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets Geliang Tang
2026-10-16 1:35 ` [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
2026-10-16 1:35 ` [PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking Geliang Tang
@ 2026-10-16 2:49 ` MPTCP CI
2 siblings, 0 replies; 7+ messages in thread
From: MPTCP CI @ 2026-10-16 2:49 UTC (permalink / raw)
To: Geliang Tang; +Cc: mptcp
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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class
2026-10-16 1:35 ` [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
2026-10-16 1:46 ` sashiko-bot
@ 2026-10-16 8:03 ` Matthieu Baerts
1 sibling, 0 replies; 7+ messages in thread
From: Matthieu Baerts @ 2026-10-16 8:03 UTC (permalink / raw)
To: Geliang Tang, mptcp; +Cc: Geliang Tang
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking
2026-10-16 1:35 ` [PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking Geliang Tang
@ 2026-10-16 8:05 ` Matthieu Baerts
0 siblings, 0 replies; 7+ messages in thread
From: Matthieu Baerts @ 2026-10-16 8:05 UTC (permalink / raw)
To: Geliang Tang, mptcp; +Cc: Geliang Tang
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-10-16 8:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-16 1:35 [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets Geliang Tang
2026-10-16 1:35 ` [PATCH mptcp-next v2 1/2] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
2026-10-16 1:46 ` sashiko-bot
2026-10-16 8:03 ` Matthieu Baerts
2026-10-16 1:35 ` [PATCH mptcp-next v2 2/2] mptcp: kunit: add sockopt test for subflow socket locking Geliang Tang
2026-10-16 8:05 ` Matthieu Baerts
2026-10-16 2:49 ` [PATCH mptcp-next v2 0/2] add distinct lockdep class for MPTCP sockets MPTCP CI
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.