After a few attempts of failed MPTCP, directly fallback to TCP for new connections #57

matttbe · 2020-07-16T14:49:18Z

The idea would be to imitate what is done in TFO, using a cache: if a destination IP is known not to support TFO (MPTCP here), fallback.

Note that now I think for TFO, they use a global counter because most issues (middleboxes) are in the operator network → most likely that either all connections are "failing" (e.g. with TFO: SYN with data are dropped / blackhole) in the network of the operator or all are OK even when trying different servers. So the "source" (client's network) is more an issue than the destination (server's network).

(Feature from the initial roadmap)

…le_activate In case if isi.nr_pages is 0, we are making sis->pages (which is unsigned int) a huge value in iomap_swapfile_activate() by assigning -1. This could cause a kernel crash in kernel v4.18 (with below signature). Or could lead to unknown issues on latest kernel if the fake big swap gets used. Fix this issue by returning -EINVAL in case of nr_pages is 0, since it is anyway a invalid swapfile. Looks like this issue will be hit when we have pagesize < blocksize type of configuration. I was able to hit the issue in case of a tiny swap file with below test script. https://raw.githubusercontent.com/riteshharjani/LinuxStudy/master/scripts/swap-issue.sh kernel crash analysis on v4.18 ============================== On v4.18 kernel, it causes a kernel panic, since sis->pages becomes a huge value and isi.nr_extents is 0. When 0 is returned it is considered as a swapfile over NFS and SWP_FILE is set (sis->flags |= SWP_FILE). Then when swapoff was getting called it was calling a_ops->swap_deactivate() if (sis->flags & SWP_FILE) is true. Since a_ops->swap_deactivate() is NULL in case of XFS, it causes below panic. Panic signature on v4.18 kernel: ======================================= root@qemu:/home/qemu# [ 8291.723351] XFS (loop2): Unmounting Filesystem [ 8292.123104] XFS (loop2): Mounting V5 Filesystem [ 8292.132451] XFS (loop2): Ending clean mount [ 8292.263362] Adding 4294967232k swap on /mnt1/test/swapfile. Priority:-2 extents:1 across:274877906880k [ 8292.277834] Unable to handle kernel paging request for instruction fetch [ 8292.278677] Faulting instruction address: 0x00000000 cpu 0x19: Vector: 400 (Instruction Access) at [c0000009dd5b7ad0] pc: 0000000000000000 lr: c0000000003eb9dc: destroy_swap_extents+0xfc/0x120 sp: c0000009dd5b7d50 msr: 8000000040009033 current = 0xc0000009b6710080 paca = 0xc00000003ffcb280 irqmask: 0x03 irq_happened: 0x01 pid = 5604, comm = swapoff Linux version 4.18.0 (riteshh@xxxxxxx) (gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04)) #57 SMP Wed Mar 3 01:33:04 CST 2021 enter ? for help [link register ] c0000000003eb9dc destroy_swap_extents+0xfc/0x120 [c0000009dd5b7d50] c0000000025a7058 proc_poll_event+0x0/0x4 (unreliable) [c0000009dd5b7da0] c0000000003f0498 sys_swapoff+0x3f8/0x910 [c0000009dd5b7e30] c00000000000bbe4 system_call+0x5c/0x70 Exception: c01 (System Call) at 00007ffff7d208d8 Signed-off-by: Ritesh Harjani <[email protected]> [djwong: rework the comment to provide more details] Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>

ksmbd-fixes

Fix the following false positive warning: ============================= WARNING: suspicious RCU usage 5.16.0-rc4+ #57 Not tainted ----------------------------- arch/x86/kvm/../../../virt/kvm/eventfd.c:484 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by fc_vcpu 0/330: #0: ffff8884835fc0b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x88/0x6f0 [kvm] #1: ffffc90004c0bb68 (&kvm->srcu){....}-{0:0}, at: vcpu_enter_guest+0x600/0x1860 [kvm] #2: ffffc90004c0c1d0 (&kvm->irq_srcu){....}-{0:0}, at: kvm_notify_acked_irq+0x36/0x180 [kvm] stack backtrace: CPU: 26 PID: 330 Comm: fc_vcpu 0 Not tainted 5.16.0-rc4+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x44/0x57 kvm_notify_acked_gsi+0x6b/0x70 [kvm] kvm_notify_acked_irq+0x8d/0x180 [kvm] kvm_ioapic_update_eoi+0x92/0x240 [kvm] kvm_apic_set_eoi_accelerated+0x2a/0xe0 [kvm] handle_apic_eoi_induced+0x3d/0x60 [kvm_intel] vmx_handle_exit+0x19c/0x6a0 [kvm_intel] vcpu_enter_guest+0x66e/0x1860 [kvm] kvm_arch_vcpu_ioctl_run+0x438/0x7f0 [kvm] kvm_vcpu_ioctl+0x38a/0x6f0 [kvm] __x64_sys_ioctl+0x89/0xc0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Since kvm_unregister_irq_ack_notifier() does synchronize_srcu(&kvm->irq_srcu), kvm->irq_ack_notifier_list is protected by kvm->irq_srcu. In fact, kvm->irq_srcu SRCU read lock is held in kvm_notify_acked_irq(), making it a false positive warning. So use hlist_for_each_entry_srcu() instead of hlist_for_each_entry_rcu(). Reviewed-by: Sean Christopherson <[email protected]> Signed-off-by: Hou Wenlong <[email protected]> Message-Id: <f98bac4f5052bad2c26df9ad50f7019e40434512.1643265976.git.houwenlong.hwl@antgroup.com> Signed-off-by: Paolo Bonzini <[email protected]>

