1. 27 4月, 2022 1 次提交
  2. 23 4月, 2022 2 次提交
  3. 11 4月, 2022 1 次提交
  4. 09 3月, 2022 1 次提交
    • P
      mptcp: strict local address ID selection · 4cf86ae8
      Paolo Abeni 提交于
      The address ID selection for MPJ subflows created in response
      to incoming ADD_ADDR option is currently unreliable: it happens
      at MPJ socket creation time, when the local address could be
      unknown.
      
      Additionally, if the no local endpoint is available for the local
      address, a new dummy endpoint is created, confusing the user-land.
      
      This change refactor the code to move the address ID selection inside
      the rebuild_header() helper, when the local address eventually
      selected by the route lookup is finally known. If the address used
      is not mapped by any endpoint - and thus can't be advertised/removed
      pick the id 0 instead of allocate a new endpoint.
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      4cf86ae8
  5. 17 2月, 2022 4 次提交
  6. 22 1月, 2022 1 次提交
  7. 08 1月, 2022 1 次提交
  8. 07 1月, 2022 7 次提交
  9. 18 12月, 2021 1 次提交
  10. 08 12月, 2021 3 次提交
  11. 20 11月, 2021 1 次提交
  12. 28 10月, 2021 1 次提交
    • P
      mptcp: allocate fwd memory separately on the rx and tx path · 6511882c
      Paolo Abeni 提交于
      All the mptcp receive path is protected by the msk socket
      spinlock. As consequences, the tx path has to play a few tricks to
      allocate the forward memory without acquiring the spinlock multiple
      times, making the overall TX path quite complex.
      
      This patch tries to clean-up a bit the tx path, using completely
      separated fwd memory allocation, for the rx and the tx path.
      
      The forward memory allocated in the rx path is now accounted in
      msk->rmem_fwd_alloc and is (still) protected by the msk socket spinlock.
      
      To cope with the above we provide a few MPTCP-specific variants for
      the helpers to charge, uncharge, reclaim and free the forward memory
      in the receive path.
      
      msk->sk_forward_alloc now accounts only the forward memory for the tx
      path, we can use the plain core sock helper to manipulate it and drop
      quite a bit of complexity.
      
      On memory pressure, both rx and tx fwd memories are reclaimed.
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6511882c
  13. 16 10月, 2021 1 次提交
  14. 25 9月, 2021 1 次提交
    • F
      mptcp: remove tx_pending_data · 9e65b6a5
      Florian Westphal 提交于
      The update on recovery is not correct.
      
      msk->tx_pending_data += msk->snd_nxt - rtx_head->data_seq;
      
      will update tx_pending_data multiple times when a subflow is declared
      stale while earlier recovery is still in progress.
      This means that tx_pending_data will still be positive even after
      all data as has been transmitted.
      
      Rather than fix it, remove this field: there are no consumers.
      The outstanding data byte count can be computed either via
      
       "msk->write_seq - rtx_head->data_seq" or
       "msk->write_seq - msk->snd_una".
      
      The latter is more recent/accurate estimate as rtx_head adjustment
      is deferred until mptcp lock can be acquired.
      Acked-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e65b6a5
  15. 24 9月, 2021 1 次提交
  16. 03 9月, 2021 1 次提交
    • M
      mptcp: Only send extra TCP acks in eligible socket states · 340fa666
      Mat Martineau 提交于
      Recent changes exposed a bug where specifically-timed requests to the
      path manager netlink API could trigger a divide-by-zero in
      __tcp_select_window(), as syzkaller does:
      
      divide error: 0000 [#1] SMP KASAN NOPTI
      CPU: 0 PID: 9667 Comm: syz-executor.0 Not tainted 5.14.0-rc6+ #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
      RIP: 0010:__tcp_select_window+0x509/0xa60 net/ipv4/tcp_output.c:3016
      Code: 44 89 ff e8 c9 29 e9 fd 45 39 e7 0f 8d 20 ff ff ff e8 db 28 e9 fd 44 89 e3 e9 13 ff ff ff e8 ce 28 e9 fd 44 89 e0 44 89 e3 99 <f7> 7c 24 04 29 d3 e9 fc fe ff ff e8 b7 28 e9 fd 44 89 f1 48 89 ea
      RSP: 0018:ffff888031ccf020 EFLAGS: 00010216
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000040000
      RDX: 0000000000000000 RSI: ffff88811532c080 RDI: 0000000000000002
      RBP: 0000000000000000 R08: ffffffff835807c2 R09: 0000000000000000
      R10: 0000000000000004 R11: ffffed1020b92441 R12: 0000000000000000
      R13: 1ffff11006399e08 R14: 0000000000000000 R15: 0000000000000000
      FS:  00007fa4c8344700(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b2f424000 CR3: 000000003e4e2003 CR4: 0000000000770ef0
      PKRU: 55555554
      Call Trace:
       tcp_select_window net/ipv4/tcp_output.c:264 [inline]
       __tcp_transmit_skb+0xc00/0x37a0 net/ipv4/tcp_output.c:1351
       __tcp_send_ack.part.0+0x3ec/0x760 net/ipv4/tcp_output.c:3972
       __tcp_send_ack net/ipv4/tcp_output.c:3978 [inline]
       tcp_send_ack+0x7d/0xa0 net/ipv4/tcp_output.c:3978
       mptcp_pm_nl_addr_send_ack+0x1ab/0x380 net/mptcp/pm_netlink.c:654
       mptcp_pm_remove_addr+0x161/0x200 net/mptcp/pm.c:58
       mptcp_nl_remove_id_zero_address+0x197/0x460 net/mptcp/pm_netlink.c:1328
       mptcp_nl_cmd_del_addr+0x98b/0xd40 net/mptcp/pm_netlink.c:1359
       genl_family_rcv_msg_doit.isra.0+0x225/0x340 net/netlink/genetlink.c:731
       genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
       genl_rcv_msg+0x341/0x5b0 net/netlink/genetlink.c:792
       netlink_rcv_skb+0x148/0x430 net/netlink/af_netlink.c:2504
       genl_rcv+0x24/0x40 net/netlink/genetlink.c:803
       netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
       netlink_unicast+0x537/0x750 net/netlink/af_netlink.c:1340
       netlink_sendmsg+0x846/0xd80 net/netlink/af_netlink.c:1929
       sock_sendmsg_nosec net/socket.c:704 [inline]
       sock_sendmsg+0x14e/0x190 net/socket.c:724
       ____sys_sendmsg+0x709/0x870 net/socket.c:2403
       ___sys_sendmsg+0xff/0x170 net/socket.c:2457
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      mptcp_pm_nl_addr_send_ack() was attempting to send a TCP ACK on the
      first subflow in the MPTCP socket's connection list without validating
      that the subflow was in a suitable connection state. To address this,
      always validate subflow state when sending extra ACKs on subflows
      for address advertisement or subflow priority change.
      
      Fixes: 84dfe367 ("mptcp: send out dedicated ADD_ADDR packet")
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/229Co-developed-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Acked-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      340fa666
  17. 01 9月, 2021 1 次提交
  18. 27 8月, 2021 2 次提交
  19. 25 8月, 2021 4 次提交
  20. 24 8月, 2021 4 次提交
  21. 18 8月, 2021 1 次提交