All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH mptcp-next 0/2] Add MPTCP support for NBD
@ 2026-10-23  9:19 Geliang Tang
  2026-10-23  9:19 ` [PATCH mptcp-next 1/2] nbd: allow MPTCP sockets Geliang Tang
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Geliang Tang @ 2026-10-23  9:19 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.

The first patch adds MPTCP socket support to the kernel NBD driver by
allowing MPTCP sockets in nbd_get_socket().

The second patch adds a comprehensive test script (mptcp_nbd.sh) that
validates NBD over both TCP and MPTCP.

Geliang Tang (2):
  nbd: allow MPTCP sockets
  selftests: mptcp: add mptcp nbd tests

 drivers/block/nbd.c                           |   4 +-
 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  | 309 ++++++++++++++++++
 5 files changed, 327 insertions(+), 1 deletion(-)
 create mode 100755 tools/testing/selftests/net/mptcp/mptcp_nbd.sh

-- 
2.55.0


^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [PATCH mptcp-next 1/2] nbd: allow MPTCP sockets
@ 2026-10-24 22:42 netdev-bot+sashiko
  0 siblings, 0 replies; 9+ messages in thread
From: netdev-bot+sashiko @ 2026-10-24 22:42 UTC (permalink / raw)
  To: geliang; +Cc: mptcp, tanggeliang, kuba

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

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

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] NBD's memory-reserve setup for its socket does not reach the TCP
  subflows of an MPTCP socket.
- [High] Accepting MPTCP sockets lets an in-kernel, process-context
  worker hold the NBD msk socket lock while making reclaim-capable…
- [Medium] nbd_reclassify_socket() (drivers/block/nbd.c:1247-1274) moves
  only sock->sk into the NBD lock classes.

--

nbd: allow MPTCP sockets

This patch adds an msk_is_mptcp() check to nbd_get_socket(), so NBD
accepts MPTCP sockets as well as TCP and stream UNIX sockets. The
stated goal is to aggregate bandwidth across several NICs.

> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index ffce519bf0087..2aeb22b1ad40e 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c

[ ... ]

> @@ -1221,8 +1222,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]
Once an MPTCP socket is accepted here, does NBD's memalloc setup reach
the sockets that actually carry the traffic?

NBD marks sock->sk in nbd_start_device() and
nbd_genl_reconnect_sock_cb():

    sk_set_memalloc(config->socks[i]->sock->sk);

and __sock_xmit() sets:

    sock->sk->sk_allocation = GFP_NOIO | __GFP_MEMALLOC;
    sock->sk->sk_use_task_frag = false;

For MPTCP, sock->sk is the msk. The data travels on TCP subflows created
by mptcp_subflow_create_socket()->sock_create_kern().

sync_socket_options() in net/mptcp/sockopt.c copies SOCK_KEEPOPEN,
SOCK_LINGER, SOCK_DBG, priority, mark and similar settings to the
subflow. It does not copy SOCK_MEMALLOC or sk_allocation, and nothing
under net/mptcp/ seems to refer to SOCK_MEMALLOC.

On receive, tcp_v4_rcv()->tcp_filter()->sk_filter_trim_cap() checks
the subflow, not the msk:

net/core/filter.c:sk_filter_trim_cap() {
    ...
	if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC)) {
		NET_INC_STATS(sock_net(sk), LINUX_MIB_PFMEMALLOCDROP);
		return SKB_DROP_REASON_PFMEMALLOC;
	}
    ...
}

Because the msk is marked, sk_memalloc_socks() is enabled, and drivers
can pass up pfmemalloc RX skbs under memory pressure. Wouldn't every
NBD reply, and every retransmission, that arrives in such an skb be
dropped at the subflow?

Transmit allocations on the subflow (ACKs, SYNs, retransmit clones via
sk_gfp_mask(ssk, ...)) also keep the default GFP_KERNEL. Subflows that
the path manager adds later through __mptcp_subflow_connect() start
with the same defaults.

With swap or dirty writeback on an NBD-over-MPTCP device, can this
stall or livelock reclaim? Preventing that for TCP is the reason
sk_set_memalloc() is called. The commit message does not mention this
limitation.

[Severity: Medium]
Does nbd_reclassify_socket() still cover the socket locks NBD takes
when the socket is MPTCP?

nbd_reclassify_socket() only reclassifies sock->sk:

drivers/block/nbd.c:nbd_reclassify_socket() {
	struct sock *sk = sock->sk;
    ...
	case AF_INET:
		sock_lock_init_class_and_name(sk, "slock-AF_INET-NBD",
    ...
}

This helper came from commit d532cddb6c60 ("nbd: Reclassify sockets to
avoid lockdep circular dependency"). For MPTCP, only the msk lock moves
into the NBD class.

Every NBD send also takes subflow locks through
mptcp_sendmsg()->__mptcp_push_pending()->lock_sock(ssk). Subflows are
kernel sockets from sock_create_kern(), so they share the
k-sk_lock-AF_INET/AF_INET6 class with every other MPTCP subflow on the
system.

Ordinary MPTCP user sockets allocate with GFP_KERNEL while holding a
lock of that class. The path is
__subflow_push_pending()->mptcp_sendmsg_frag()->mptcp_alloc_tx_skb():

    gfp_t gfp = data_lock_held ? GFP_ATOMIC : sk->sk_allocation;

That records a k-sk_lock -> fs_reclaim dependency. Meanwhile, NBD I/O
issued under the block layer's reclaim ordering takes the same class.

Could this bring back the fs_reclaim/sk_lock circular dependency report
that d532cddb6c60 suppressed, this time through the subflow lock class?
Nothing seems to reclassify subflows, including the ones the path
manager creates later.

[Severity: High]
Can accepting MPTCP sockets lead to a deadlock between reclaim and the
msk socket lock?

mptcp_worker() runs on the system workqueue and holds the msk lock
while it runs the path manager and closes subflows:

net/mptcp/protocol.c:mptcp_worker() {
    ...
	lock_sock(sk);
    ...
	mptcp_pm_worker(msk);
    ...
	if (test_and_clear_bit(MPTCP_WORK_CLOSE_SUBFLOW, &msk->flags))
		__mptcp_close_subflow(sk);
    ...
}

>From there, __mptcp_subflow_connect() calls
mptcp_subflow_create_socket()->sock_create_kern() and
subflow_ulp_init()->subflow_create_ctx(sk, GFP_KERNEL). The subflow
close path also calls mptcp_close_ssk()->mptcp_event(..., GFP_KERNEL).
None of this runs under a memalloc_noio scope.

If direct reclaim in that worker waits on swap or writeback to the NBD
device, the NBD I/O needs the same msk lock:

    nbd_queue_rq()->sock_xmit()->mptcp_sendmsg()->lock_sock(msk)
    recv_work()->sock_xmit()->mptcp_recvmsg()->lock_sock(msk)

Wouldn't the worker and NBD then wait on each other?

There is also a self-deadlock case. If the worker's own reclaim flushes
a plug into the BLK_MQ_F_BLOCKING nbd queue from the worker's own
context, lock_sock() would wait on an msk that the same task already
holds.

The memalloc_noreclaim_save() call and the sk_allocation setting in
__sock_xmit() only cover the NBD task and allocations that use
sk_allocation. They do not cover explicit GFP_KERNEL allocations in the
MPTCP worker. With plain TCP, no in-kernel process context sleeps in
reclaim while holding the NBD socket lock.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-10-24 22:42 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-23  9:19 [PATCH mptcp-next 0/2] Add MPTCP support for NBD Geliang Tang
2026-10-23  9:19 ` [PATCH mptcp-next 1/2] nbd: allow MPTCP sockets Geliang Tang
2026-10-23  9:47   ` sashiko-bot
2026-10-24  9:24   ` Matthieu Baerts
2026-10-23  9:19 ` [PATCH mptcp-next 2/2] selftests: mptcp: add mptcp nbd tests Geliang Tang
2026-10-23  9:36   ` sashiko-bot
2026-10-23 10:31 ` [PATCH mptcp-next 0/2] Add MPTCP support for NBD MPTCP CI
2026-10-24  6:04 ` MPTCP CI
  -- strict thread matches above, loose matches on Subject: below --
2026-10-24 22:42 [PATCH mptcp-next 1/2] 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.