1. 17 Sep, 2016 13 commits
    • David Howells's avatar
      rxrpc: Don't transmit an ACK if there's no reason set · 27d0fc43
      David Howells authored
      Don't transmit an ACK if call->ackr_reason in unset.  There's the
      possibility of a race between recvmsg() sending an ACK and the background
      processing thread trying to send the same one.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      27d0fc43
    • David Howells's avatar
      rxrpc: Fix retransmission algorithm · dfa7d920
      David Howells authored
      Make the retransmission algorithm use for-loops instead of do-loops and
      move the counter increments into the for-statement increment slots.
      
      Though the do-loops are slighly more efficient since there will be at least
      one pass through the each loop, the counter increments are harder to get
      right as the continue-statements skip them.
      
      Without this, if there are any positive acks within the loop, the do-loop
      will cycle forever because the counter increment is never done.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      dfa7d920
    • David Howells's avatar
      rxrpc: Fix the parsing of soft-ACKs · d01dc4c3
      David Howells authored
      The soft-ACK parser doesn't increment the pointer into the soft-ACK list,
      resulting in the first ACK/NACK value being applied to all the relevant
      packets in the Tx queue.  This has the potential to miss retransmissions
      and cause excessive retransmissions.
      
      Fix this by incrementing the pointer.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d01dc4c3
    • David Howells's avatar
      rxrpc: Fix unexposed client conn release · 78883793
      David Howells authored
      If the last call on a client connection is release after the connection has
      had a bunch of calls allocated but before any DATA packets are sent (so
      that it's not yet marked RXRPC_CONN_EXPOSED), an assertion will happen in
      rxrpc_disconnect_client_call().
      
      	af_rxrpc: Assertion failed - 1(0x1) >= 2(0x2) is false
      	------------[ cut here ]------------
      	kernel BUG at ../net/rxrpc/conn_client.c:753!
      
      This is because it's expecting the conn to have been exposed and to have 2
      or more refs - but this isn't necessarily the case.
      
      Simply remove the assertion.  This allows the conn to be moved into the
      inactive state and deleted if it isn't resurrected before the final put is
      called.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      78883793
    • David Howells's avatar
      rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call() · 357f5ef6
      David Howells authored
      Call rxrpc_release_call() on getting an error in rxrpc_new_client_call()
      rather than trying to do the cleanup ourselves.  This isn't a problem,
      provided we set RXRPC_CALL_HAS_USERID only if we actually add the call to
      the calls tree as cleanup code fragments that would otherwise cause
      problems are conditional.
      
      Without this, we miss some of the cleanup.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      357f5ef6
    • David Howells's avatar
      rxrpc: Fix the putting of client connections · 66d58af7
      David Howells authored
      In rxrpc_put_one_client_conn(), if a connection has RXRPC_CONN_COUNTED set
      on it, then it's accounted for in rxrpc_nr_client_conns and may be on
      various lists - and this is cleaned up correctly.
      
      However, if the connection doesn't have RXRPC_CONN_COUNTED set on it, then
      the put routine returns rather than just skipping the extra bit of cleanup.
      
      Fix this by making the extra bit of clean up conditional instead and always
      killing off the connection.
      
      This manifests itself as connections with a zero usage count hanging around
      in /proc/net/rxrpc_conns because the connection allocated, but discarded,
      due to a race with another process that set up a parallel connection, which
      was then shared instead.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      66d58af7
    • David Howells's avatar
      rxrpc: Purge the to_be_accepted queue on socket release · 0360da6d
      David Howells authored
      Purge the queue of to_be_accepted calls on socket release.  Note that
      purging sock_calls doesn't release the ref owned by to_be_accepted.
      
      Probably the sock_calls list is redundant given a purges of the recvmsg_q,
      the to_be_accepted queue and the calls tree.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      0360da6d
    • David Howells's avatar
      rxrpc: Record calls that need to be accepted · e6f3afb3
      David Howells authored
      Record calls that need to be accepted using sk_acceptq_added() otherwise
      the backlog counter goes negative because sk_acceptq_removed() is called.
      This causes the preallocator to malfunction.
      
      Calls that are preaccepted by AFS within the kernel aren't affected by
      this.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      e6f3afb3
    • David Howells's avatar
      rxrpc: Fix handling of the last packet in rxrpc_recvmsg_data() · 816c9fce
      David Howells authored
      The code for determining the last packet in rxrpc_recvmsg_data() has been
      using the RXRPC_CALL_RX_LAST flag to determine if the rx_top pointer points
      to the last packet or not.  This isn't a good idea, however, as the input
      code may be running simultaneously on another CPU and that sets the flag
      *before* updating the top pointer.
      
      Fix this by the following means:
      
       (1) Restrict the use of RXRPC_CALL_RX_LAST to the input routines only.
           There's otherwise a synchronisation problem between detecting the flag
           and checking tx_top.  This could probably be dealt with by appropriate
           application of memory barriers, but there's a simpler way.
      
       (2) Set RXRPC_CALL_RX_LAST after setting rx_top.
      
       (3) Make rxrpc_rotate_rx_window() consult the flags header field of the
           DATA packet it's about to discard to see if that was the last packet.
           Use this as the basis for ending the Rx phase.  This shouldn't be a
           problem because the recvmsg side of things is guaranteed to see the
           packets in order.
      
       (4) Make rxrpc_recvmsg_data() return 1 to indicate the end of the data if:
      
           (a) the packet it has just processed is marked as RXRPC_LAST_PACKET
      
           (b) the call's Rx phase has been ended.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      816c9fce
    • David Howells's avatar
      rxrpc: Check the return value of rxrpc_locate_data() · 2e2ea51d
      David Howells authored
      Check the return value of rxrpc_locate_data() in rxrpc_recvmsg_data().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      2e2ea51d
    • David Howells's avatar
      rxrpc: Move the check of rx_pkt_offset from rxrpc_locate_data() to caller · 4b22457c
      David Howells authored
      Move the check of rx_pkt_offset from rxrpc_locate_data() to the caller,
      rxrpc_recvmsg_data(), so that it's more clear what's going on there.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4b22457c
    • David Howells's avatar
      rxrpc: Remove some whitespace. · fabf9201
      David Howells authored
      Remove a tab that's on a line that should otherwise be blank.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      fabf9201
    • David Howells's avatar
      rxrpc: Make IPv6 support conditional on CONFIG_IPV6 · d1912747
      David Howells authored
      Add CONFIG_AF_RXRPC_IPV6 and make the IPv6 support code conditional on it.
      This is then made conditional on CONFIG_IPV6.
      
      Without this, the following can be seen:
      
         net/built-in.o: In function `rxrpc_init_peer':
      >> peer_object.c:(.text+0x18c3c8): undefined reference to `ip6_route_output_flags'
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1912747
  2. 16 Sep, 2016 27 commits