packetdrill/fixes: clearing properly the status in listen()/disconnect #65

matttbe · 2020-07-23T16:29:15Z

It could be nice to add more coverage in packetdrill to check different scenarios with listen(), especially when getting disconnected. See @pabeni 's comment above

The current implementation of L2CAP options negotiation will continue the negotiation when a device responds with L2CAP_CONF_UNACCEPT ("unaccepted options"), but not when the device replies with L2CAP_CONF_UNKNOWN ("unknown options"). Trying to continue the negotiation without ERTM support will allow Bluetooth-capable XBox One controllers (notably models 1708 and 1797) to connect. btmon before patch: > ACL Data RX: Handle 256 flags 0x02 dlen 16 #64 [hci0] 59.182702 L2CAP: Connection Response (0x03) ident 2 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 256 flags 0x00 dlen 23 #65 [hci0] 59.182744 L2CAP: Configure Request (0x04) ident 3 len 15 Destination CID: 64 Flags: 0x0000 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 256 flags 0x02 dlen 16 #66 [hci0] 59.183948 L2CAP: Configure Request (0x04) ident 1 len 8 Destination CID: 64 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1480 < ACL Data TX: Handle 256 flags 0x00 dlen 18 #67 [hci0] 59.183994 L2CAP: Configure Response (0x05) ident 1 len 10 Source CID: 64 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1480 > ACL Data RX: Handle 256 flags 0x02 dlen 15 #69 [hci0] 59.187676 L2CAP: Configure Response (0x05) ident 3 len 7 Source CID: 64 Flags: 0x0000 Result: Failure - unknown options (0x0003) 04 . < ACL Data TX: Handle 256 flags 0x00 dlen 12 #70 [hci0] 59.187722 L2CAP: Disconnection Request (0x06) ident 4 len 4 Destination CID: 64 Source CID: 64 > ACL Data RX: Handle 256 flags 0x02 dlen 12 #73 [hci0] 59.192714 L2CAP: Disconnection Response (0x07) ident 4 len 4 Destination CID: 64 Source CID: 64 btmon after patch: > ACL Data RX: Handle 256 flags 0x02 dlen 16 #248 [hci0] 103.502970 L2CAP: Connection Response (0x03) ident 5 len 8 Destination CID: 65 Source CID: 65 Result: Connection pending (0x0001) Status: No further information available (0x0000) > ACL Data RX: Handle 256 flags 0x02 dlen 16 #249 [hci0] 103.504184 L2CAP: Connection Response (0x03) ident 5 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 256 flags 0x00 dlen 23 #250 [hci0] 103.504398 L2CAP: Configure Request (0x04) ident 6 len 15 Destination CID: 65 Flags: 0x0000 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 256 flags 0x02 dlen 16 #251 [hci0] 103.505472 L2CAP: Configure Request (0x04) ident 3 len 8 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1480 < ACL Data TX: Handle 256 flags 0x00 dlen 18 #252 [hci0] 103.505689 L2CAP: Configure Response (0x05) ident 3 len 10 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1480 > ACL Data RX: Handle 256 flags 0x02 dlen 15 #254 [hci0] 103.509165 L2CAP: Configure Response (0x05) ident 6 len 7 Source CID: 65 Flags: 0x0000 Result: Failure - unknown options (0x0003) 04 . < ACL Data TX: Handle 256 flags 0x00 dlen 12 #255 [hci0] 103.509426 L2CAP: Configure Request (0x04) ident 7 len 4 Destination CID: 65 Flags: 0x0000 < ACL Data TX: Handle 256 flags 0x00 dlen 12 #257 [hci0] 103.511870 L2CAP: Connection Request (0x02) ident 8 len 4 PSM: 1 (0x0001) Source CID: 66 > ACL Data RX: Handle 256 flags 0x02 dlen 14 #259 [hci0] 103.514121 L2CAP: Configure Response (0x05) ident 7 len 6 Source CID: 65 Flags: 0x0000 Result: Success (0x0000) Signed-off-by: Florian Dollinger <dollinger.florian@gmx.de> Co-developed-by: Florian Dollinger <dollinger.florian@gmx.de> Reviewed-by: Luiz Augusto Von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

pabeni · 2021-12-10T15:37:48Z

this is addressed via:

commit e8a5f5d
Author: Paolo Abeni pabeni@redhat.com
Date: Thu Dec 9 05:48:40 2021 +0000

mptcp: full disconnect implementation