This is arm64 version of commit fec56f5 ("bpf: Introduce BPF trampoline"). A bpf trampoline converts native calling convention to bpf calling convention and is used to implement various bpf features, such as fentry, fexit, fmod_ret and struct_ops. This patch does essentially the same thing that bpf trampoline does on x86. Tested on Raspberry Pi 4B and qemu: #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #237 xdp_bpf2bpf:OK Signed-off-by: Xu Kuohai <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jean-Philippe Brucker <[email protected]> Acked-by: Song Liu <[email protected]> Acked-by: KP Singh <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]

Since priv->rx_mapping[i] is maped in moxart_mac_open(), we should unmap it from moxart_mac_stop(). Fixes 2 warnings. 1. During error unwinding in moxart_mac_probe(): "goto init_fail;", then moxart_mac_free_memory() calls dma_unmap_single() with priv->rx_mapping[i] pointers zeroed. WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:963 check_unmap+0x704/0x980 DMA-API: moxart-ethernet 92000000.mac: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=1600 bytes] CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0+ #60 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0xbc/0x1f0 __warn from warn_slowpath_fmt+0x94/0xc8 warn_slowpath_fmt from check_unmap+0x704/0x980 check_unmap from debug_dma_unmap_page+0x8c/0x9c debug_dma_unmap_page from moxart_mac_free_memory+0x3c/0xa8 moxart_mac_free_memory from moxart_mac_probe+0x190/0x218 moxart_mac_probe from platform_probe+0x48/0x88 platform_probe from really_probe+0xc0/0x2e4 2. After commands: ip link set dev eth0 down ip link set dev eth0 up WARNING: CPU: 0 PID: 55 at kernel/dma/debug.c:570 add_dma_entry+0x204/0x2ec DMA-API: moxart-ethernet 92000000.mac: cacheline tracking EEXIST, overlapping mappings aren't supported CPU: 0 PID: 55 Comm: ip Not tainted 5.19.0+ #57 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0xbc/0x1f0 __warn from warn_slowpath_fmt+0x94/0xc8 warn_slowpath_fmt from add_dma_entry+0x204/0x2ec add_dma_entry from dma_map_page_attrs+0x110/0x328 dma_map_page_attrs from moxart_mac_open+0x134/0x320 moxart_mac_open from __dev_open+0x11c/0x1ec __dev_open from __dev_change_flags+0x194/0x22c __dev_change_flags from dev_change_flags+0x14/0x44 dev_change_flags from devinet_ioctl+0x6d4/0x93c devinet_ioctl from inet_ioctl+0x1ac/0x25c v1 -> v2: Extraneous change removed. Fixes: 6c821bd ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Sergei Antonov <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>

…) to avoid crash When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG: BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ... Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning. Use get_cpu() instead of smp_processor_id() to avoid this BUG. Suggested-by: Chen Yu <[email protected]> Signed-off-by: Srinivas Pandruvada <[email protected]> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>

BPF CI reported that selftest deny_namespace failed with s390x. test_unpriv_userns_create_no_bpf:PASS:no-bpf unpriv new user ns 0 nsec test_deny_namespace:PASS:skel load 0 nsec libbpf: prog 'test_userns_create': failed to attach: ERROR: strerror_r(-524)=22 libbpf: prog 'test_userns_create': failed to auto-attach: -524 test_deny_namespace:FAIL:attach unexpected error: -524 (errno 524) #57/1 deny_namespace/unpriv_userns_create_no_bpf:FAIL #57 deny_namespace:FAIL BPF program test_userns_create is a BPF LSM type program which is based on trampoline and s390x does not support s390x. Let add the test to x390x deny list to avoid this failure in BPF CI. Signed-off-by: Yonghong Song <[email protected]> Acked-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>

