All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH mptcp-next v2 0/4] Add MPTCP support for NBD
@ 2026-10-26 10:35 Geliang Tang
  2026-10-26 10:35 ` [PATCH mptcp-next v2 1/4] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
                   ` (4 more replies)
  0 siblings, 5 replies; 11+ messages in thread
From: Geliang Tang @ 2026-10-26 10:35 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang

From: Geliang Tang <tanggeliang@kylinos.cn>

This series adds MPTCP (Multipath TCP) support to NBD (Network Block
Device) and includes comprehensive tests.

MPTCP can aggregate bandwidth from multiple network interfaces, providing
significant performance improvements in multi-NIC scenarios. Our tests
with 4 virtual NICs (each limited to 1000 Mbit/s / 125 MB/s) show ~4x
bandwidth improvement: TCP achieves ~110 MiB/s while MPTCP achieves
~400 MiB/s for both read and write operations.

Patch 1 gives MPTCP sockets a distinct lockdep class to prevent
false positive lockdep warnings when MPTCP master sockets and their
subflow sockets are used together in the same lock chain.

Patch 2 adds a set_memalloc protocol callback to struct proto that
allows protocols to propagate SOCK_MEMALLOC flag and allocation
settings to their sub-sockets automatically. MPTCP implements this
callback to sync memalloc settings to all subflow sockets.

Patch 3 adds MPTCP socket support to the kernel NBD driver by
allowing MPTCP sockets in nbd_get_socket().

Patch 4 adds a comprehensive test script (mptcp_nbd.sh) that
validates NBD over both TCP and MPTCP.

v2:
- Add lockdep class distinction for MPTCP sockets (patch 1)
- Add set_memalloc protocol callback for automatic subflow sync (patch 2)
- update selfetsts.

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

Geliang Tang (4):
  mptcp: give MPTCP sockets a distinct lockdep class
  sock: add set_memalloc protocol callback
  nbd: allow MPTCP sockets
  selftests: mptcp: add mptcp nbd tests

 drivers/block/nbd.c                           |   5 +-
 include/net/sock.h                            |   1 +
 net/core/sock.c                               |   8 +
 net/mptcp/pm_kernel.c                         |  16 -
 net/mptcp/protocol.c                          |  58 ++-
 tools/testing/selftests/net/mptcp/Makefile    |   1 +
 tools/testing/selftests/net/mptcp/config      |   1 +
 .../testing/selftests/net/mptcp/mptcp_lib.sh  |  13 +
 .../testing/selftests/net/mptcp/mptcp_nbd.sh  | 373 ++++++++++++++++++
 9 files changed, 458 insertions(+), 18 deletions(-)
 create mode 100755 tools/testing/selftests/net/mptcp/mptcp_nbd.sh

-- 
2.55.0


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: [PATCH mptcp-next v2 3/4] nbd: allow MPTCP sockets
@ 2026-10-27 23:46 netdev-bot+sashiko
  0 siblings, 0 replies; 11+ messages in thread
From: netdev-bot+sashiko @ 2026-10-27 23:46 UTC (permalink / raw)
  To: geliang; +Cc: mptcp, tanggeliang, kuba

Thank you for your contribution! Sashiko AI review found 5 potential
issue(s) to consider.

Critical: 0 · High: 2 · Medium: 2 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] __sock_xmit() (drivers/block/nbd.c:583) calls
  sk_set_memalloc(sock->sk) inside the do/while loop, so it runs once…
- [High] Once NBD accepts an MPTCP msk, an in-kernel agent can hold the
  NBD data socket's lock while doing allocations that may reclaim.
- [Medium] With this patch an MPTCP msk can be attached to NBD.
- [Medium] nbd_reclassify_socket() (drivers/block/nbd.c:1248-1276)
  switches on sk_family and moves only the top-level socket lock into…
- [Low] The commit author is 'Geliang Tang <geliang@kernel.org>', but the
  only Signed-off-by is 'Geliang Tang <tanggeliang@kylinos.cn>'.

--

nbd: allow MPTCP sockets