When a console stack dump is initiated with CONFIG_GCOV_PROFILE_ALL enabled, show_trace_log_lvl() gets out of sync with the ORC unwinder, causing the stack trace to show all text addresses as unreliable: # echo l > /proc/sysrq-trigger [ 477.521031] sysrq: Show backtrace of all active CPUs [ 477.523813] NMI backtrace for cpu 0 [ 477.524492] CPU: 0 PID: 1021 Comm: bash Not tainted 6.0.0 #65 [ 477.525295] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 [ 477.526439] Call Trace: [ 477.526854] <TASK> [ 477.527216] ? dump_stack_lvl+0xc7/0x114 [ 477.527801] ? dump_stack+0x13/0x1f [ 477.528331] ? nmi_cpu_backtrace.cold+0xb5/0x10d [ 477.528998] ? lapic_can_unplug_cpu+0xa0/0xa0 [ 477.529641] ? nmi_trigger_cpumask_backtrace+0x16a/0x1f0 [ 477.530393] ? arch_trigger_cpumask_backtrace+0x1d/0x30 [ 477.531136] ? sysrq_handle_showallcpus+0x1b/0x30 [ 477.531818] ? __handle_sysrq.cold+0x4e/0x1ae [ 477.532451] ? write_sysrq_trigger+0x63/0x80 [ 477.533080] ? proc_reg_write+0x92/0x110 [ 477.533663] ? vfs_write+0x174/0x530 [ 477.534265] ? handle_mm_fault+0x16f/0x500 [ 477.534940] ? ksys_write+0x7b/0x170 [ 477.535543] ? __x64_sys_write+0x1d/0x30 [ 477.536191] ? do_syscall_64+0x6b/0x100 [ 477.536809] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 477.537609] </TASK> This happens when the compiled code for show_stack() has a single word on the stack, and doesn't use a tail call to show_stack_log_lvl(). (CONFIG_GCOV_PROFILE_ALL=y is the only known case of this.) Then the __unwind_start() skip logic hits an off-by-one bug and fails to unwind all the way to the intended starting frame. Fix it by reverting the following commit: f1d9a2a ("x86/unwind/orc: Don't skip the first frame for inactive tasks") The original justification for that commit no longer exists. That original issue was later fixed in a different way, with the following commit: f2ac57a ("x86/unwind/orc: Fix inactive tasks with stack pointer in %sp on GCC 10 compiled kernels") Fixes: f1d9a2a ("x86/unwind/orc: Don't skip the first frame for inactive tasks") Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com> [jpoimboe: rewrite commit log] Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra <peterz@infradead.org>

With latest llvm17, dynptr/test_dynptr_is_null subtest failed in my testing VM. The failure log looks like below: All error logs: tester_init:PASS:tester_log_buf 0 nsec process_subtest:PASS:obj_open_mem 0 nsec process_subtest:PASS:Can't alloc specs array 0 nsec verify_success:PASS:dynptr_success__open 0 nsec verify_success:PASS:bpf_object__find_program_by_name 0 nsec verify_success:PASS:dynptr_success__load 0 nsec verify_success:PASS:bpf_program__attach 0 nsec verify_success:FAIL:err unexpected err: actual 4 != expected 0 #65/9 dynptr/test_dynptr_is_null:FAIL The error happens for bpf prog test_dynptr_is_null in dynptr_success.c: if (bpf_dynptr_is_null(&ptr2)) { err = 4; goto exit; } The bpf_dynptr_is_null(&ptr) unexpectedly returned a non-zero value and the control went to the error path. Digging further, I found the root cause is due to function signature difference between kernel and user space. In kernel, we have ... __bpf_kfunc bool bpf_dynptr_is_null(struct bpf_dynptr_kern *ptr) ... while in bpf_kfuncs.h we have: extern int bpf_dynptr_is_null(const struct bpf_dynptr *ptr) __ksym; The kernel bpf_dynptr_is_null disasm code: ffffffff812f1a90 <bpf_dynptr_is_null>: ffffffff812f1a90: f3 0f 1e fa endbr64 ffffffff812f1a94: 0f 1f 44 00 00 nopl (%rax,%rax) ffffffff812f1a99: 53 pushq %rbx ffffffff812f1a9a: 48 89 fb movq %rdi, %rbx ffffffff812f1a9d: e8 ae 29 17 00 callq 0xffffffff81464450 <__asan_load8_noabort> ffffffff812f1aa2: 48 83 3b 00 cmpq $0x0, (%rbx) ffffffff812f1aa6: 0f 94 c0 sete %al ffffffff812f1aa9: 5b popq %rbx ffffffff812f1aaa: c3 retq Note that only 1-byte register %al is set and the other 7-bytes are not touched. In bpf program, the asm code for the above bpf_dynptr_is_null(&ptr2): 266: 85 10 00 00 ff ff ff ff call -0x1 267: b4 01 00 00 04 00 00 00 w1 = 0x4 268: 16 00 03 00 00 00 00 00 if w0 == 0x0 goto +0x3 <LBB9_8> Basically, 4-byte subregister is tested. This might cause error as the value other than the lowest byte might not be 0. This patch fixed the issue by using the identical func prototype across kernel and selftest user space. The fixed bpf asm code: 267: 85 10 00 00 ff ff ff ff call -0x1 268: 54 00 00 00 01 00 00 00 w0 &= 0x1 269: b4 01 00 00 04 00 00 00 w1 = 0x4 270: 16 00 03 00 00 00 00 00 if w0 == 0x0 goto +0x3 <LBB9_8> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20230517040404.4023912-1-yhs@fb.com

