Changes in protocol.c

f1e30061 - tcp/dccp: remove icsk->icsk_ack.timeout

Mon, 24 Mar 2025 20:36:07 +0000

tcp/dccp: remove icsk->icsk_ack.timeouticsk->icsk_ack.timeout can be replaced by icsk->csk_delack_timer.expiresThis saves 8 bytes in TCP/DCCP sockets and helps for better cache locality.Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250324203607.703850-3-edumazet@google.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

a7c428ee - tcp/dccp: remove icsk->icsk_timeout

Mon, 24 Mar 2025 20:36:06 +0000

tcp/dccp: remove icsk->icsk_timeouticsk->icsk_timeout can be replaced by icsk->icsk_retransmit_timer.expiresThis saves 8 bytes in TCP/DCCP sockets and helps for better cache locality.Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250324203607.703850-2-edumazet@google.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

a17336b2 - mptcp: pm: avoid calling PM specific code from core

Fri, 07 Mar 2025 11:21:53 +0000

mptcp: pm: avoid calling PM specific code from coreWhen destroying an MPTCP socket, some userspace PM specific code wascalled from mptcp_destroy_common() in protocol.c. That feels wrong, andit is the only case.Instead, the core now calls mptcp_pm_destroy() from pm.c which is now incharge of cleaning the announced addresses list, and ask the differentPMs to do extra cleaning if needed, e.g. the userspace PM, if used, willclean the local addresses list.While at it, the userspace PM specific helper has been prefixed with'mptcp_userspace_pm_' like the other ones.No behavioural changes intended.Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-9-abef20ada03b@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

551a9ad7 - mptcp: pm: remove '_nl' from mptcp_pm_nl_work

Fri, 07 Mar 2025 11:21:48 +0000

mptcp: pm: remove '_nl' from mptcp_pm_nl_workCurrently, in-kernel PM specific helpers are prefixed with'mptcp_pm_nl_'. But here 'mptcp_pm_nl_work' is not specific to this PM:it is called from the core to call helpers, some of them needed by boththe in-kernel and userspace PMs.To avoid confusions, the '_nl' bit has been removed from the name.Also used 'worker' instead of 'work', similar to protocol.c's worker.No behavioural changes intended.Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250307-net-next-mptcp-pm-reorg-v1-4-abef20ada03b@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

483cec55 - net: use sock_kmemdup for ip_options

Fri, 28 Feb 2025 10:01:32 +0000

net: use sock_kmemdup for ip_optionsInstead of using sock_kmalloc() to allocate an ip_options and thenimmediately duplicate another ip_options to the newly allocated one inipv6_dup_options(), mptcp_copy_ip_options() and sctp_v4_copy_ip_options(),the newly added sock_kmemdup() helper can be used to simplify the code.Signed-off-by: Geliang Tang Reviewed-by: Kuniyuki Iwashima Acked-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/91ae749d66600ec6fb679e0e518fda6acb5c3e6f.1740735165.git.tanggeliang@kylinos.cnSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

e0ca4057 - mptcp: micro-optimize __mptcp_move_skb()

Tue, 18 Feb 2025 18:36:18 +0000

mptcp: micro-optimize __mptcp_move_skb()After the RX path refactor the mentioned function is expected to runfrequently, let's optimize it a bit.Scan for ready subflow from the last processed one, and stop aftertraversing the list once or reaching the msk memory limit - instead oflooking for dubious per-subflow conditions.Also re-order the memory limit checks, to avoid duplicate tests.Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250218-net-next-mptcp-rx-path-refactor-v1-7-4a47d90d7998@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

51fe9cb9 - mptcp: dismiss __mptcp_rmem()

Tue, 18 Feb 2025 18:36:17 +0000

mptcp: dismiss __mptcp_rmem()After the RX path refactor, it become a wrapper for sk_rmem_allocaccess, with a slightly misleading name. Just drop it.Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250218-net-next-mptcp-rx-path-refactor-v1-6-4a47d90d7998@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

6639498e - mptcp: cleanup mem accounting

Tue, 18 Feb 2025 18:36:15 +0000

mptcp: cleanup mem accountingAfter the previous patch, updating sk_forward_memory is cheap andwe can drop a lot of complexity from the MPTCP memory accounting,removing the custom fwd mem allocations for rmem.Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250218-net-next-mptcp-rx-path-refactor-v1-4-4a47d90d7998@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

bc68b0ef - mptcp: move the whole rx path under msk socket lock protection

Tue, 18 Feb 2025 18:36:14 +0000