We need to probe for IOCP only once during boot stage, as we were probing for IOCP for all the stages this caused the below issue during module-init stage, [9.019104] Unable to handle kernel paging request at virtual address ffffffff8100d3a0 [9.027153] Oops [#1] [9.029421] Modules linked in: rcar_canfd renesas_usbhs i2c_riic can_dev spi_rspi i2c_core [9.037686] CPU: 0 PID: 90 Comm: udevd Not tainted 6.7.0-rc1+ #57 [9.043756] Hardware name: Renesas SMARC EVK based on r9a07g043f01 (DT) [9.050339] epc : riscv_noncoherent_supported+0x10/0x3e [9.055558] ra : andes_errata_patch_func+0x4a/0x52 [9.060418] epc : ffffffff8000d8c2 ra : ffffffff8000d95c sp : ffffffc8003abb00 [9.067607] gp : ffffffff814e25a0 tp : ffffffd80361e540 t0 : 0000000000000000 [9.074795] t1 : 000000000900031e t2 : 0000000000000001 s0 : ffffffc8003abb20 [9.081984] s1 : ffffffff015b57c7 a0 : 0000000000000000 a1 : 0000000000000001 [9.089172] a2 : 0000000000000000 a3 : 0000000000000000 a4 : ffffffff8100d8be [9.096360] a5 : 0000000000000001 a6 : 0000000000000001 a7 : 000000000900031e [9.103548] s2 : ffffffff015b57d7 s3 : 0000000000000001 s4 : 000000000000031e [9.110736] s5 : 8000000000008a45 s6 : 0000000000000500 s7 : 000000000000003f [9.117924] s8 : ffffffc8003abd48 s9 : ffffffff015b1140 s10: ffffffff8151a1b0 [9.125113] s11: ffffffff015b1000 t3 : 0000000000000001 t4 : fefefefefefefeff [9.132301] t5 : ffffffff015b57c7 t6 : ffffffd8b63a6000 [9.137587] status: 0000000200000120 badaddr: ffffffff8100d3a0 cause: 000000000000000f [9.145468] [<ffffffff8000d8c2>] riscv_noncoherent_supported+0x10/0x3e [9.151972] [<ffffffff800027e8>] _apply_alternatives+0x84/0x86 [9.157784] [<ffffffff800029be>] apply_module_alternatives+0x10/0x1a [9.164113] [<ffffffff80008fcc>] module_finalize+0x5e/0x7a [9.169583] [<ffffffff80085cd6>] load_module+0xfd8/0x179c [9.174965] [<ffffffff80086630>] init_module_from_file+0x76/0xaa [9.180948] [<ffffffff800867f6>] __riscv_sys_finit_module+0x176/0x2a8 [9.187365] [<ffffffff80889862>] do_trap_ecall_u+0xbe/0x130 [9.192922] [<ffffffff808920bc>] ret_from_exception+0x0/0x64 [9.198573] Code: 0009 b7e9 6797 014d a783 85a7 c799 4785 0717 0100 (0123) aef7 [9.205994] ---[ end trace 0000000000000000 ]--- This is because we called riscv_noncoherent_supported() for all the stages during IOCP probe. riscv_noncoherent_supported() function sets noncoherent_supported variable to true which has an annotation set to "__ro_after_init" due to which we were seeing the above splat. Fix this by probing for IOCP only once in boot stage by having a boolean variable "done" which will be set to true upon IOCP probe in errata_probe_iocp() and we bail out early if "done" is set to true. While at it make return type of errata_probe_iocp() to void as we were not checking the return value in andes_errata_patch_func(). Fixes: e021ae7 ("riscv: errata: Add Andes alternative ports") Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Yu Chien Peter Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>

During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: <TASK> __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 <TASK> Fix the issue by preventing the migration of the perf context to an invalid target. Fixes: 81dd4d4 ("dmaengine: idxd: Add IDXD performance monitor support") Reported-by: Terrence Xu <[email protected]> Tested-by: Terrence Xu <[email protected]> Signed-off-by: Fenghua Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>

If there is a symbol link in the given patch, checkpatch.pl reports two inaccurate warnings: $ 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 ''' $ ./scripts/checkpatch.pl 0001-selftests-bpf-Add-mptcp-pm_nl_ctl-link.patch ''' WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #57: 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 #57: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c total: 0 errors, 2 warnings, 16 lines checked ''' This patch fixes this by adding a new variable $symbol_link in checkpatch script, set it if the new file mode is 120000. Skip these two checks "missing SPDX-License-Identifier" and "adding a line without newline at end of file" if this variable is set. Signed-off-by: Geliang Tang <[email protected]> Message-Id: <1628d78e12809ff0f4dd0526f6addbbf00dae66b.1715503185.git.tanggeliang@kylinos.cn>

If there is a symbol link in the given patch, checkpatch.pl reports two inaccurate warnings: $ 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 ''' $ ./scripts/checkpatch.pl 0001-selftests-bpf-Add-mptcp-pm_nl_ctl-link.patch ''' WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 multipath-tcp#57: 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#57: FILE: tools/testing/selftests/bpf/mptcp_pm_nl_ctl.c:1: +../net/mptcp/pm_nl_ctl.c total: 0 errors, 2 warnings, 16 lines checked ''' This patch fixes this by adding a new variable $symbol_link in checkpatch script, set it if the new file mode is 120000. Skip these two checks "missing SPDX-License-Identifier" and "adding a line without newline at end of file" if this variable is set. Signed-off-by: Geliang Tang <[email protected]>

After 3 failed attempts, there is a fallback to TCP. If this "plain" TCP connection was a success, it likely means that MPTCP is blocked. The next connections now directly falls back to TCP. Link: multipath-tcp/mptcp_net-next#57 Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>

An MPTCP firewall blackhole can be detected if the following SYN retransmission after a fallback to "plain" TCP is accepted. In case of blackhole, a similar technique to the one used by TFO is used: MPTCP can be disabled for a certain period of time, 1h by default. This time period will grow exponentially when more blackhole issues get detected right after MPTCP is re-enabled and will reset to the initial value when the blackhole issue goes away. The blackhole period can be modified thanks to a new sysctl knob: blackhole_timeout. Two new MIB counters help understanding what's happening: - 'Blackhole', incremented when a blackhole has been detected. - 'MPCapableSYNTXDisabled', incremented when an MPTCP connection directly falls back to TCP during the blackhole period. Because the technique is similar to the one used by TFO, an important part of the new code is similar to what was can find in tcp_fastopen.c, with some adaptations to the MPTCP case. Closes: multipath-tcp/mptcp_net-next#57 Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>

An MPTCP firewall blackhole can be detected if the following SYN retransmission after a fallback to "plain" TCP is accepted. In case of blackhole, a similar technique to the one used by TFO is used: MPTCP can be disabled for a certain period of time, 1h by default. This time period will grow exponentially when more blackhole issues get detected right after MPTCP is re-enabled and will reset to the initial value when the blackhole issue goes away. The blackhole period can be modified thanks to a new sysctl knob: blackhole_timeout. Two new MIB counters help understanding what's happening: - 'Blackhole', incremented when a blackhole has been detected. - 'MPCapableSYNTXDisabled', incremented when an MPTCP connection directly falls back to TCP during the blackhole period. Because the technique is similar to the one used by TFO, an important part of the new code is similar to what was can find in tcp_fastopen.c, with some adaptations to the MPTCP case. Closes: #57 Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Message-Id: <[email protected]>

An MPTCP firewall blackhole can be detected if the following SYN retransmission after a fallback to "plain" TCP is accepted. In case of blackhole, a similar technique to the one used by TFO is used: MPTCP can be disabled for a certain period of time, 1h by default. This time period will grow exponentially when more blackhole issues get detected right after MPTCP is re-enabled and will reset to the initial value when the blackhole issue goes away. The blackhole period can be modified thanks to a new sysctl knob: blackhole_timeout. Two new MIB counters help understanding what's happening: - 'Blackhole', incremented when a blackhole has been detected. - 'MPCapableSYNTXDisabled', incremented when an MPTCP connection directly falls back to TCP during the blackhole period. Because the technique is similar to the one used by TFO, an important part of the new code is similar to what was can find in tcp_fastopen.c, with some adaptations to the MPTCP case. Closes: #57 Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>

An MPTCP firewall blackhole can be detected if the following SYN retransmission after a fallback to "plain" TCP is accepted. In case of blackhole, a similar technique to the one in place with TFO is now used: MPTCP can be disabled for a certain period of time, 1h by default. This time period will grow exponentially when more blackhole issues get detected right after MPTCP is re-enabled and will reset to the initial value when the blackhole issue goes away. The blackhole period can be modified thanks to a new sysctl knob: blackhole_timeout. Two new MIB counters help understanding what's happening: - 'Blackhole', incremented when a blackhole is detected. - 'MPCapableSYNTXDisabled', incremented when an MPTCP connection directly falls back to TCP during the blackhole period. Because the technique is inspired by the one used by TFO, an important part of the new code is similar to what can find in tcp_fastopen.c, with some adaptations to the MPTCP case. Closes: multipath-tcp/mptcp_net-next#57 Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>