1. 16 Oct, 2018 1 commit
  2. 02 Aug, 2018 1 commit
  3. 01 Aug, 2018 2 commits
  4. 16 May, 2018 1 commit
  5. 30 Mar, 2018 1 commit
    • David Howells's avatar
      rxrpc: Fix checker warnings and errors · 88f2a825
      David Howells authored
      Fix various issues detected by checker.
       (*) rxrpc_discard_prealloc() should be using rcu_assign_pointer to set
       (*) rxrpc_service_connection_reaper() should be passing NULL rather than 0 to
           trace_rxrpc_conn() as the where argument.
       (*) rxrpc_disconnect_client_call() should get its net pointer via the
           call->conn rather than call->sock to avoid a warning about accessing
           an RCU pointer without protection.
       (*) Proc seq start/stop functions need annotation as they pass locks
           between the functions.
      False positives:
       (*) Checker doesn't correctly handle of seq-retry lock context balance in
       (*) Checker thinks execution may proceed past the BUG() in
       (*) Variable length array warnings from SKCIPHER_REQUEST_ON_STACK() in
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  6. 16 Jan, 2018 1 commit
    • Alexey Dobriyan's avatar
      net: delete /proc THIS_MODULE references · 96890d62
      Alexey Dobriyan authored
      /proc has been ignoring struct file_operations::owner field for 10 years.
      Specifically, it started with commit 786d7e16
      ("Fix rmmod/read/write races in /proc entries"). Notice the chunk where
      inode->i_fop is initialized with proxy struct file_operations for
      regular files:
      	-               if (de->proc_fops)
      	-                       inode->i_fop = de->proc_fops;
      	+               if (de->proc_fops) {
      	+                       if (S_ISREG(inode->i_mode))
      	+                               inode->i_fop = &proc_reg_file_ops;
      	+                       else
      	+                               inode->i_fop = de->proc_fops;
      	+               }
      VFS stopped pinning module at this point.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  7. 05 Jun, 2017 1 commit
    • David Howells's avatar
      rxrpc: Separate the connection's protocol service ID from the lookup ID · 68d6d1ae
      David Howells authored
      Keep the rxrpc_connection struct's idea of the service ID that is exposed
      in the protocol separate from the service ID that's used as a lookup key.
      This allows the protocol service ID on a client connection to get upgraded
      without making the connection unfindable for other client calls that also
      would like to use the upgraded connection.
      The connection's actual service ID is then returned through recvmsg() by
      way of msg_name.
      Whilst we're at it, we get rid of the last_service_id field from each
      channel.  The service ID is per-connection, not per-call and an entire
      connection is upgraded in one go.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  8. 25 May, 2017 1 commit
    • David Howells's avatar
      rxrpc: Support network namespacing · 2baec2c3
      David Howells authored
      Support network namespacing in AF_RXRPC with the following changes:
       (1) All the local endpoint, peer and call lists, locks, counters, etc. are
           moved into the per-namespace record.
       (2) All the connection tracking is moved into the per-namespace record
           with the exception of the client connection ID tree, which is kept
           global so that connection IDs are kept unique per-machine.
       (3) Each namespace gets its own epoch.  This allows each network namespace
           to pretend to be a separate client machine.
       (4) The /proc/net/rxrpc_xxx files are now called /proc/net/rxrpc/xxx and
           the contents reflect the namespace.
      fs/afs/ should be okay with this patch as it explicitly requires the current
      net namespace to be init_net to permit a mount to proceed at the moment.  It
      will, however, need updating so that cells, IP addresses and DNS records are
      per-namespace also.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  9. 05 Jan, 2017 1 commit
  10. 13 Sep, 2016 1 commit
    • David Howells's avatar
      rxrpc: Add IPv6 support · 75b54cb5
      David Howells authored
      Add IPv6 support to AF_RXRPC.  With this, AF_RXRPC sockets can be created:
      	service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET6);
      instead of:
      	service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET);
      The AFS filesystem doesn't support IPv6 at the moment, though, since that
      requires upgrades to some of the RPC calls.
      Note that a good portion of this patch is replacing "%pI4:%u" in print
      statements with "%pISpc" which is able to handle both protocols and print
      the port.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  11. 08 Sep, 2016 1 commit
    • David Howells's avatar
      rxrpc: Preallocate peers, conns and calls for incoming service requests · 00e90712
      David Howells authored
      Make it possible for the data_ready handler called from the UDP transport
      socket to completely instantiate an rxrpc_call structure and make it
      immediately live by preallocating all the memory it might need.  The idea
      is to cut out the background thread usage as much as possible.
      [Note that the preallocated structs are not actually used in this patch -
       that will be done in a future patch.]
      If insufficient resources are available in the preallocation buffers, it
      will be possible to discard the DATA packet in the data_ready handler or
      schedule a BUSY packet without the need to schedule an attempt at
      allocation in a background thread.
      To this end:
       (1) Preallocate rxrpc_peer, rxrpc_connection and rxrpc_call structs to a
           maximum number each of the listen backlog size.  The backlog size is
           limited to a maxmimum of 32.  Only this many of each can be in the
           preallocation buffer.
       (2) For userspace sockets, the preallocation is charged initially by
           listen() and will be recharged by accepting or rejecting pending
           new incoming calls.
       (3) For kernel services {,re,dis}charging of the preallocation buffers is
           handled manually.  Two notifier callbacks have to be provided before
           kernel_listen() is invoked:
           (a) An indication that a new call has been instantiated.  This can be
           	 used to trigger background recharging.
           (b) An indication that a call is being discarded.  This is used when
           	 the socket is being released.
           A function, rxrpc_kernel_charge_accept() is called by the kernel
           service to preallocate a single call.  It should be passed the user ID
           to be used for that call and a callback to associate the rxrpc call
           with the kernel service's side of the ID.
       (4) Discard the preallocation when the socket is closed.
       (5) Temporarily bump the refcount on the call allocated in
           rxrpc_incoming_call() so that rxrpc_release_call() can ditch the
           preallocation ref on service calls unconditionally.  This will no
           longer be necessary once the preallocation is used.
      Note that this does not yet control the number of active service calls on a
      client - that will come in a later patch.
      A future development would be to provide a setsockopt() call that allows a
      userspace server to manually charge the preallocation buffer.  This would
      allow user call IDs to be provided in advance and the awkward manual accept
      stage to be bypassed.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  12. 07 Sep, 2016 1 commit
    • David Howells's avatar
      rxrpc: Calls shouldn't hold socket refs · 8d94aa38
      David Howells authored
      rxrpc calls shouldn't hold refs on the sock struct.  This was done so that
      the socket wouldn't go away whilst the call was in progress, such that the
      call could reach the socket's queues.
      However, we can mark the socket as requiring an RCU release and rely on the
      RCU read lock.
      To make this work, we do:
       (1) rxrpc_release_call() removes the call's call user ID.  This is now
           only called from socket operations and not from the call processor:
      	rxrpc_accept_call() / rxrpc_kernel_accept_call()
      	rxrpc_reject_call() / rxrpc_kernel_reject_call()
           Though it is also called in the cleanup path of
           rxrpc_accept_incoming_call() before we assign a user ID.
       (2) Pass the socket pointer into rxrpc_release_call() rather than getting
           it from the call so that we can get rid of uninitialised calls.
       (3) Fix call processor queueing to pass a ref to the work queue and to
           release that ref at the end of the processor function (or to pass it
           back to the work queue if we have to requeue).
       (4) Skip out of the call processor function asap if the call is complete
           and don't requeue it if the call is complete.
       (5) Clean up the call immediately that the refcount reaches 0 rather than
           trying to defer it.  Actual deallocation is deferred to RCU, however.
       (6) Don't hold socket refs for allocated calls.
       (7) Use the RCU read lock when queueing a message on a socket and treat
           the call's socket pointer according to RCU rules and check it for
           We also need to use the RCU read lock when viewing a call through
       (8) Transmit the final ACK/ABORT to a client call in rxrpc_release_call()
           if this hasn't been done yet so that we can then disconnect the call.
           Once the call is disconnected, it won't have any access to the
           connection struct and the UDP socket for the call work processor to be
           able to send the ACK.  Terminal retransmission will be handled by the
           connection processor.
       (9) Release all calls immediately on the closing of a socket rather than
           trying to defer this.  Incomplete calls will be aborted.
      The call refcount model is much simplified.  Refs are held on the call by:
       (1) A socket's user ID tree.
       (2) A socket's incoming call secureq and acceptq.
       (3) A kernel service that has a call in progress.
       (4) A queued call work processor.  We have to take care to put any call
           that we failed to queue.
       (5) sk_buffs on a socket's receive queue.  A future patch will get rid of
      Whilst we're at it, we can do:
       (1) Get rid of the RXRPC_CALL_EV_RELEASE event.  Release is now done
           entirely from the socket routines and never from the call's processor.
       (2) Get rid of the RXRPC_CALL_DEAD state.  Calls now end in the
           RXRPC_CALL_COMPLETE state.
       (3) Get rid of the rxrpc_call::destroyer work item.  Calls are now torn
           down when their refcount reaches 0 and then handed over to RCU for
           final cleanup.
       (4) Get rid of the rxrpc_call::deadspan timer.  Calls are cleaned up
           immediately they're finished with and don't hang around.
           Post-completion retransmission is handled by the connection processor
           once the call is disconnected.
       (5) Get rid of the dead call expiry setting as there's no longer a timer
           to set.
       (6) rxrpc_destroy_all_calls() can just check that the call list is empty.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  13. 30 Aug, 2016 1 commit
  14. 24 Aug, 2016 2 commits
    • David Howells's avatar
      rxrpc: Dup the main conn list for the proc interface · 4d028b2c
      David Howells authored
      The main connection list is used for two independent purposes: primarily it
      is used to find connections to reap and secondarily it is used to list
      connections in procfs.
      Split the procfs list out from the reap list.  This allows us to stop using
      the reap list for client connections when they acquire a separate
      management strategy from service collections.
      The client connections will not be on a management single list, and sometimes
      won't be on a management list at all.  This doesn't leave them floating,
      however, as they will also be on an rb-tree rooted on the socket so that the
      socket can find them to dispatch calls.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      rxrpc: Make /proc/net/rxrpc_calls safer · df5d8bf7
      David Howells authored
      Make /proc/net/rxrpc_calls safer by stashing a copy of the peer pointer in
      the rxrpc_call struct and checking in the show routine that the peer
      pointer, the socket pointer and the local pointer obtained from the socket
      pointer aren't NULL before we use them.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  15. 23 Aug, 2016 2 commits
    • David Howells's avatar
      rxrpc: Calculate serial skew on packet reception · 563ea7d5
      David Howells authored
      Calculate the serial number skew in the data_ready handler when a packet
      has been received and a connection looked up.  The skew is cached in the
      sk_buff's priority field.
      The connection highest received serial number is updated at this time also.
      This can be done without locks or atomic instructions because, at this
      point, the code is serialised by the socket.
      This generates more accurate skew data because if the packet is offloaded
      to a work queue before this is determined, more packets may come in,
      bumping the highest serial number and thereby increasing the apparent skew.
      This also removes some unnecessary atomic ops.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      rxrpc: Tidy up the rxrpc_call struct a bit · dabe5a79
      David Howells authored
      Do a little tidying of the rxrpc_call struct:
       (1) in_clientflag is no longer compared against the value that's in the
           packet, so keeping it in this form isn't necessary.  Use a flag in
           flags instead and provide a pair of wrapper functions.
       (2) We don't read the epoch value, so that can go.
       (3) Move what remains of the data that were used for hashing up in the
           struct to be with the channel number.
       (4) Get rid of the local pointer.  We can get at this via the socket
           struct and we only use this in the procfs viewer.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  16. 06 Jul, 2016 2 commits
    • David Howells's avatar
      rxrpc: Call channels should have separate call number spaces · a1399f8b
      David Howells authored
      Each channel on a connection has a separate, independent number space from
      which to allocate callNumber values.  It is entirely possible, for example,
      to have a connection with four active calls, each with call number 1.
      Note that the callNumber values for any particular channel don't have to
      start at 1, but they are supposed to increment monotonically for that
      channel from a client's perspective and may not be reused once the call
      number is transmitted (until the epoch cycles all the way back round).
      Currently, however, call numbers are allocated on a per-connection basis
      and, further, are held in an rb-tree.  The rb-tree is redundant as the four
      channel pointers in the rxrpc_connection struct are entirely capable of
      pointing to all the calls currently in progress on a connection.
      To this end, make the following changes:
       (1) Handle call number allocation independently per channel.
       (2) Get rid of the conn->calls rb-tree.  This is overkill as a connection
           may have a maximum of four calls in progress at any one time.  Use the
           pointers in the channels[] array instead, indexed by the channel
           number from the packet.
       (3) For each channel, save the result of the last call that was in
           progress on that channel in conn->channels[] so that the final ACK or
           ABORT packet can be replayed if necessary.  Any call earlier than that
           is just ignored.  If we've seen the next call number in a packet, the
           last one is most definitely defunct.
       (4) When generating a RESPONSE packet for a connection, the call number
           counter for each channel must be included in it.
       (5) When parsing a RESPONSE packet for a connection, the call number
           counters contained therein should be used to set the minimum expected
           call numbers on each channel.
      To do in future commits:
       (1) Replay terminal packets based on the last call stored in
       (2) Connections should be retired before the callNumber space on any
           channel runs out.
       (3) A server is expected to disregard or reject any new incoming call that
           has a call number less than the current call number counter.  The call
           number counter for that channel must be advanced to the new call
           Note that the server cannot just require that the next call that it
           sees on a channel be exactly the call number counter + 1 because then
           there's a scenario that could cause a problem: The client transmits a
           packet to initiate a connection, the network goes out, the server
           sends an ACK (which gets lost), the client sends an ABORT (which also
           gets lost); the network then reconnects, the client then reuses the
           call number for the next call (it doesn't know the server already saw
           the call number), but the server thinks it already has the first
           packet of this call (it doesn't know that the client doesn't know that
           it saw the call number the first time).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      rxrpc: Turn connection #defines into enums and put outside struct def · bba304db
      David Howells authored
      Turn the connection event and state #define lists into enums and move
      outside of the struct definition.
      Whilst we're at it, change _SERVER to _SERVICE in those identifiers and add
      EV_ into the event name to distinguish them from flags and states.
      Also add a symbol indicating the number of states and use that in the state
      text array.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  17. 22 Jun, 2016 3 commits
    • 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>
    • 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>
    • 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
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  18. 13 Jun, 2016 1 commit
    • David Howells's avatar
      rxrpc: Rename files matching ar-*.c to git rid of the "ar-" prefix · 8c3e34a4
      David Howells authored
      Rename files matching net/rxrpc/ar-*.c to get rid of the "ar-" prefix.
      This will aid splitting those files by making easier to come up with new
      Note that the not all files are simply renamed from ar-X.c to X.c.  The
      following exceptions are made:
       (*) ar-call.c -> call_object.c
           ar-ack.c -> call_event.c
           call_object.c is going to contain the core of the call object
           handling.  Call event handling is all going to be in call_event.c.
       (*) ar-accept.c -> call_accept.c
           Incoming call handling is going to be here.
       (*) ar-connection.c -> conn_object.c
           ar-connevent.c -> conn_event.c
           The former file is going to have the basic connection object handling,
           but there will likely be some differentiation between client
           connections and service connections in additional files later.  The
           latter file will have all the connection-level event handling.
       (*) ar-local.c -> local_object.c
           This will have the local endpoint object handling code.  The local
           endpoint event handling code will later be split out into
       (*) ar-peer.c -> peer_object.c
           This will have the peer endpoint object handling code.  Peer event
           handling code will be placed in peer_event.c (for the moment, there is
       (*) ar-error.c -> peer_event.c
           This will become the peer event handling code, though for the moment
           it's actually driven from the local endpoint's perspective.
      Note that I haven't renamed ar-transport.c to transport_object.c as the
      intention is to delete it when the rxrpc_transport struct is excised.
      The only file that actually has its contents changed is net/rxrpc/Makefile.
      net/rxrpc/ar-internal.h will need its section marker comments updating, but
      I'll do that in a separate patch to make it easier for git to follow the
      history across the rename.  I may also want to rename ar-internal.h at some
      point - but that would mean updating all the #includes and I'd rather do
      that in a separate step.
      Signed-off-by: David Howells <dhowells@redhat.com.
  19. 11 Apr, 2016 1 commit
    • David Howells's avatar
      rxrpc: Differentiate local and remote abort codes in structs · dc44b3a0
      David Howells authored
      In the rxrpc_connection and rxrpc_call structs, there's one field to hold
      the abort code, no matter whether that value was generated locally to be
      sent or was received from the peer via an abort packet.
      Split the abort code fields in two for cleanliness sake and add an error
      field to hold the Linux error number to the rxrpc_call struct too
      (sometimes this is generated in a context where we can't return it to
      userspace directly).
      Furthermore, add a skb mark to indicate a packet that caused a local abort
      to be generated so that recvmsg() can pick up the correct abort code.  A
      future addition will need to be to indicate to userspace the difference
      between aborts via a control message.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  20. 04 Mar, 2016 1 commit
    • David Howells's avatar
      rxrpc: Keep the skb private record of the Rx header in host byte order · 0d12f8a4
      David Howells authored
      Currently, a copy of the Rx packet header is copied into the the sk_buff
      private data so that we can advance the pointer into the buffer,
      potentially discarding the original.  At the moment, this copy is held in
      network byte order, but this means we're doing a lot of unnecessary
      The reasons it was done this way are that we need the values in network
      byte order occasionally and we can use the copy, slightly modified, as part
      of an iov array when sending an ack or an abort packet.
      However, it seems more reasonable on review that it would be better kept in
      host byte order and that we make up a new header when we want to send
      another packet.
      To this end, rename the original header struct to rxrpc_wire_header (with
      BE fields) and institute a variant called rxrpc_host_header that has host
      order fields.  Change the struct in the sk_buff private data into an
      rxrpc_host_header and translate the values when filling it in.
      This further allows us to keep values kept in various structures in host
      byte order rather than network byte order and allows removal of some fields
      that are byteswapped duplicates.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  21. 31 Oct, 2008 1 commit
  22. 29 Feb, 2008 1 commit
  23. 01 Feb, 2008 1 commit
  24. 11 Jul, 2007 2 commits
  25. 22 May, 2007 1 commit
  26. 26 Apr, 2007 1 commit