mptcp: move the whole rx path under msk socket lock protectionAfter commit c2e6048fa1cf ("mptcp: fix race in release_cb") we canmove the whole MPTCP rx path under the socket lock leveraging therelease_cb.We can drop a bunch of spin_lock pairs in the receive functions, usea single receive queue and invoke __mptcp_move_skbs only when subflowsask for it.This will allow more cleanup in the next patch.Some changes are worth specific mention:The msk rcvbuf update now always happens under both the msk and thesubflow socket lock: we can drop a bunch of ONCE annotation andconsolidate the checks.When the skbs move is delayed at msk release callback time, even themsk rcvbuf update is delayed; additionally take care of such action in__mptcp_move_skbs().Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250218-net-next-mptcp-rx-path-refactor-v1-3-4a47d90d7998@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

f03afb3a - mptcp: drop __mptcp_fastopen_gen_msk_ackseq()

Tue, 18 Feb 2025 18:36:13 +0000

mptcp: drop __mptcp_fastopen_gen_msk_ackseq()When we will move the whole RX path under the msk socket lock, updatingthe already queued skb for passive fastopen socket at 3rd ack time willbe extremely painful and race proneThe map_seq for already enqueued skbs is used only to allow correctcoalescing with later data; preventing collapsing to the first skb ofa fastopen connect we can completely remove the__mptcp_fastopen_gen_msk_ackseq() helper.Before dropping this helper, a new item had to be added to themptcp_skb_cb structure. Because this item will be frequently tested inthe fast path -- almost on every packet -- and because there is freespace there, a single byte is used instead of a bitfield. This microoptimisation slightly reduces the number of CPU operations to do theassociated check.Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250218-net-next-mptcp-rx-path-refactor-v1-2-4a47d90d7998@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

619af16b - mptcp: handle fastopen disconnect correctly

Thu, 23 Jan 2025 18:05:56 +0000

mptcp: handle fastopen disconnect correctlySyzbot was able to trigger a data stream corruption: WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493 release_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703 mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 The root cause is the bad handling of disconnect() generated internallyby the MPTCP protocol in case of connect FASTOPEN errors.Address the issue increasing the socket disconnect counter even on sucha case, to allow other threads waiting on the same socket lock toproperly error out.Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures")Cc: stable@vger.kernel.orgReported-by: syzbot+ebc0b8ae5d3590b2c074@syzkaller.appspotmail.comCloses: https://lore.kernel.org/67605870.050a0220.37aaf.0137.GAE@google.comCloses: https://github.com/multipath-tcp/mptcp_net-next/issues/537Tested-by: syzbot+ebc0b8ae5d3590b2c074@syzkaller.appspotmail.comSigned-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250123-net-mptcp-syzbot-issues-v1-3-af73258a726f@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

f835bdae - net: remove init_dummy_netdev()

Mon, 13 Jan 2025 00:34:55 +0000

net: remove init_dummy_netdev()init_dummy_netdev() can initialize statically declared or embeddednet_devices. Such netdevs did not come from alloc_netdev_mqs().After recent work by Breno, there are the only two cases wherewe have do that.Switch those cases to alloc_netdev_mqs() and delete init_dummy_netdev().Dealing with static netdevs is not worth the maintenance burden.Reviewed-by: Alexander Lobakin Reviewed-by: Matthieu Baerts (NGI0) Reviewed-by: Joe Damato Link: https://patch.msgid.link/20250113003456.3904110-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

56b824eb - mptcp: prevent excessive coalescing on receive

Mon, 30 Dec 2024 18:12:32 +0000

mptcp: prevent excessive coalescing on receiveCurrently the skb size after coalescing is only limited by the skblayout (the skb must not carry frag_list). A single coalesced skbcovering several MSS can potentially fill completely the receivebuffer. In such a case, the snd win will zero until the receive bufferwill be empty again, affecting tput badly.Fixes: 8268ed4c9d19 ("mptcp: introduce and use mptcp_try_coalesce()")Cc: stable@vger.kernel.org # please delay 2 weeks after 6.13-final releaseSigned-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20241230-net-mptcp-rbuf-fixes-v1-3-8608af434ceb@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

551844f2 - mptcp: don't always assume copied data in mptcp_cleanup_rbuf()

Mon, 30 Dec 2024 18:12:31 +0000

mptcp: don't always assume copied data in mptcp_cleanup_rbuf()Under some corner cases the MPTCP protocol can end-up invokingmptcp_cleanup_rbuf() when no data has been copied, but such helperassumes the opposite condition.Explicitly drop such assumption and performs the costly call onlywhen strictly needed - before releasing the msk socket lock.Fixes: fd8976790a6c ("mptcp: be careful on MPTCP-level ack.")Cc: stable@vger.kernel.orgSigned-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20241230-net-mptcp-rbuf-fixes-v1-2-8608af434ceb@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

449e6912 - mptcp: fix recvbuffer adjust on sleeping rcvmsg

