1. 23 Jun, 2021 38 commits
  2. 22 Jun, 2021 2 commits
    • David S. Miller's avatar
      Merge branch 'mptcp-C-flag-and-fixes' · 38f75922
      David S. Miller authored
      Mat Martineau says:
      
      ====================
      mptcp: Connection-time 'C' flag and two fixes
      
      Here are six more patches from the MPTCP tree.
      
      Most of them add support for the 'C' flag in the MPTCP connection-time
      option headers. This flag affects how the initial address and port are
      treated by each peer. Normally one peer may send MP_JOIN requests to the
      remote address and port that were used when initiating the MPTCP
      connection. The 'C' bit indicates that MP_JOINs should only be sent to
      remote addresses that have been advertised with ADD_ADDR.
      
      The other two patches are unrelated improvements.
      
      Patches 1-4: Add the 'C' flag feature, a sysctl to optionally enable it,
      and a selftest.
      
      Patch 5: Adjust rp_filter settings in a selftest.
      
      Patch 6: Improve rbuf cleanup for MPTCP sockets.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38f75922
    • Paolo Abeni's avatar
      mptcp: refine mptcp_cleanup_rbuf · fde56eea
      Paolo Abeni authored
      The current cleanup rbuf tries a bit too hard to avoid acquiring
      the subflow socket lock. We may end-up delaying the needed ack,
      or skip acking a blocked subflow.
      
      Address the above extending the conditions used to trigger the cleanup
      to reflect more closely what TCP does and invoking tcp_cleanup_rbuf()
      on all the active subflows.
      
      Note that we can't replicate the exact tests implemented in
      tcp_cleanup_rbuf(), as MPTCP lacks some of the required info - e.g.
      ping-pong mode.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fde56eea