1. 22 Jun, 2016 13 commits
    • David Howells's avatar
      rxrpc: Kill the client connection bundle concept · 999b69f8
      David Howells authored
      Kill off the concept of maintaining a bundle of connections to a particular
      target service to increase the number of call slots available for any
      beyond four for that service (there are four call slots per connection).
      
      This will make cleaning up the connection handling code easier and
      facilitate removal of the rxrpc_transport struct.  Bundling can be
      reintroduced later if necessary.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      999b69f8
    • David Howells's avatar
      rxrpc: Provide more refcount helper functions · 5627cc8b
      David Howells authored
      Provide refcount helper functions for connections so that the code doesn't
      touch local or connection usage counts directly.
      
      Also make it such that local and peer put functions can take a NULL
      pointer.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      5627cc8b
    • David Howells's avatar
      rxrpc: Make rxrpc_send_packet() take a connection not a transport · 985a5c82
      David Howells authored
      Make rxrpc_send_packet() take a connection not a transport as part of the
      phasing out of the rxrpc_transport struct.
      
      Whilst we're at it, rename the function to rxrpc_send_data_packet() to
      differentiate it from the other packet sending functions.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      985a5c82
    • David Howells's avatar
      rxrpc: Calls displayed in /proc may in future lack a connection · f4e7da8c
      David Howells authored
      Allocated rxrpc calls displayed in /proc/net/rxrpc_calls may in future be
      on the proc list before they're connected or after they've been
      disconnected - in which case they may not have a pointer to a connection
      struct that can be used to get data from there.
      
      Deal with this by using stuff from the call struct in preference where
      possible and printing "no_connection" rather than a peer address if no
      connection is assigned.
      
      This change also has the added bonus that the service ID is now taken from
      the call rather the connection which will allow per-call service upgrades
      to be shown - something required for AuriStor server compatibility.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      f4e7da8c
    • David Howells's avatar
      rxrpc: Validate the net address given to rxrpc_kernel_begin_call() · f4552c2d
      David Howells authored
      Validate the net address given to rxrpc_kernel_begin_call() before using
      it.
      
      Whilst this should be mostly unnecessary for in-kernel users, it does clear
      the tail of the address struct in case we want to hash or compare the whole
      thing.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      f4552c2d
    • David Howells's avatar
      rxrpc: Use IDR to allocate client conn IDs on a machine-wide basis · 4a3388c8
      David Howells authored
      Use the IDR facility to allocate client connection IDs on a machine-wide
      basis so that each client connection has a unique identifier.  When the
      connection ID space wraps, we advance the epoch by 1, thereby effectively
      having a 62-bit ID space.  The IDR facility is then used to look up client
      connections during incoming packet routing instead of using an rbtree
      rooted on the transport.
      
      This change allows for the removal of the transport in the future and also
      means that client connections can be looked up directly in the data-ready
      handler by connection ID.
      
      The ID management code is placed in a new file, conn-client.c, to which all
      the client connection-specific code will eventually move.
      
      Note that the IDR tree gets very expensive on memory if the connection IDs
      are widely scattered throughout the number space, so we shall need to
      retire connections that have, say, an ID more than four times the maximum
      number of client conns away from the current allocation point to try and
      keep the IDs concentrated.  We will also need to retire connections from an
      old epoch.
      
      Also note that, for the moment, a pointer to the transport has to be passed
      through into the ID allocation function so that we can take a BH lock to
      prevent a locking issue against in-BH lookup of client connections.  This
      will go away later when RCU is used for server connections also.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4a3388c8
    • David Howells's avatar
      rxrpc: rxrpc_connection_lock shouldn't be a BH lock, but conn_lock is · b3f57504
      David Howells authored
      rxrpc_connection_lock shouldn't be accessed as a BH-excluding lock.  It's
      only accessed in a few places and none of those are in BH-context.
      
      rxrpc_transport::conn_lock, however, *is* a BH-excluding lock and should be
      accessed so consistently.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b3f57504
    • David Howells's avatar
      rxrpc: Pass sk_buff * rather than rxrpc_host_header * to functions · 42886ffe
      David Howells authored
      Pass a pointer to struct sk_buff rather than struct rxrpc_host_header to
      functions so that they can in the future get at transport protocol parameters
      rather than just RxRPC parameters.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      42886ffe
    • David Howells's avatar
      rxrpc: Fix exclusive connection handling · cc8feb8e
      David Howells authored
      "Exclusive connections" are meant to be used for a single client call and
      then scrapped.  The idea is to limit the use of the negotiated security
      context.  The current code, however, isn't doing this: it is instead
      restricting the socket to a single virtual connection and doing all the
      calls over that.
      
      This is changed such that the socket no longer maintains a special virtual
      connection over which it will do all the calls, but rather gets a new one
      each time a new exclusive call is made.
      
      Further, using a socket option for this is a poor choice.  It should be
      done on sendmsg with a control message marker instead so that calls can be
      marked exclusive individually.  To that end, add RXRPC_EXCLUSIVE_CALL
      which, if passed to sendmsg() as a control message element, will cause the
      call to be done on an single-use connection.
      
      The socket option (RXRPC_EXCLUSIVE_CONNECTION) still exists and, if set,
      will override any lack of RXRPC_EXCLUSIVE_CALL being specified so that
      programs using the setsockopt() will appear to work the same.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc8feb8e
    • David Howells's avatar
      rxrpc: Replace conn->trans->{local,peer} with conn->params.{local,peer} · 85f32278
      David Howells authored
      Replace accesses of conn->trans->{local,peer} with
      conn->params.{local,peer} thus making it easier for a future commit to
      remove the rxrpc_transport struct.
      
      This also reduces the number of memory accesses involved.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      85f32278
    • David Howells's avatar
      rxrpc: Use structs to hold connection params and protocol info · 19ffa01c
      David Howells authored
      Define and use a structure to hold connection parameters.  This makes it
      easier to pass multiple connection parameters around.
      
      Define and use a structure to hold protocol information used to hash a
      connection for lookup on incoming packet.  Most of these fields will be
      disposed of eventually, including the duplicate local pointer.
      
      Whilst we're at it rename "proto" to "family" when referring to a protocol
      family.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      19ffa01c
    • Arnd Bergmann's avatar
      rxrpc: fix uninitialized variable use · 2f9f9f52
      Arnd Bergmann authored
      Hashing the peer key was introduced for AF_INET, but gcc
      warns about the rxrpc_peer_hash_key function returning uninitialized
      data for any other value of srx->transport.family:
      
      net/rxrpc/peer_object.c: In function 'rxrpc_peer_hash_key':
      net/rxrpc/peer_object.c:57:15: error: 'p' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      Assuming that nothing else can be set here, this changes the
      function to just return zero in case of an unknown address
      family.
      
      Fixes: be6e6707 ("rxrpc: Rework peer object handling to use hash table and RCU")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      2f9f9f52
    • Dan Carpenter's avatar
      rxrpc: checking for IS_ERR() instead of NULL · 0e4699e4
      Dan Carpenter authored
      rxrpc_lookup_peer_rcu() and rxrpc_lookup_peer() return NULL on error, never
      error pointers, so IS_ERR() can't be used.
      
      Fix three callers of those functions.
      
      Fixes: be6e6707 ('rxrpc: Rework peer object handling to use hash table and RCU')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      0e4699e4
  2. 21 Jun, 2016 27 commits