Mon, 30 Dec 2024 18:12:30 +0000

mptcp: fix recvbuffer adjust on sleeping rcvmsgIf the recvmsg() blocks after receiving some data - i.e. due toSO_RCVLOWAT - the MPTCP code will attempt multiple times toadjust the receive buffer size, wrongly accounting every time thecumulative of received data - instead of accounting only for thedelta.Address the issue moving mptcp_rcv_space_adjust just after thedata reception and passing it only the just received bytes.This also removes an unneeded difference between the TCP and MPTCPRX code path implementation.Fixes: 581302298524 ("mptcp: error out earlier on disconnect")Cc: stable@vger.kernel.orgSigned-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20241230-net-mptcp-rbuf-fixes-v1-1-8608af434ceb@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

b169e76e - mptcp: fix possible integer overflow in mptcp_reset_tout_timer

Thu, 07 Nov 2024 10:36:57 +0000

mptcp: fix possible integer overflow in mptcp_reset_tout_timerIn 'mptcp_reset_tout_timer', promote 'probe_timestamp' to unsigned longto avoid possible integer overflow. Compile tested only.Found by Linux Verification Center (linuxtesting.org) with SVACE.Signed-off-by: Dmitry Kandybka Link: https://patch.msgid.link/20241107103657.1560536-1-d.kandybka@gmail.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

ce7356ae - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust

Fri, 08 Nov 2024 10:58:17 +0000

mptcp: cope racing subflow creation in mptcp_rcv_space_adjustAdditional active subflows - i.e. created by the in kernel pathmanager - are included into the subflow list before starting the3whs.A racing recvmsg() spooling data received on an already establishedsubflow would unconditionally call tcp_cleanup_rbuf() on all thecurrent subflows, potentially hitting a divide by zero error onthe newly created ones.Explicitly check that the subflow is in a suitable state beforeinvoking tcp_cleanup_rbuf().Fixes: c76c6956566f ("mptcp: call tcp_cleanup_rbuf on subflows")Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/02374660836e1b52afc91966b7535c8c5f7bafb0.1731060874.git.pabeni@redhat.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

58130229 - mptcp: error out earlier on disconnect

Fri, 08 Nov 2024 10:58:16 +0000

mptcp: error out earlier on disconnectEric reported a division by zero splat in the MPTCP protocol:Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0Hardware name: Google Google Compute Engine/Google Compute Engine,BIOS Google 09/13/2024RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e80d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89RSP: 0018:ffffc900041f7930 EFLAGS: 00010293RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314bRDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885sock_recvmsg_nosec net/socket.c:1051 [inline]sock_recvmsg+0x1b2/0x250 net/socket.c:1073__sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265__do_sys_recvfrom net/socket.c:2283 [inline]__se_sys_recvfrom net/socket.c:2279 [inline]__x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7feb5d857559Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 4889 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002dRAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131cR13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdefand provided a nice reproducer.The root cause is the current bad handling of racing disconnect.After the blamed commit below, sk_wait_data() can return (witherror) with the underlying socket disconnected and a zero rcv_mss.Catch the error and return without performing any additionaloperations on the current socket.Reported-by: Eric Dumazet Fixes: 419ce133ab92 ("tcp: allow again tcp_disconnect() when threads are waiting")Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/8c82ecf71662ecbc47bf390f9905de70884c9f2d.1731060874.git.pabeni@redhat.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

5add80bf - mptcp: implement mptcp_pm_connection_closed

Mon, 21 Oct 2024 15:14:05 +0000

mptcp: implement mptcp_pm_connection_closedThe MPTCP path manager event handler mptcp_pm_connection_closedinterface has been added in the commit 1b1c7a0ef7f3 ("mptcp: Add pathmanager interface") but it was an empty function from then on.With such name, it sounds good to invoke mptcp_event with theMPTCP_EVENT_CLOSED event type from it. It also removes a bit ofduplicated code.Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20241021-net-next-mptcp-misc-6-13-v1-3-1ef02746504a@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c

581c8cbf - mptcp: annotate data-races around subflow->fully_established

Mon, 21 Oct 2024 15:14:04 +0000

mptcp: annotate data-races around subflow->fully_establishedWe introduce the same handling for potential data races with the'fully_established' flag in subflow as previously done formsk->fully_established.Additionally, we make a crucial change: convert the subflow's'fully_established' from 'bit_field' to 'bool' type. This isnecessary because methods for avoiding data races don't work wellwith 'bit_field'. Specifically, the 'READ_ONCE' needs to knowthe size of the variable being accessed, which is not supported in'bit_field'. Also, 'test_bit' expect the address of 'bit_field'.Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/516Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20241021-net-next-mptcp-misc-6-13-v1-2-1ef02746504a@kernel.orgSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/mptcp/protocol.c