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

in-kernel PM: send >1 ADD_ADDR before the establishment of a new subflow #334

Open
matttbe opened this issue Jan 10, 2023 · 0 comments
Open
Labels
enhancement pm path-manager

Comments

@matttbe
Copy link
Member

matttbe commented Jan 10, 2023

Currently, the behaviour of the in-kernel PM is:

  • send a first ADD_ADDR (if any) once the connection switched to "fully established"
  • send other ADD_ADDR (if any) after each establishment of new subflows

The current behaviour is probably not solid enough, e.g. if the client cannot established a new subflow to the first announced address, the server will not announced other available addresses.
The PM should probably try to send more ADD_ADDR later, e.g. when an ADD_ADDR ECHO has been received.

Originally posted by @matttbe in #331 (comment)

@matttbe matttbe moved this to Needs triage in MPTCP Upstream: Future Feb 22, 2023
@geliangtang geliangtang added the pm path-manager label Aug 4, 2023
@matttbe matttbe changed the title PM: in-kernel: send >1 ADD_ADDR before the establishment of a new subflow in-kernel PM: send >1 ADD_ADDR before the establishment of a new subflow Jun 18, 2024
matttbe pushed a commit that referenced this issue Jul 10, 2024
Add a test case which replaces an active ingress qdisc while keeping the
miniq in-tact during the transition period to the new clsact qdisc.

  # ./vmtest.sh -- ./test_progs -t tc_link
  [...]
  ./test_progs -t tc_link
  [    3.412871] bpf_testmod: loading out-of-tree module taints kernel.
  [    3.413343] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel
  #332     tc_links_after:OK
  #333     tc_links_append:OK
  #334     tc_links_basic:OK
  #335     tc_links_before:OK
  #336     tc_links_chain_classic:OK
  #337     tc_links_chain_mixed:OK
  #338     tc_links_dev_chain0:OK
  #339     tc_links_dev_cleanup:OK
  #340     tc_links_dev_mixed:OK
  #341     tc_links_ingress:OK
  #342     tc_links_invalid:OK
  #343     tc_links_prepend:OK
  #344     tc_links_replace:OK
  #345     tc_links_revision:OK
  Summary: 14/0 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Martin KaFai Lau <martin.lau@kernel.org>
Link: https://lore.kernel.org/r/20240708133130.11609-2-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
matttbe pushed a commit that referenced this issue Oct 28, 2024
Currently, there is no terminator entry for exynosautov920_cmu_of_match,
hence facing below KASAN warning,

	BUG: KASAN: global-out-of-bounds in of_match_node+0x120/0x13c
	Read of size 1 at addr ffffffe31cc9e628 by task swapper/0/1

	CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0+ #334
	Hardware name: linux,dummy-virt (DT)
	Call trace:
	 dump_backtrace+0x94/0xec
	 show_stack+0x18/0x24
	 dump_stack_lvl+0x90/0xd0
	 print_report+0x1f4/0x5b4
	 kasan_report+0xc8/0x110
	 __asan_report_load1_noabort+0x20/0x2c
	 of_match_node+0x120/0x13c
	 of_match_device+0x70/0xb4
	 platform_match+0xa0/0x25c
	 __device_attach_driver+0x7c/0x2d4
	 bus_for_each_drv+0x100/0x188
	 __device_attach+0x174/0x364
	 device_initial_probe+0x14/0x20
	 bus_probe_device+0x128/0x158
	 device_add+0xb3c/0x10fc
	 of_device_add+0xdc/0x150
	 of_platform_device_create_pdata+0x120/0x20c
	 of_platform_bus_create+0x2bc/0x620
	 of_platform_populate+0x58/0x108
	 of_platform_default_populate_init+0x100/0x120
	 do_one_initcall+0x110/0x788
	 kernel_init_freeable+0x44c/0x61c
	 kernel_init+0x24/0x1e4
	 ret_from_fork+0x10/0x20

	The buggy address belongs to the variable:
	 exynosautov920_cmu_of_match+0xc8/0x2c80

Add a dummy terminator entry at the end to assist of_match_node() in
traversing up to the terminator entry without accessing an
out-of-boundary index.

Fixes: 485e13f ("clk: samsung: add top clock support for ExynosAuto v920 SoC")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20240927102104.3268790-1-ruanjinjie@huawei.com
[krzk: drop trailing comma]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement pm path-manager
Projects
Status: Needs triage
Development

No branches or pull requests

2 participants