If there is a symbol link in the given patch, like the following one: $ cat 0001-selftests-bpf-Add-mptcp-pm_nl_ctl-link.patch ''' # diff --git a/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c \ # b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # new file mode 120000 # index 000000000000..5a08c255b278 # --- /dev/null # +++ b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # @@ -0,0 +1 @@ # +../net/mptcp/pm_nl_ctl.c # \ No newline at end of file ''' checkpatch.pl reports two inaccurate warnings: ''' WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c WARNING: adding a line without newline at end of file #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ''' And three checks if run it with strict option: ''' CHECK: spaces preferred around that '/' (ctx:VxV) #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ^ CHECK: spaces preferred around that '/' (ctx:VxV) #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ^ CHECK: spaces preferred around that '/' (ctx:VxV) #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ''' This patch fixes this by adding a new variable $symbol_link in checkpatch script, set it if the new file mode is 120000. Skip "missing or malformed SPDX-License-Identifier tag", "adding a line without newline at end of file" and "spaces preferred around that '/'" checks if this variable is set. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Message-Id: <8e5cdb8e4eb6d964ec3ffe961ab8e65b8788584f.1715815795.git.tanggeliang@kylinos.cn>

If there is a symbol link in the given patch, like the following one: $ cat 0001-selftests-bpf-Add-mptcp-pm_nl_ctl-link.patch ''' # diff --git a/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c \ # b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # new file mode 120000 # index 000000000000..5a08c255b278 # --- /dev/null # +++ b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # @@ -0,0 +1 @@ # +../net/mptcp/pm_nl_ctl.c # \ No newline at end of file ''' checkpatch.pl reports two inaccurate warnings: ''' WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 multipath-tcp#65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c WARNING: adding a line without newline at end of file multipath-tcp#65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ''' And three checks if run it with strict option: ''' CHECK: spaces preferred around that '/' (ctx:VxV) multipath-tcp#65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ^ CHECK: spaces preferred around that '/' (ctx:VxV) multipath-tcp#65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ^ CHECK: spaces preferred around that '/' (ctx:VxV) multipath-tcp#65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ''' This patch fixes this by adding a new variable $symbol_link in checkpatch script, set it if the new file mode is 120000. Skip "missing or malformed SPDX-License-Identifier tag", "adding a line without newline at end of file" and "spaces preferred around that '/'" checks if this variable is set. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>

If there is a symbol link in the given patch, like the following one: $ cat 0001-selftests-bpf-Add-mptcp-pm_nl_ctl-link.patch ''' # diff --git a/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c \ # b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # new file mode 120000 # index 000000000000..5a08c255b278 # --- /dev/null # +++ b/tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c # @@ -0,0 +1 @@ # +../net/mptcp/pm_nl_ctl.c # \ No newline at end of file ''' checkpatch.pl reports two inaccurate warnings: ''' WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c WARNING: adding a line without newline at end of file #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ''' And three checks if run it with strict option: ''' CHECK: spaces preferred around that '/' (ctx:VxV) #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ^ CHECK: spaces preferred around that '/' (ctx:VxV) #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ^ CHECK: spaces preferred around that '/' (ctx:VxV) #65: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c ''' This patch fixes this by adding a new variable $symbol_link in checkpatch script, set it if the new file mode is 120000. Skip "missing or malformed SPDX-License-Identifier tag", "adding a line without newline at end of file" and "spaces preferred around that '/'" checks if this variable is set. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Message-Id: <dc502b1b45cb27fda48d72d73e3267a32db023d8.1717722648.git.tanggeliang@kylinos.cn>

matttbe added the bug label Jul 23, 2020

matttbe changed the title ~~clearing properly the status in listen()~~ packetdrill/fixes: clearing properly the status in listen()/disconnect Jul 8, 2021

pabeni closed this as completed Dec 10, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

packetdrill/fixes: clearing properly the status in listen()/disconnect #65

packetdrill/fixes: clearing properly the status in listen()/disconnect #65

matttbe commented Jul 23, 2020 •

edited

Loading

pabeni commented Dec 10, 2021

packetdrill/fixes: clearing properly the status in listen()/disconnect #65

packetdrill/fixes: clearing properly the status in listen()/disconnect #65

Comments

matttbe commented Jul 23, 2020 • edited Loading

pabeni commented Dec 10, 2021

matttbe commented Jul 23, 2020 •

edited

Loading