This commit makes nbd_get_socket() accept MPTCP sockets as well as TCP
and stream UNIX sockets, by adding an msk_is_mptcp() check. The goal is
to get MPTCP bandwidth aggregation across several NICs for NBD traffic.

> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>

[Severity: Low]
This isn't a bug, but the author address (geliang@kernel.org) doesn't
match the Signed-off-by address (tanggeliang@kylinos.cn). checkpatch
reports this as FROM_SIGN_OFF_MISMATCH.

Could a matching Signed-off-by or From: line be added? The other patches
in the series seem to have the same mismatch.

> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index c5e26fc98d1aa..9cf89d53839a1 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c

[ ... ]

> @@ -1222,8 +1223,9 @@ static struct socket *nbd_get_socket(struct nbd_device *nbd, unsigned long fd,
>  		return NULL;
>  
>  	if (!sk_is_tcp(sock->sk) &&
> +	    !msk_is_mptcp(sock->sk) &&

[Severity: High]
Now that MPTCP sockets are accepted here, does the sk_set_memalloc() call
that runs on every loop iteration in __sock_xmit() cause problems on the
I/O path?

drivers/block/nbd.c:__sock_xmit() {
    ...
		do {
			sock->sk->sk_allocation = GFP_NOIO | __GFP_MEMALLOC;
			sock->sk->sk_use_task_frag = false;
			sk_set_memalloc(sock->sk);
			msg.msg_flags = msg_flags | MSG_NOSIGNAL;
    ...
}

That call came from the earlier "sock: add set_memalloc protocol
callback" commit in this series. sk_set_memalloc() increments the global
static key every time, even when SOCK_MEMALLOC is already set:

net/core/sock.c:sk_set_memalloc() {
	sock_set_flag(sk, SOCK_MEMALLOC);
	sk->sk_allocation |= __GFP_MEMALLOC;
	static_branch_inc(&memalloc_socks_key);
	...
}

NBD never calls sk_clear_memalloc(). So memalloc_socks_key goes up once
per send/recv fragment and never comes down. Each increment takes
cpus_read_lock() through static_key_slow_inc().

When the count reaches INT_MAX, static_key_slow_inc_cpuslocked() hits
WARN_ON_ONCE(). After that, every call takes jump_label_mutex.

For MPTCP, each iteration also calls mptcp_set_memalloc(). That takes
lock_sock() on the msk and lock_sock_nested() on every subflow before the
actual sendmsg/recvmsg:

net/mptcp/protocol.c:mptcp_set_memalloc() {
	...
	lock_sock(sk);
	memalloc = sock_flag(sk, SOCK_MEMALLOC);
	mptcp_for_each_subflow(msk, subflow) {
		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);

		lock_sock_nested(ssk, SINGLE_DEPTH_NESTING);
	...
}

Should this setup happen once at attach time, as nbd_start_device() and
nbd_reconnect_socket() already do it, and be undone at teardown?

[Severity: Medium]
Do MPTCP subflows created after the socket is attached get the
reclaim-safe settings?

mptcp_set_memalloc() copies SOCK_MEMALLOC, sk_allocation and
sk_use_task_frag only to the subflows that are on msk->conn_list when it
runs. Subflows still on join_list are skipped.

The PM worker creates new subflows through:

mptcp_worker()->mptcp_pm_worker()->__mptcp_subflow_connect()->
    mptcp_subflow_create_socket()->sock_create_kern()

These start with GFP_KERNEL, SOCK_MEMALLOC clear and sk_use_task_frag
set. mptcp_sockopt_sync_locked() doesn't copy these fields, and nothing
else in net/mptcp/ appears to write them.

Until some later __sock_xmit() iteration resyncs them, can
sk_filter_trim_cap() drop pfmemalloc skbs that arrive on such a subflow?
Can the subflow's allocations also enter reclaim in a swap-over-NBD
setup?

And if the sk_set_memalloc() call is moved to attach time, would late
subflows ever be covered?

[Severity: High]
Can this add a reclaim deadlock that plain TCP NBD sockets don't have?

mptcp_worker() holds the msk socket lock while the PM creates subflows:

net/mptcp/protocol.c:mptcp_worker() {
	...
	lock_sock(sk);
	...
	mptcp_pm_worker(msk);
	...
}

mptcp_pm_worker() reaches __mptcp_subflow_connect(). That calls
mptcp_subflow_create_socket()->sock_create_kern(), which does a
GFP_KERNEL sk_alloc. It then calls kernel_connect(), where tcp_connect()
allocates with the subflow's default GFP_KERNEL sk_allocation. The
userspace PM does the same under lock_sock(). None of this runs under
memalloc_noio_save().

Suppose one of those allocations enters direct reclaim and waits on
writeback or swap-out to the NBD device. The NBD I/O that reclaim is
waiting for also needs the msk lock:

__sock_xmit()->sk_set_memalloc()->mptcp_set_memalloc()->lock_sock(msk)
__sock_xmit()->sock_sendmsg()->mptcp_sendmsg()->lock_sock(msk)
__sock_xmit()->sock_recvmsg()->mptcp_recvmsg()->lock_sock(msk)

The timeout path doesn't seem to break the cycle either:
nbd_xmit_timeout()->sock_shutdown()->kernel_sock_shutdown()->
mptcp_shutdown() also takes lock_sock(msk).

The NBD peer can trigger subflow creation remotely, for example with an
ADD_ADDR. That is the multi-subflow setup the commit message describes.

Does anything prevent this cycle: reclaim waits on NBD, NBD waits on the
msk lock, and the msk lock holder waits on reclaim?

[Severity: Medium]
Could this bring back the lockdep circular dependency that commit
d532cddb6c60 ("nbd: Reclassify sockets to avoid lockdep circular
dependency") removed?

nbd_reclassify_socket() reclassifies only the top-level sock. For MPTCP,
that means only the msk lock moves to the sk_lock-AF_INET(6)-NBD class:

drivers/block/nbd.c:nbd_reclassify_socket() {
	...
	switch (sk->sk_family) {
	case AF_INET:
		sock_lock_init_class_and_name(sk, "slock-AF_INET-NBD",
	...
}

The subflows come from sock_create_kern(). They stay in the shared
k-sk_lock-AF_INET(6) class that every kernel TCP socket uses.

NBD I/O takes those subflow locks while holding the NBD-classed msk lock.
Examples are lock_sock(ssk) in __mptcp_push_pending() and
lock_sock_nested(ssk) in mptcp_set_memalloc().

Lockdep already records fs_reclaim -> sk_lock-AF_INET-NBD, so this adds
fs_reclaim -> k-sk_lock-AF_INET.

Any kernel TCP socket in that class that allocates with GFP_KERNEL under
lock_sock() records the reverse edge. One example is
__mptcp_subflow_connect()->kernel_connect()->tcp_connect() on a join
subflow.

Do the subflow locks need to be reclassified too?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1793010744.git.tanggeliang%40kylinos.cn

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2026-10-27 23:46 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-26 10:35 [PATCH mptcp-next v2 0/4] Add MPTCP support for NBD Geliang Tang
2026-10-26 10:35 ` [PATCH mptcp-next v2 1/4] mptcp: give MPTCP sockets a distinct lockdep class Geliang Tang
2026-10-26 11:27   ` sashiko-bot
2026-10-26 10:35 ` [PATCH mptcp-next v2 2/4] sock: add set_memalloc protocol callback Geliang Tang
2026-10-26 11:46   ` sashiko-bot
2026-10-26 10:35 ` [PATCH mptcp-next v2 3/4] nbd: allow MPTCP sockets Geliang Tang
2026-10-26 12:14   ` sashiko-bot
2026-10-26 10:35 ` [PATCH mptcp-next v2 4/4] selftests: mptcp: add mptcp nbd tests Geliang Tang
2026-10-26 12:32   ` sashiko-bot
2026-10-26 12:04 ` [PATCH mptcp-next v2 0/4] Add MPTCP support for NBD MPTCP CI
  -- strict thread matches above, loose matches on Subject: below --
2026-10-27 23:46 [PATCH mptcp-next v2 3/4] nbd: allow MPTCP sockets netdev-bot+sashiko

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.