Skip to content
This repository has been archived by the owner on Apr 18, 2024. It is now read-only.

I can't use multiple subflows properly #148

Closed
delinage opened this issue Oct 28, 2016 · 2 comments
Closed

I can't use multiple subflows properly #148

delinage opened this issue Oct 28, 2016 · 2 comments

Comments

@delinage
Copy link

delinage commented Oct 28, 2016 •
edited by matttbe
Loading

So… I have a problem/question. I’m going to try to give all the information needed, but if I miss something, please tell me.

I have 2 computers (one is “server” and the other one is “client”) with mptcp installed (also tools).
I have configured the routing tables (and added the scripts mptcp_up and mptcp_down, because I’m using ubuntu 16.04 LTS).

When I check “amiusing mptcp.de” I get a positive result, I get I’m using 2 subflows to connect on certain ports. (5900 and 8080 with scheduler default)

Everything seems normal but…

  1. If I use ifstat while surfing on amiusingmptcp.de I get I’m using a lot one interface but nearly nothing the other one (I thought this was normal, so I didn’t worry) (I’m using fullmesh in both computers).
  2. If I try to make a connection between the computers, using ipref, it seems I’m only using 1 subflow (I’ve checked netstat and wireshark) because the second ones don’t connect.
    So, I don’t know where the mistake is, and I would appreciate the help.

Images:
-Client: (it looks like it tries to connect the other subflow but it can't)

client1

client2

-Server:

server

PS:
Client:
10.102.81.138 (it's the one used to connect with server)
192.168.10.158 (it's the other one /30)
Server:
10.102.81.130 (it's the one I use to connect)
192.168.0.122

Thanks in advance.
@delinage delinage reopened this Oct 28, 2016
@cpaasch
Copy link
Member

cpaasch commented Oct 28, 2016

@delinage, you closed, reopened, closed the issue. So, I guess you managed to fix it?

@delinage
Copy link
Author

Yes, sorry. I'm trying something different, I'll reopen if it doesn't work.
Sorry for the inconvenience.

dreibh pushed a commit to dreibh/mptcp that referenced this issue Oct 12, 2017
@gregkh
sata_via: Enable hotplug only on VT6421
c533c11 
[ Upstream commit 3cf8645 ]

Commit 57e5568 ("sata_via: Implement hotplug for VT6421") adds
hotplug IRQ handler for VT6421 but enables hotplug on all chips. This
is a bug because it causes "irq xx: nobody cared" error on VT6420 when
hot-(un)plugging a drive:

[  381.839948] irq 20: nobody cared (try booting with the "irqpoll" option)
[  381.840014] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc5+ multipath-tcp#148
[  381.840066] Hardware name:          P4VM800/P4VM800, BIOS P1.60 05/29/2006
[  381.840117] Call Trace:
[  381.840167]  <IRQ>
[  381.840225]  ? dump_stack+0x44/0x58
[  381.840278]  ? __report_bad_irq+0x14/0x97
[  381.840327]  ? handle_edge_irq+0xa5/0xa5
[  381.840376]  ? note_interrupt+0x155/0x1cf
[  381.840426]  ? handle_edge_irq+0xa5/0xa5
[  381.840474]  ? handle_irq_event_percpu+0x32/0x38
[  381.840524]  ? handle_irq_event+0x1f/0x38
[  381.840573]  ? handle_fasteoi_irq+0x69/0xb8
[  381.840625]  ? handle_irq+0x4f/0x5d
[  381.840672]  </IRQ>
[  381.840726]  ? do_IRQ+0x2e/0x8b
[  381.840782]  ? common_interrupt+0x2c/0x34
[  381.840836]  ? mwait_idle+0x60/0x82
[  381.840892]  ? arch_cpu_idle+0x6/0x7
[  381.840949]  ? do_idle+0x96/0x18e
[  381.841002]  ? cpu_startup_entry+0x16/0x1a
[  381.841057]  ? start_kernel+0x319/0x31c
[  381.841111]  ? startup_32_smp+0x166/0x168
[  381.841165] handlers:
[  381.841219] [<c12a7263>] ata_bmdma_interrupt
[  381.841274] Disabling IRQ multipath-tcp#20

Seems that VT6420 can do hotplug too (there's no documentation) but the
comments say that SCR register access (required for detecting hotplug
events) can cause problems on these chips.

For now, just keep hotplug disabled on anything other than VT6421.

Signed-off-by: Ondrej Zary <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
matttbe pushed a commit that referenced this issue Mar 8, 2023
@SunHao-0 @gregkh
bpf: Skip task with pid=1 in send_signal_common()
4923160 
[ Upstream commit a3d81bc1eaef48e34dd0b9b48eefed9e02a06451 ]

The following kernel panic can be triggered when a task with pid=1 attaches
a prog that attempts to send killing signal to itself, also see [1] for more
details:

  Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
  CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
  Call Trace:
  <TASK>
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
  panic+0x2c4/0x60f kernel/panic.c:275
  do_exit.cold+0x63/0xe4 kernel/exit.c:789
  do_group_exit+0xd4/0x2a0 kernel/exit.c:950
  get_signal+0x2460/0x2600 kernel/signal.c:2858
  arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
  exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
  exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
  __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
  syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
  do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

So skip task with pid=1 in bpf_send_signal_common() to avoid the panic.

  [1] https://lore.kernel.org/bpf/[email protected]

Signed-off-by: Hao Sun <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@cpaasch @delinage