WARNING in sk_stream_kill_queues #172
Assignees
Labels
Comments
|
My CI got the issue again: |
|
@pabeni : I was able to reproduce it locally \o/ |
something as simple as: |
|
@pabeni: thank you for the suggestion! I got the debug line: $ ./mptcp_connect.sh -l 0.99% -d 4 -r '94% 99%'
[ 6.413292] IPv6: ADDRCONF(NETDEV_CHANGE): ns1eth2: link becomes ready
[ 6.836783] IPv6: ADDRCONF(NETDEV_CHANGE): ns2eth3: link becomes ready
[ 7.018194] IPv6: ADDRCONF(NETDEV_CHANGE): ns2eth1: link becomes ready
[ 7.244303] IPv6: ADDRCONF(NETDEV_CHANGE): ns4eth3: link becomes ready
[ 7.249847] IPv6: ADDRCONF(NETDEV_CHANGE): ns3eth4: link becomes ready
# INFO: set ns3-60942489-xeVvp0 dev ns3eth2: ethtool -K gso off
# INFO: set ns4-60942489-xeVvp0 dev ns4eth3: ethtool -K tso off gso off
# Created /tmp/tmp.nhFXn1i8T6 (size 7654428 /tmp/tmp.nhFXn1i8T6) containing data sent by client
# Created /tmp/tmp.gPDCwooLju (size 7000092 /tmp/tmp.gPDCwooLju) containing data sent by server
# New MPTCP socket can be blocked via sysctl [ OK ]
# setsockopt(..., TCP_ULP, "mptcp", ...) blocked [ OK ]
# INFO: validating network environment with pings
[ 12.091048] netem: version 1.3
# INFO: Using loss of 0.99% delay 4 ms reorder 94% 99% with delay 1ms on ns3eth4
# ns1 MPTCP -> ns1 (10.0.1.1:10000 ) MPTCP (duration 442ms) [ OK ]
# ns1 MPTCP -> ns1 (10.0.1.1:10001 ) TCP (duration 127ms) [ OK ]
# ns1 TCP -> ns1 (10.0.1.1:10002 ) MPTCP (duration 218ms) [ OK ]
# ns1 MPTCP -> ns1 (dead:beef:1::1:10003) MPTCP (duration 161ms) [ OK ]
# ns1 MPTCP -> ns1 (dead:beef:1::1:10004) TCP (duration 133ms) [ OK ]
# ns1 TCP -> ns1 (dead:beef:1::1:10005) MPTCP (duration 114ms) [ OK ]
# ns1 MPTCP -> ns2 (10.0.1.2:10006 ) MPTCP (duration 132ms) [ OK ]
# ns1 MPTCP -> ns2 (dead:beef:1::2:10007) MPTCP (duration 139ms) [ OK ]
# ns1 MPTCP -> ns2 (10.0.2.1:10008 ) MPTCP (duration 150ms) [ OK ]
# ns1 MPTCP -> ns2 (dead:beef:2::1:10009) MPTCP (duration 158ms) [ OK ]
# ns1 MPTCP -> ns3 (10.0.2.2:10010 ) MPTCP [ 24.320970] ------------[ cut here ]------------
[ 24.325588] WARNING: CPU: 0 PID: 171 at net/core/stream.c:208 sk_stream_kill_queues (net/core/stream.c:208 (discriminator 1))
[ 24.333582] Modules linked in: sch_netem
[ 24.337218] CPU: 0 PID: 171 Comm: kworker/0:2 Not tainted 5.12.0+ #25
[ 24.343110] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[ 24.351637] Workqueue: events mptcp_worker
[ 24.355617] RIP: 0010:sk_stream_kill_queues (net/core/stream.c:208 (discriminator 1))
[ 24.360406] Code: 00 85 c0 75 1f 85 f6 75 21 5b 5d c3 48 89 df e8 73 ec fe ff 8b 83 48 01 00 00 8b b3 00 01 00 00 85 c0 74 e1 0f 0b 85 f6 74 df <0f> 0b 5b 5d c3 0f 0b eb ac 0f 1f 40 00 0f 1f 44 00 00 41 57 41 56
All code
========
0: 00 85 c0 75 1f 85 add %al,-0x7ae08a40(%rbp)
6: f6 75 21 divb 0x21(%rbp)
9: 5b pop %rbx
a: 5d pop %rbp
b: c3 retq
c: 48 89 df mov %rbx,%rdi
f: e8 73 ec fe ff callq 0xfffffffffffeec87
14: 8b 83 48 01 00 00 mov 0x148(%rbx),%eax
1a: 8b b3 00 01 00 00 mov 0x100(%rbx),%esi
20: 85 c0 test %eax,%eax
22: 74 e1 je 0x5
24: 0f 0b ud2
26: 85 f6 test %esi,%esi
28: 74 df je 0x9
2a:* 0f 0b ud2 <-- trapping instruction
2c: 5b pop %rbx
2d: 5d pop %rbp
2e: c3 retq
2f: 0f 0b ud2
31: eb ac jmp 0xffffffffffffffdf
33: 0f 1f 40 00 nopl 0x0(%rax)
37: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
3c: 41 57 push %r15
3e: 41 56 push %r14
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: 5b pop %rbx
3: 5d pop %rbp
4: c3 retq
5: 0f 0b ud2
7: eb ac jmp 0xffffffffffffffb5
9: 0f 1f 40 00 nopl 0x0(%rax)
d: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
12: 41 57 push %r15
14: 41 56 push %r14
[ 24.377001] RSP: 0018:ffff97e74035fdf8 EFLAGS: 00010206
[ 24.381861] RAX: 0000000000000000 RBX: ffff92aa42f695c0 RCX: 0000000000000000
[ 24.388290] RDX: ffffffffbdcf8a50 RSI: 000000000000010a RDI: ffff92aa42f695c0
[ 24.394599] RBP: ffff92aa42f69670 R08: 0000000000000000 R09: ffffffffbd049900
[ 24.401117] R10: ffff92aa42cd6e00 R11: 0000000000000001 R12: ffff97e74035fe10
[ 24.407650] R13: ffff92aa42f69b90 R14: ffff92aabdc2d100 R15: 0000000000000000
[ 24.419952] FS: 0000000000000000(0000) GS:ffff92aabdc00000(0000) knlGS:0000000000000000
[ 24.427317] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 24.432644] CR2: 000055bfe9b3a9f0 CR3: 0000000002cc6000 CR4: 00000000003506f0
[ 24.439157] Call Trace:
[ 24.441590] __mptcp_destroy_sock (net/mptcp/protocol.c:2640 (discriminator 3))
[ 24.445609] mptcp_worker (net/mptcp/protocol.c:2396)
[ 24.449112] process_one_work (kernel/workqueue.c:2275)
[ 24.453011] worker_thread (include/linux/list.h:282)
[ 24.456487] ? process_one_work (kernel/workqueue.c:2364)
[ 24.460430] kthread (kernel/kthread.c:313)
[ 24.463436] ? kthread_park (kernel/kthread.c:266)
[ 24.466792] ret_from_fork (arch/x86/entry/entry_64.S:294)
[ 24.470195] ---[ end trace 130998adc1f76743 ]---
[ 24.474711] MPTCP: msk=000000000469329e fwd=266
[ 24.475022] ------------[ cut here ]------------
[ 24.484046] WARNING: CPU: 0 PID: 10 at net/ipv4/af_inet.c:157 inet_sock_destruct (net/ipv4/af_inet.c:157 (discriminator 1))
[ 24.491830] Modules linked in: sch_netem
[ 24.496108] CPU: 0 PID: 10 Comm: ksoftirqd/0 Tainted: G W 5.12.0+ #25
[ 24.503854] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[ 24.512904] RIP: 0010:inet_sock_destruct (net/ipv4/af_inet.c:157 (discriminator 1))
[ 24.517998] Code: bc 24 30 01 00 00 5b 41 5c e9 f7 eb f2 ff 41 0f b6 44 24 12 3c 07 74 8f e9 ea fb 21 00 4c 89 e7 e8 20 54 f0 ff e9 71 ff ff ff <0f> 0b eb b6 0f 0b 41 8b 84 24 4c 01 00 00 85 c0 74 90 0f 0b 41 8b
All code
========
0: bc 24 30 01 00 mov $0x13024,%esp
5: 00 5b 41 add %bl,0x41(%rbx)
8: 5c pop %rsp
9: e9 f7 eb f2 ff jmpq 0xfffffffffff2ec05
e: 41 0f b6 44 24 12 movzbl 0x12(%r12),%eax
14: 3c 07 cmp $0x7,%al
16: 74 8f je 0xffffffffffffffa7
18: e9 ea fb 21 00 jmpq 0x21fc07
1d: 4c 89 e7 mov %r12,%rdi
20: e8 20 54 f0 ff callq 0xfffffffffff05445
25: e9 71 ff ff ff jmpq 0xffffffffffffff9b
2a:* 0f 0b ud2 <-- trapping instruction
2c: eb b6 jmp 0xffffffffffffffe4
2e: 0f 0b ud2
30: 41 8b 84 24 4c 01 00 mov 0x14c(%r12),%eax
37: 00
38: 85 c0 test %eax,%eax
3a: 74 90 je 0xffffffffffffffcc
3c: 0f 0b ud2
3e: 41 rex.B
3f: 8b .byte 0x8b
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: eb b6 jmp 0xffffffffffffffba
4: 0f 0b ud2
6: 41 8b 84 24 4c 01 00 mov 0x14c(%r12),%eax
d: 00
e: 85 c0 test %eax,%eax
10: 74 90 je 0xffffffffffffffa2
12: 0f 0b ud2
14: 41 rex.B
15: 8b .byte 0x8b
[ 24.539219] RSP: 0018:ffff97e74005bb08 EFLAGS: 00010206
[ 24.545482] RAX: 000000000000010a RBX: ffff92aa42f69670 RCX: 0000000000000010
[ 24.561087] RDX: 0000000000000000 RSI: 000000000000010a RDI: ffff92aa42f69670
[ 24.567758] RBP: ffff92aa42f695c0 R08: ffff92aa42f6970c R09: 0000000000000000
[ 24.573760] R10: 0000000000000000 R11: 0000000000000000 R12: ffff92aa42f695c0
[ 24.579685] R13: ffff92aa42f26400 R14: ffff92aa443c9914 R15: ffff92aa443c9900
[ 24.585715] FS: 0000000000000000(0000) GS:ffff92aabdc00000(0000) knlGS:0000000000000000
[ 24.592601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 24.597588] CR2: 000055bfe9b3a9f0 CR3: 000000004ea10000 CR4: 00000000003506f0
[ 24.603650] Call Trace:
[ 24.605858] __sk_destruct (net/core/sock.c:1795)
[ 24.609145] subflow_ulp_release (include/net/sock.h:1813)
[ 24.612801] tcp_cleanup_ulp (net/ipv4/tcp_ulp.c:124)
[ 24.616176] tcp_v4_destroy_sock (net/ipv4/tcp_ipv4.c:2234)
[ 24.619902] inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:887 (discriminator 9))
[ 24.623763] tcp_rcv_state_process (net/ipv4/tcp_input.c:6496)
[ 24.627598] ? security_sock_rcv_skb (security/security.c:2204 (discriminator 19))
[ 24.631437] ? sk_filter_trim_cap (net/core/filter.c:156)
[ 24.635152] ? tcp_v4_inbound_md5_hash.constprop.0 (net/ipv4/tcp_ipv4.c:1416)
[ 24.640109] tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1716)
[ 24.643409] tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2077)
[ 24.646483] ? icmpv6_rcv (include/linux/skbuff.h:4085)
[ 24.649811] ip_protocol_deliver_rcu (net/ipv4/ip_input.c:204 (discriminator 1))
[ 24.653709] ip_local_deliver_finish (include/linux/rcupdate.h:74)
[ 24.657511] ip_local_deliver (include/linux/netfilter.h:301)
[ 24.660931] ? tcp_v4_early_demux (include/net/dst.h:469)
[ 24.664789] ? ip_rcv_finish_core.isra.0 (net/ipv4/ip_input.c:342)
[ 24.669087] ip_rcv (include/linux/netfilter.h:302)
[ 24.671775] __netif_receive_skb_one_core (net/core/dev.c:5440 (discriminator 4))
[ 24.676139] process_backlog (include/linux/rcupdate.h:74)
[ 24.679614] __napi_poll (net/core/dev.c:6966)
[ 24.682659] net_rx_action (net/core/dev.c:7035)
[ 24.685918] __do_softirq (kernel/softirq.c:559)
[ 24.689150] run_ksoftirqd (arch/x86/include/asm/irqflags.h:45)
[ 24.692365] smpboot_thread_fn (kernel/smpboot.c:165)
[ 24.696047] ? sort_range (kernel/smpboot.c:108)
[ 24.699192] kthread (kernel/kthread.c:313)
[ 24.702002] ? kthread_park (kernel/kthread.c:266)
[ 24.705210] ret_from_fork (arch/x86/entry/entry_64.S:294)
[ 24.708340] ---[ end trace 130998adc1f76744 ]---
(duration 405ms) [ OK ]
# ns1 MPTCP -> ns3 (dead:beef:2::2:10011) MPTCP (duration 166ms) [ OK ]
# ns1 MPTCP -> ns3 (10.0.3.2:10012 ) MPTCP (duration 166ms) [ OK ]
# ns1 MPTCP -> ns3 (dead:beef:3::2:10013) MPTCP (duration 190ms) [ OK ]
# ns1 MPTCP -> ns4 (10.0.3.1:10014 ) MPTCP (duration 431ms) [ OK ]
# ns1 MPTCP -> ns4 (dead:beef:3::1:10015) MPTCP (duration 226ms) [ OK ]
# ns2 MPTCP -> ns1 (10.0.1.1:10016 ) MPTCP (duration 138ms) [ OK ]
# ns2 MPTCP -> ns1 (dead:beef:1::1:10017) MPTCP (duration 123ms) [ OK ]
# ns2 MPTCP -> ns3 (10.0.2.2:10018 ) MPTCP (duration 299ms) [ OK ]
# ns2 MPTCP -> ns3 (dead:beef:2::2:10019) MPTCP (duration 775ms) [ OK ]
# ns2 MPTCP -> ns3 (10.0.3.2:10020 ) MPTCP (duration 169ms) [ OK ]
# ns2 MPTCP -> ns3 (dead:beef:3::2:10021) MPTCP (duration 882ms) [ OK ]
# ns2 MPTCP -> ns4 (10.0.3.1:10022 ) MPTCP (duration 273ms) [ OK ]
# ns2 MPTCP -> ns4 (dead:beef:3::1:10023) MPTCP (duration 185ms) [ OK ]
# ns3 MPTCP -> ns1 (10.0.1.1:10024 ) MPTCP (duration 335ms) [ OK ]
# ns3 MPTCP -> ns1 (dead:beef:1::1:10025) MPTCP (duration 176ms) [ OK ]
# ns3 MPTCP -> ns2 (10.0.1.2:10026 ) MPTCP (duration 376ms) [ OK ]
# ns3 MPTCP -> ns2 (dead:beef:1::2:10027) MPTCP (duration 871ms) [ OK ]
# ns3 MPTCP -> ns2 (10.0.2.1:10028 ) MPTCP (duration 197ms) [ OK ]
# ns3 MPTCP -> ns2 (dead:beef:2::1:10029) MPTCP (duration 194ms) [ OK ]
# ns3 MPTCP -> ns4 (10.0.3.1:10030 ) MPTCP (duration 122ms) [ OK ]
# ns3 MPTCP -> ns4 (dead:beef:3::1:10031) MPTCP (duration 139ms) [ OK ]
# ns4 MPTCP -> ns1 (10.0.1.1:10032 ) MPTCP (duration 241ms) [ OK ]
# ns4 MPTCP -> ns1 (dead:beef:1::1:10033) MPTCP (duration 1049ms) [ OK ]
# ns4 MPTCP -> ns2 (10.0.1.2:10034 ) MPTCP (duration 1094ms) [ OK ]
# ns4 MPTCP -> ns2 (dead:beef:1::2:10035) MPTCP (duration 222ms) [ OK ]
# ns4 MPTCP -> ns2 (10.0.2.1:10036 ) MPTCP (duration 186ms) [ OK ]
# ns4 MPTCP -> ns2 (dead:beef:2::1:10037) MPTCP (duration 1527ms) [ OK ]
# ns4 MPTCP -> ns3 (10.0.2.2:10038 ) MPTCP (duration 156ms) [ OK ]
# ns4 MPTCP -> ns3 (dead:beef:2::2:10039) MPTCP (duration 161ms) [ OK ]
# ns4 MPTCP -> ns3 (10.0.3.2:10040 ) MPTCP (duration 147ms) [ OK ]
# ns4 MPTCP -> ns3 (dead:beef:3::2:10041) MPTCP (duration 154ms) [ OK ]
# INFO: with peek mode: saveWithPeek
# ns1 MPTCP -> ns1 (10.0.1.1:10042 ) MPTCP (duration 166ms) [ OK ]
# ns1 MPTCP -> ns1 (10.0.1.1:10043 ) TCP (duration 113ms) [ OK ]
# ns1 TCP -> ns1 (10.0.1.1:10044 ) MPTCP (duration 129ms) [ OK ]
# ns1 MPTCP -> ns1 (dead:beef:1::1:10045) MPTCP (duration 163ms) [ OK ]
# ns1 MPTCP -> ns1 (dead:beef:1::1:10046) TCP (duration 122ms) [ OK ]
# ns1 TCP -> ns1 (dead:beef:1::1:10047) MPTCP (duration 114ms) [ OK ]
# INFO: with peek mode: saveAfterPeek
# ns1 MPTCP -> ns1 (10.0.1.1:10048 ) MPTCP (duration 179ms) [ OK ]
# ns1 MPTCP -> ns1 (10.0.1.1:10049 ) TCP (duration 139ms) [ OK ]
# ns1 TCP -> ns1 (10.0.1.1:10050 ) MPTCP (duration 117ms) [ OK ]
# ns1 MPTCP -> ns1 (dead:beef:1::1:10051) MPTCP (duration 164ms) [ OK ]
# ns1 MPTCP -> ns1 (dead:beef:1::1:10052) TCP (duration 114ms) [ OK ]
# ns1 TCP -> ns1 (dead:beef:1::1:10053) MPTCP (duration 127ms) [ OK ]
# Time: 74 seconds
++ rc=0 |
|
not sure if the following is the root cause, but looks like currently we could update sk_forward_memory without owning the mptcp_data_lock() in: mptcp_worker() -> __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_clean_una() [memory pressure] -> __mptcp_update_wmem() @matttbe: could you please test the following patch: I think calling clean_una there is not required, will be done shortly later at msk socket lock release time. Additionally, could you please add pr_warn() just around all *reclaim_partial() calls ? |
|
@pabeni : thank you for the patch! After 10 attempts, I got this error: It looks different, no? |
matttbe
pushed a commit
that referenced
this issue
May 17, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 18, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 19, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
|
When trying to reproduce #192 with perf, I got this warning after 14 hours of tests: On top of yesterday's In perf.zip file, we can file:
|
|
Not sure if this one is useful then :-/ |
|
I had it again, without perf, with @pabeni's 4th patch: On top of yesterday's |
matttbe
pushed a commit
that referenced
this issue
May 20, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
May 20, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
May 20, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
May 20, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 21, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 22, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 24, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 25, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() -> __mptcp_update_wmem() We can hit the above only under memory pressure. When that happen, forward memory accounting could be corrupted, as reported by Matt. Address the issue creating a new variant of __mptcp_clean_una_wakeup() which handle fwd memory updates with the proper care and invoking such new helper in the relevant code path. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
May 25, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
May 25, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 26, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 27, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 28, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 29, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 30, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
zx2c4-bot
pushed a commit
to WireGuard/wireguard-linux
that referenced
this issue
May 30, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: multipath-tcp/mptcp_net-next#172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
May 31, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
May 31, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 1, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 2, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 3, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 3, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 4, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 4, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 4, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 4, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 4, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 4, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
jenkins-tessares
pushed a commit
that referenced
this issue
Jun 5, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 7, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 7, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 7, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 7, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
matttbe
pushed a commit
that referenced
this issue
Jun 7, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: #172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
hamadmarri
pushed a commit
to hamadmarri/linux
that referenced
this issue
Jun 9, 2021
[ Upstream commit b5941f0 ] MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: multipath-tcp/mptcp_net-next#172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
woodsts
pushed a commit
to woodsts/linux-stable
that referenced
this issue
Jun 10, 2021
[ Upstream commit b5941f0 ] MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: multipath-tcp/mptcp_net-next#172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Oct 9, 2021
MPTCP sk_forward_memory handling is a bit special, as such field is protected by the msk socket spin_lock, instead of the plain socket lock. Currently we have a code path updating such field without handling the relevant lock: __mptcp_retrans() -> __mptcp_clean_una_wakeup() Several helpers in __mptcp_clean_una_wakeup() will update sk_forward_alloc, possibly causing such field corruption, as reported by Matthieu. Address the issue providing and using a new variant of blamed function which explicitly acquires the msk spin lock. Fixes: 64b9cea ("mptcp: fix spurious retransmissions") Closes: multipath-tcp/mptcp_net-next#172 Reported-by: Matthieu Baerts <[email protected]> Tested-by: Matthieu Baerts <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]>
matttbe
pushed a commit
that referenced
this issue
May 20, 2024
Recent additions in BPF like cpu v4 instructions, test_bpf module exhibits the following failures: test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #313 BSWAP 16: 0x0123456789abcdef -> 0xefcd eBPF filter opcode 00d7 (@2) unsupported jited:0 301 PASS test_bpf: #314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 555 PASS test_bpf: #315 BSWAP 64: 0x0123456789abcdef -> 0x67452301 eBPF filter opcode 00d7 (@2) unsupported jited:0 268 PASS test_bpf: #316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 269 PASS test_bpf: #317 BSWAP 16: 0xfedcba9876543210 -> 0x1032 eBPF filter opcode 00d7 (@2) unsupported jited:0 460 PASS test_bpf: #318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 320 PASS test_bpf: #319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe eBPF filter opcode 00d7 (@2) unsupported jited:0 222 PASS test_bpf: #320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 273 PASS test_bpf: #344 BPF_LDX_MEMSX | BPF_B eBPF filter opcode 0091 (@5) unsupported jited:0 432 PASS test_bpf: #345 BPF_LDX_MEMSX | BPF_H eBPF filter opcode 0089 (@5) unsupported jited:0 381 PASS test_bpf: #346 BPF_LDX_MEMSX | BPF_W eBPF filter opcode 0081 (@5) unsupported jited:0 505 PASS test_bpf: #490 JMP32_JA: Unconditional jump: if (true) return 1 eBPF filter opcode 0006 (@1) unsupported jited:0 261 PASS test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed] Fix them by adding missing processing. Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Today, I'm replacing Christoph in sending bug reports about new warnings reported by the kernel :)
This was spot by my CI when running selftests (mptcp_connect) with the latest export branch and a non debug kernel:
Maybe similar to #136 ?The text was updated successfully, but these errors were encountered: