1. 24 8月, 2021 5 次提交
  2. 14 8月, 2021 3 次提交
  3. 23 6月, 2021 1 次提交
  4. 27 3月, 2021 5 次提交
  5. 13 3月, 2021 5 次提交
  6. 13 2月, 2021 2 次提交
  7. 07 2月, 2021 1 次提交
  8. 03 2月, 2021 2 次提交
  9. 10 1月, 2021 1 次提交
  10. 10 12月, 2020 6 次提交
    • P
      mptcp: link MPC subflow into msk only after accept · 5b950ff4
      Paolo Abeni 提交于
      Christoph reported the following splat:
      
      WARNING: CPU: 0 PID: 4615 at net/ipv4/inet_connection_sock.c:1031 inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031
      Modules linked in:
      CPU: 0 PID: 4615 Comm: syz-executor.4 Not tainted 5.9.0 #37
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      RIP: 0010:inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031
      Code: 03 00 00 00 e8 79 b2 3d ff e9 ad f9 ff ff e8 1f 76 ba fe be 02 00 00 00 4c 89 f7 e8 62 b2 3d ff e9 14 f9 ff ff e8 08 76 ba fe <0f> 0b e9 97 f8 ff ff e8 fc 75 ba fe be 03 00 00 00 4c 89 f7 e8 3f
      RSP: 0018:ffffc900037f7948 EFLAGS: 00010293
      RAX: ffff88810a349c80 RBX: ffff888114ee1b00 RCX: ffffffff827b14cd
      RDX: 0000000000000000 RSI: ffffffff827b1c38 RDI: 0000000000000005
      RBP: ffff88810a2a8000 R08: ffff88810a349c80 R09: fffff520006fef1f
      R10: 0000000000000003 R11: fffff520006fef1e R12: ffff888114ee2d00
      R13: dffffc0000000000 R14: 0000000000000001 R15: ffff888114ee1d68
      FS:  00007f2ac1945700(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffd44798bc0 CR3: 0000000109810002 CR4: 0000000000170ef0
      Call Trace:
       __tcp_close+0xd86/0x1110 net/ipv4/tcp.c:2433
       __mptcp_close_ssk+0x256/0x430 net/mptcp/protocol.c:1761
       __mptcp_destroy_sock+0x49b/0x770 net/mptcp/protocol.c:2127
       mptcp_close+0x62d/0x910 net/mptcp/protocol.c:2184
       inet_release+0xe9/0x1f0 net/ipv4/af_inet.c:434
       __sock_release+0xd2/0x280 net/socket.c:596
       sock_close+0x15/0x20 net/socket.c:1277
       __fput+0x276/0x960 fs/file_table.c:281
       task_work_run+0x109/0x1d0 kernel/task_work.c:151
       get_signal+0xe8f/0x1d40 kernel/signal.c:2561
       arch_do_signal+0x88/0x1b60 arch/x86/kernel/signal.c:811
       exit_to_user_mode_loop kernel/entry/common.c:161 [inline]
       exit_to_user_mode_prepare+0x9b/0xf0 kernel/entry/common.c:191
       syscall_exit_to_user_mode+0x22/0x150 kernel/entry/common.c:266
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7f2ac1254469
      Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48
      RSP: 002b:00007f2ac1944dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffbf RBX: 000000000069bf00 RCX: 00007f2ac1254469
      RDX: 0000000000000000 RSI: 0000000000008982 RDI: 0000000000000003
      RBP: 000000000069bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 000000000069bf0c
      R13: 00007ffeb53f178f R14: 00000000004668b0 R15: 0000000000000003
      
      After commit 0397c6d8 ("mptcp: keep unaccepted MPC subflow into
      join list"), the msk's workqueue and/or PM can touch the MPC
      subflow - and acquire its socket lock - even if it's still unaccepted.
      
      If the above event races with the relevant listener socket close, we
      can end-up with the above splat.
      
      This change addresses the issue delaying the MPC socket insertion
      in conn_list at accept time - that is, partially reverting the
      blamed commit.
      
      We must additionally ensure that mptcp_pm_fully_established()
      happens after accept() time, or the PM will not be able to
      handle properly such event - conn_list could be empty otherwise.
      
      In the receive path, we check the subflow list node to ensure
      it is out of the listener queue. Be sure client subflows do
      not match transiently such condition moving them into the join
      list earlier at creation time.
      
      Since we now have multiple mptcp_pm_fully_established() call sites
      from different code-paths, said helper can now race with itself.
      Use an additional PM status bit to avoid multiple notifications.
      Reported-by: NChristoph Paasch <cpaasch@apple.com>
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/103
      Fixes: 0397c6d8 ("mptcp: keep unaccepted MPC subflow into join list"),
      Reviewed-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b950ff4
    • G
      mptcp: rename add_addr_signal and mptcp_add_addr_status · 13ad9f01
      Geliang Tang 提交于
      Since the RM_ADDR signal had been reused with add_addr_signal, it's not
      suitable to call it add_addr_signal or mptcp_add_addr_status. So this
      patch renamed add_addr_signal to addr_signal, and renamed
      mptcp_add_addr_status to mptcp_addr_signal_status.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13ad9f01
    • G
      mptcp: drop rm_addr_signal flag · 42842a42
      Geliang Tang 提交于
      This patch reused add_addr_signal for the RM_ADDR announcing signal, by
      defining a new ADD_ADDR status named MPTCP_RM_ADDR_SIGNAL. Then the flag
      rm_addr_signal in PM could be dropped.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42842a42
    • G
      mptcp: add port parameter for mptcp_pm_announce_addr · 0f5c9e3f
      Geliang Tang 提交于
      This patch added a new parameter 'port' for mptcp_pm_announce_addr. If
      this parameter is true, we set the MPTCP_ADD_ADDR_PORT bit of the
      add_addr_signal. That means the announced address is added with a port
      number.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f5c9e3f
    • G
      mptcp: send out dedicated packet for ADD_ADDR using port · fbe0f87a
      Geliang Tang 提交于
      The process is similar to that of the ADD_ADDR IPv6, this patch also sent
      out a pure ack for the ADD_ADDR using port.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbe0f87a
    • G
      mptcp: add the outgoing ADD_ADDR port support · 4a2777a8
      Geliang Tang 提交于
      This patch added a new add_addr_signal type named MPTCP_ADD_ADDR_PORT,
      to identify it is an address with port to be added.
      
      It also added a new parameter 'port' for both mptcp_add_addr_len and
      mptcp_pm_add_addr_signal.
      
      In mptcp_established_options_add_addr, we check whether the announced
      address is added with port. If it is, we put this port number to
      mptcp_out_options's port field.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a2777a8
  11. 21 11月, 2020 2 次提交
  12. 17 11月, 2020 1 次提交
  13. 04 10月, 2020 1 次提交
  14. 25 9月, 2020 5 次提交