Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mptcp_close() deletes MPTCP socket before disconnection completes #92

Closed
mjmartineau opened this issue Sep 19, 2020 · 3 comments
Closed
Assignees
Labels
Projects

Comments

@mjmartineau
Copy link
Member

The DATA_FIN changes in v5.9 added code to mptcp_close() to send DATA_FIN, but when the function is called with timeout == 0 it does not wait for the peer to complete the disconnection handshake. The MPTCP socket is immediately deleted in a sequence like this:

  1. Userspace calls close() on the MPTCP socket, leading to a call to mptcp_close() with timeout 0
  2. DATA_FIN is sent
  3. sk_stream_wait_close() does not wait because timeout is 0
  4. The connection is immediately moved to the TCP_CLOSED state, the subflows are shut down, and the MPTCP socket is released
  5. ACK packets are received from the peer with the DATA_ACK, and then DATA_FIN from the peer.

That final DATA_FIN from the peer is never acknowledged, so the peer keeps resending.

It looks like mptcp_close() needs to handle the non-closed states more like tcp_close() does, and let the protocol close handle final cleanup of the socket.

@mjmartineau mjmartineau added this to the v5.9 milestone Sep 19, 2020
@mjmartineau mjmartineau self-assigned this Sep 19, 2020
@matttbe matttbe added this to Needs triage in MPTCP Bugs via automation Oct 1, 2020
@mjmartineau mjmartineau removed this from the v5.9 milestone Oct 1, 2020
@pabeni
Copy link

pabeni commented Oct 6, 2020

should be addressed by the recent sendmsg refactor, right?

@mjmartineau
Copy link
Member Author

@pabeni, it should be addressed by the sendmsg refactor. I just tested on the export branch and still see the resend behavior, but I think that's because the net-next tree doesn't have all the net fixes yet. I will confirm and close after net-next catches up.

@mjmartineau
Copy link
Member Author

The DATA_FIN and DATA_ACKs are exchanged properly with mptcp_trunk v1 protocol - I tested with my own merge of net-next (before 16-Oct merge with Linus' tree) and -net.

MPTCP Bugs automation moved this from Needs triage to Closed Oct 17, 2020
jenkins-tessares pushed a commit that referenced this issue Apr 1, 2022
The per-channel data is available directly in the driver data struct. So
use it without making use of pwm_[gs]et_chip_data().

The relevant change introduced by this patch to lpc18xx_pwm_disable() at
the assembler level (for an arm lpc18xx_defconfig build) is:

	push    {r3, r4, r5, lr}
	mov     r4, r0
	mov     r0, r1
	mov     r5, r1
	bl      0 <pwm_get_chip_data>
	ldr     r3, [r0, #0]

changes to

	ldr     r3, [r1, #8]
	push    {r4, lr}
	add.w   r3, r0, r3, lsl #2
	ldr     r3, [r3, #92]   ; 0x5c

So this reduces stack usage, has an improved runtime behavior because of
better pipeline usage, doesn't branch to an external function and the
generated code is a bit smaller occupying less memory.

The codesize of lpc18xx_pwm_probe() is reduced by 32 bytes.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
jenkins-tessares pushed a commit that referenced this issue Dec 13, 2022
BPF CI fails for arm64 and s390x each with the following result:

  [...]
  All error logs:

  serial_test_kprobe_multi_bench_attach:PASS:get_syms 0 nsec
  serial_test_kprobe_multi_bench_attach:PASS:kprobe_multi_empty__open_and_load 0 nsec
  libbpf: prog 'test_kprobe_empty': failed to attach: Operation not supported
  serial_test_kprobe_multi_bench_attach:FAIL:bpf_program__attach_kprobe_multi_opts unexpected error: -95
  #92      kprobe_multi_bench_attach:FAIL
  [...]

Add the test to the deny list.

Fixes: 5b6c7e5 ("selftests/bpf: Add attach bench test")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
MPTCP Bugs
  
Closed
Development

No branches or pull requests

2 participants