Skip to content
  1. May 18, 2020
    • Florian Westphal's avatar
      mptcp: avoid blocking in tcp_sendpages · 72511aab
      Florian Westphal authored
      
      
      The transmit loop continues to xmit new data until an error is returned
      or all data was transmitted.
      
      For the blocking i/o case, this means that tcp_sendpages() may block on
      the subflow until more space becomes available, i.e. we end up sleeping
      with the mptcp socket lock held.
      
      Instead we should check if a different subflow is ready to be used.
      
      This restarts the subflow sk lookup when the tx operation succeeded
      and the tcp subflow can't accept more data or if tcp_sendpages
      indicates -EAGAIN on a blocking mptcp socket.
      
      In that case we also need to set the NOSPACE bit to make sure we get
      notified once memory becomes available.
      
      In case all subflows are busy, the existing logic will wait until a
      subflow is ready, releasing the mptcp socket lock while doing so.
      
      The mptcp worker already sets DONTWAIT, so no need to make changes there.
      
      v2:
       * set NOSPACE bit
       * add a comment to clarify that mptcp-sk sndbuf limits need to
         be checked as well.
      
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72511aab
    • Florian Westphal's avatar
      mptcp: break and restart in case mptcp sndbuf is full · fb529e62
      Florian Westphal authored
      
      
      Its not enough to check for available tcp send space.
      
      We also hold on to transmitted data for mptcp-level retransmits.
      Right now we will send more and more data if the peer can ack data
      at the tcp level fast enough, since that frees up tcp send buffer space.
      
      But we also need to check that data was acked and reclaimed at the mptcp
      level.
      
      Therefore add needed check in mptcp_sendmsg, flush tcp data and
      wait until more mptcp snd space becomes available if we are over the
      limit.  Before we wait for more data, also make sure we start the
      retransmit timer if we ran out of sndbuf space.
      
      Otherwise there is a very small chance that we wait forever:
      
       * receiver is waiting for data
       * sender is blocked because mptcp socket buffer is full
       * at tcp level, all data was acked
       * mptcp-level snd_una was not updated, because last ack
         that acknowledged the last data packet carried an older
         MPTCP-ack.
      
      Restarting the retransmit timer avoids this problem: if TCP
      subflow is idle, data is retransmitted from the RTX queue.
      
      New data will make the peer send a new, updated MPTCP-Ack.
      
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb529e62
    • Florian Westphal's avatar
      mptcp: move common nospace-pattern to a helper · a0e17064
      Florian Westphal authored
      
      
      Paolo noticed that ssk_check_wmem() has same pattern, so add/use
      common helper for both places.
      
      Suggested-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0e17064
    • David Ahern's avatar
      selftests: Drop 'pref medium' in route checks · eb682677
      David Ahern authored
      
      
      The 'pref medium' attribute was moved in iproute2 to be near the prefix
      which is where it applies versus after the last nexthop. The nexthop
      tests were updated to drop the string from route checking, but it crept
      in again with the compat tests.
      
      Fixes: 4dddb5be ("selftests: net: add new testcases for nexthop API compat mode sysctl")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb682677
  2. May 17, 2020
  3. May 16, 2020