1. 31 3月, 2018 2 次提交
    • D
      rxrpc: Fix apparent leak of rxrpc_local objects · 31f5f9a1
      David Howells 提交于
      rxrpc_local objects cannot be disposed of until all the connections that
      point to them have been RCU'd as a connection object holds refcount on the
      local endpoint it is communicating through.  Currently, this can cause an
      assertion failure to occur when a network namespace is destroyed as there's
      no check that the RCU destructors for the connections have been run before
      we start trying to destroy local endpoints.
      
      The kernel reports:
      
      	rxrpc: AF_RXRPC: Leaked local 0000000036a41bc1 {5}
      	------------[ cut here ]------------
      	kernel BUG at ../net/rxrpc/local_object.c:439!
      
      Fix this by keeping a count of the live connections and waiting for it to
      go to zero at the end of rxrpc_destroy_all_connections().
      
      Fixes: dee46364 ("rxrpc: Add RCU destruction for connections and calls")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      31f5f9a1
    • D
      rxrpc: Fix checker warnings and errors · 88f2a825
      David Howells 提交于
      Fix various issues detected by checker.
      
      Errors:
      
       (*) rxrpc_discard_prealloc() should be using rcu_assign_pointer to set
           call->socket.
      
      Warnings:
      
       (*) 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
           rxrpc_find_service_conn_rcu().
      
       (*) Checker thinks execution may proceed past the BUG() in
           rxrpc_publish_service_conn().
      
       (*) Variable length array warnings from SKCIPHER_REQUEST_ON_STACK() in
           rxkad.c.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      88f2a825
  2. 08 2月, 2018 1 次提交
    • D
      rxrpc: Fix received abort handling · 17e9e23b
      David Howells 提交于
      AF_RXRPC is incorrectly sending back to the server any abort it receives
      for a client connection.  This is due to the final-ACK offload to the
      connection event processor patch.  The abort code is copied into the
      last-call information on the connection channel and then the event
      processor is set.
      
      Instead, the following should be done:
      
       (1) In the case of a final-ACK for a successful call, the ACK should be
           scheduled as before.
      
       (2) In the case of a locally generated ABORT, the ABORT details should be
           cached for sending in response to further packets related to that
           call and no further action scheduled at call disconnect time.
      
       (3) In the case of an ACK received from the peer, the call should be
           considered dead, no ABORT should be transmitted at this time.  In
           response to further non-ABORT packets from the peer relating to this
           call, an RX_USER_ABORT ABORT should be transmitted.
      
       (4) In the case of a call killed due to network error, an RX_USER_ABORT
           ABORT should be cached for transmission in response to further
           packets, but no ABORT should be sent at this time.
      
      Fixes: 3136ef49 ("rxrpc: Delay terminal ACK transmission on a client call")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17e9e23b
  3. 29 11月, 2017 1 次提交
  4. 24 11月, 2017 3 次提交
    • D
      rxrpc: Fix conn expiry timers · 3d18cbb7
      David Howells 提交于
      Fix the rxrpc connection expiry timers so that connections for closed
      AF_RXRPC sockets get deleted in a more timely fashion, freeing up the
      transport UDP port much more quickly.
      
       (1) Replace the delayed work items with work items plus timers so that
           timer_reduce() can be used to shorten them and so that the timer
           doesn't requeue the work item if the net namespace is dead.
      
       (2) Don't use queue_delayed_work() as that won't alter the timeout if the
           timer is already running.
      
       (3) Don't rearm the timers if the network namespace is dead.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      3d18cbb7
    • D
      rxrpc: Fix service endpoint expiry · f859ab61
      David Howells 提交于
      RxRPC service endpoints expire like they're supposed to by the following
      means:
      
       (1) Mark dead rxrpc_net structs (with ->live) rather than twiddling the
           global service conn timeout, otherwise the first rxrpc_net struct to
           die will cause connections on all others to expire immediately from
           then on.
      
       (2) Mark local service endpoints for which the socket has been closed
           (->service_closed) so that the expiration timeout can be much
           shortened for service and client connections going through that
           endpoint.
      
       (3) rxrpc_put_service_conn() needs to schedule the reaper when the usage
           count reaches 1, not 0, as idle conns have a 1 count.
      
       (4) The accumulator for the earliest time we might want to schedule for
           should be initialised to jiffies + MAX_JIFFY_OFFSET, not ULONG_MAX as
           the comparison functions use signed arithmetic.
      
       (5) Simplify the expiration handling, adding the expiration value to the
           idle timestamp each time rather than keeping track of the time in the
           past before which the idle timestamp must go to be expired.  This is
           much easier to read.
      
       (6) Ignore the timeouts if the net namespace is dead.
      
       (7) Restart the service reaper work item rather the client reaper.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f859ab61
    • D
      rxrpc: Delay terminal ACK transmission on a client call · 3136ef49
      David Howells 提交于
      Delay terminal ACK transmission on a client call by deferring it to the
      connection processor.  This allows it to be skipped if we can send the next
      call instead, the first DATA packet of which will implicitly ack this call.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      3136ef49
  5. 29 8月, 2017 1 次提交
    • D
      rxrpc: Fix IPv6 support · 7b674e39
      David Howells 提交于
      Fix IPv6 support in AF_RXRPC in the following ways:
      
       (1) When extracting the address from a received IPv4 packet, if the local
           transport socket is open for IPv6 then fill out the sockaddr_rxrpc
           struct for an IPv4-mapped-to-IPv6 AF_INET6 transport address instead
           of an AF_INET one.
      
       (2) When sending CHALLENGE or RESPONSE packets, the transport length needs
           to be set from the sockaddr_rxrpc::transport_len field rather than
           sizeof() on the IPv4 transport address.
      
       (3) When processing an IPv4 ICMP packet received by an IPv6 socket, set up
           the address correctly before searching for the affected peer.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      7b674e39
  6. 15 6月, 2017 1 次提交
    • D
      rxrpc: Cache the congestion window setting · f7aec129
      David Howells 提交于
      Cache the congestion window setting that was determined during a call's
      transmission phase when it finishes so that it can be used by the next call
      to the same peer, thereby shortcutting the slow-start algorithm.
      
      The value is stored in the rxrpc_peer struct and is accessed without
      locking.  Each call takes the value that happens to be there when it starts
      and just overwrites the value when it finishes.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7aec129
  7. 05 6月, 2017 1 次提交
    • D
      rxrpc: Separate the connection's protocol service ID from the lookup ID · 68d6d1ae
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      68d6d1ae
  8. 26 5月, 2017 1 次提交
    • D
      rxrpc: Support network namespacing · 2baec2c3
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2baec2c3
  9. 05 1月, 2017 1 次提交
    • D
      rxrpc: Add some more tracing · b1d9f7fd
      David Howells 提交于
      Add the following extra tracing information:
      
       (1) Modify the rxrpc_transmit tracepoint to record the Tx window size as
           this is varied by the slow-start algorithm.
      
       (2) Modify the rxrpc_rx_ack tracepoint to record more information from
           received ACK packets.
      
       (3) Add an rxrpc_rx_data tracepoint to record the information in DATA
           packets.
      
       (4) Add an rxrpc_disconnect_call tracepoint to record call disconnection,
           including the reason the call was disconnected.
      
       (5) Add an rxrpc_improper_term tracepoint to record implicit termination
           of a call by a client either by starting a new call on a particular
           connection channel without first transmitting the final ACK for the
           previous call.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      b1d9f7fd
  10. 22 9月, 2016 1 次提交
  11. 17 9月, 2016 2 次提交
  12. 14 9月, 2016 1 次提交
    • D
      rxrpc: Add IPv6 support · 75b54cb5
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      75b54cb5
  13. 08 9月, 2016 2 次提交
    • D
      rxrpc: Rewrite the data and ack handling code · 248f219c
      David Howells 提交于
      Rewrite the data and ack handling code such that:
      
       (1) Parsing of received ACK and ABORT packets and the distribution and the
           filing of DATA packets happens entirely within the data_ready context
           called from the UDP socket.  This allows us to process and discard ACK
           and ABORT packets much more quickly (they're no longer stashed on a
           queue for a background thread to process).
      
       (2) We avoid calling skb_clone(), pskb_pull() and pskb_trim().  We instead
           keep track of the offset and length of the content of each packet in
           the sk_buff metadata.  This means we don't do any allocation in the
           receive path.
      
       (3) Jumbo DATA packet parsing is now done in data_ready context.  Rather
           than cloning the packet once for each subpacket and pulling/trimming
           it, we file the packet multiple times with an annotation for each
           indicating which subpacket is there.  From that we can directly
           calculate the offset and length.
      
       (4) A call's receive queue can be accessed without taking locks (memory
           barriers do have to be used, though).
      
       (5) Incoming calls are set up from preallocated resources and immediately
           made live.  They can than have packets queued upon them and ACKs
           generated.  If insufficient resources exist, DATA packet #1 is given a
           BUSY reply and other DATA packets are discarded).
      
       (6) sk_buffs no longer take a ref on their parent call.
      
      To make this work, the following changes are made:
      
       (1) Each call's receive buffer is now a circular buffer of sk_buff
           pointers (rxtx_buffer) rather than a number of sk_buff_heads spread
           between the call and the socket.  This permits each sk_buff to be in
           the buffer multiple times.  The receive buffer is reused for the
           transmit buffer.
      
       (2) A circular buffer of annotations (rxtx_annotations) is kept parallel
           to the data buffer.  Transmission phase annotations indicate whether a
           buffered packet has been ACK'd or not and whether it needs
           retransmission.
      
           Receive phase annotations indicate whether a slot holds a whole packet
           or a jumbo subpacket and, if the latter, which subpacket.  They also
           note whether the packet has been decrypted in place.
      
       (3) DATA packet window tracking is much simplified.  Each phase has just
           two numbers representing the window (rx_hard_ack/rx_top and
           tx_hard_ack/tx_top).
      
           The hard_ack number is the sequence number before base of the window,
           representing the last packet the other side says it has consumed.
           hard_ack starts from 0 and the first packet is sequence number 1.
      
           The top number is the sequence number of the highest-numbered packet
           residing in the buffer.  Packets between hard_ack+1 and top are
           soft-ACK'd to indicate they've been received, but not yet consumed.
      
           Four macros, before(), before_eq(), after() and after_eq() are added
           to compare sequence numbers within the window.  This allows for the
           top of the window to wrap when the hard-ack sequence number gets close
           to the limit.
      
           Two flags, RXRPC_CALL_RX_LAST and RXRPC_CALL_TX_LAST, are added also
           to indicate when rx_top and tx_top point at the packets with the
           LAST_PACKET bit set, indicating the end of the phase.
      
       (4) Calls are queued on the socket 'receive queue' rather than packets.
           This means that we don't need have to invent dummy packets to queue to
           indicate abnormal/terminal states and we don't have to keep metadata
           packets (such as ABORTs) around
      
       (5) The offset and length of a (sub)packet's content are now passed to
           the verify_packet security op.  This is currently expected to decrypt
           the packet in place and validate it.
      
           However, there's now nowhere to store the revised offset and length of
           the actual data within the decrypted blob (there may be a header and
           padding to skip) because an sk_buff may represent multiple packets, so
           a locate_data security op is added to retrieve these details from the
           sk_buff content when needed.
      
       (6) recvmsg() now has to handle jumbo subpackets, where each subpacket is
           individually secured and needs to be individually decrypted.  The code
           to do this is broken out into rxrpc_recvmsg_data() and shared with the
           kernel API.  It now iterates over the call's receive buffer rather
           than walking the socket receive queue.
      
      Additional changes:
      
       (1) The timers are condensed to a single timer that is set for the soonest
           of three timeouts (delayed ACK generation, DATA retransmission and
           call lifespan).
      
       (2) Transmission of ACK and ABORT packets is effected immediately from
           process-context socket ops/kernel API calls that cause them instead of
           them being punted off to a background work item.  The data_ready
           handler still has to defer to the background, though.
      
       (3) A shutdown op is added to the AF_RXRPC socket so that the AFS
           filesystem can shut down the socket and flush its own work items
           before closing the socket to deal with any in-progress service calls.
      
      Future additional changes that will need to be considered:
      
       (1) Make sure that a call doesn't hog the front of the queue by receiving
           data from the network as fast as userspace is consuming it to the
           exclusion of other calls.
      
       (2) Transmit delayed ACKs from within recvmsg() when we've consumed
           sufficiently more packets to avoid the background work item needing to
           run.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      248f219c
    • D
      rxrpc: Preallocate peers, conns and calls for incoming service requests · 00e90712
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      00e90712
  14. 30 8月, 2016 1 次提交
  15. 24 8月, 2016 2 次提交
    • D
      rxrpc: Improve management and caching of client connection objects · 45025bce
      David Howells 提交于
      Improve the management and caching of client rxrpc connection objects.
      From this point, client connections will be managed separately from service
      connections because AF_RXRPC controls the creation and re-use of client
      connections but doesn't have that luxury with service connections.
      
      Further, there will be limits on the numbers of client connections that may
      be live on a machine.  No direct restriction will be placed on the number
      of client calls, excepting that each client connection can support a
      maximum of four concurrent calls.
      
      Note that, for a number of reasons, we don't want to simply discard a
      client connection as soon as the last call is apparently finished:
      
       (1) Security is negotiated per-connection and the context is then shared
           between all calls on that connection.  The context can be negotiated
           again if the connection lapses, but that involves holding up calls
           whilst at least two packets are exchanged and various crypto bits are
           performed - so we'd ideally like to cache it for a little while at
           least.
      
       (2) If a packet goes astray, we will need to retransmit a final ACK or
           ABORT packet.  To make this work, we need to keep around the
           connection details for a little while.
      
       (3) The locally held structures represent some amount of setup time, to be
           weighed against their occupation of memory when idle.
      
      
      To this end, the client connection cache is managed by a state machine on
      each connection.  There are five states:
      
       (1) INACTIVE - The connection is not held in any list and may not have
           been exposed to the world.  If it has been previously exposed, it was
           discarded from the idle list after expiring.
      
       (2) WAITING - The connection is waiting for the number of client conns to
           drop below the maximum capacity.  Calls may be in progress upon it
           from when it was active and got culled.
      
           The connection is on the rxrpc_waiting_client_conns list which is kept
           in to-be-granted order.  Culled conns with waiters go to the back of
           the queue just like new conns.
      
       (3) ACTIVE - The connection has at least one call in progress upon it, it
           may freely grant available channels to new calls and calls may be
           waiting on it for channels to become available.
      
           The connection is on the rxrpc_active_client_conns list which is kept
           in activation order for culling purposes.
      
       (4) CULLED - The connection got summarily culled to try and free up
           capacity.  Calls currently in progress on the connection are allowed
           to continue, but new calls will have to wait.  There can be no waiters
           in this state - the conn would have to go to the WAITING state
           instead.
      
       (5) IDLE - The connection has no calls in progress upon it and must have
           been exposed to the world (ie. the EXPOSED flag must be set).  When it
           expires, the EXPOSED flag is cleared and the connection transitions to
           the INACTIVE state.
      
           The connection is on the rxrpc_idle_client_conns list which is kept in
           order of how soon they'll expire.
      
      A connection in the ACTIVE or CULLED state must have at least one active
      call upon it; if in the WAITING state it may have active calls upon it;
      other states may not have active calls.
      
      As long as a connection remains active and doesn't get culled, it may
      continue to process calls - even if there are connections on the wait
      queue.  This simplifies things a bit and reduces the amount of checking we
      need do.
      
      
      There are a couple flags of relevance to the cache:
      
       (1) EXPOSED - The connection ID got exposed to the world.  If this flag is
           set, an extra ref is added to the connection preventing it from being
           reaped when it has no calls outstanding.  This flag is cleared and the
           ref dropped when a conn is discarded from the idle list.
      
       (2) DONT_REUSE - The connection should be discarded as soon as possible and
           should not be reused.
      
      
      This commit also provides a number of new settings:
      
       (*) /proc/net/rxrpc/max_client_conns
      
           The maximum number of live client connections.  Above this number, new
           connections get added to the wait list and must wait for an active
           conn to be culled.  Culled connections can be reused, but they will go
           to the back of the wait list and have to wait.
      
       (*) /proc/net/rxrpc/reap_client_conns
      
           If the number of desired connections exceeds the maximum above, the
           active connection list will be culled until there are only this many
           left in it.
      
       (*) /proc/net/rxrpc/idle_conn_expiry
      
           The normal expiry time for a client connection, provided there are
           fewer than reap_client_conns of them around.
      
       (*) /proc/net/rxrpc/idle_conn_fast_expiry
      
           The expedited expiry time, used when there are more than
           reap_client_conns of them around.
      
      
      Note that I combined the Tx wait queue with the channel grant wait queue to
      save space as only one of these should be in use at once.
      
      Note also that, for the moment, the service connection cache still uses the
      old connection management code.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      45025bce
    • D
      rxrpc: Dup the main conn list for the proc interface · 4d028b2c
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      4d028b2c
  16. 23 8月, 2016 3 次提交
    • D
      rxrpc: Perform terminal call ACK/ABORT retransmission from conn processor · 18bfeba5
      David Howells 提交于
      Perform terminal call ACK/ABORT retransmission in the connection processor
      rather than in the call processor.  With this change, once last_call is
      set, no more incoming packets will be routed to the corresponding call or
      any earlier calls on that channel (call IDs must only increase on a channel
      on a connection).
      
      Further, if a packet's callNumber is before the last_call ID or a packet is
      aimed at successfully completed service call then that packet is discarded
      and ignored.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      18bfeba5
    • D
      rxrpc: Set connection expiry on idle, not put · f51b4480
      David Howells 提交于
      Set the connection expiry time when a connection becomes idle rather than
      doing this in rxrpc_put_connection().  This makes the put path more
      efficient (it is likely to be called occasionally whilst a connection has
      outstanding calls because active workqueue items needs to be given a ref).
      
      The time is also preset in the connection allocator in case the connection
      never gets used.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f51b4480
    • D
      rxrpc: Drop channel number field from rxrpc_call struct · 01a90a45
      David Howells 提交于
      Drop the channel number (channel) field from the rxrpc_call struct to
      reduce the size of the call struct.  The field is redundant: if the call is
      attached to a connection, the channel can be obtained from there by AND'ing
      with RXRPC_CHANNELMASK.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      01a90a45
  17. 06 7月, 2016 12 次提交
    • D
      rxrpc: Use RCU to access a peer's service connection tree · 8496af50
      David Howells 提交于
      Move to using RCU access to a peer's service connection tree when routing
      an incoming packet.  This is done using a seqlock to trigger retrying of
      the tree walk if a change happened.
      
      Further, we no longer get a ref on the connection looked up in the
      data_ready handler unless we queue the connection's work item - and then
      only if the refcount > 0.
      
      
      Note that I'm avoiding the use of a hash table for service connections
      because each service connection is addressed by a 62-bit number
      (constructed from epoch and connection ID >> 2) that would allow the client
      to engage in bucket stuffing, given knowledge of the hash algorithm.
      Peers, however, are hashed as the network address is less controllable by
      the client.  The total number of peers will also be limited in a future
      commit.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      8496af50
    • D
      rxrpc: Move data_ready peer lookup into rxrpc_find_connection() · 1291e9d1
      David Howells 提交于
      Move the peer lookup done in input.c by data_ready into
      rxrpc_find_connection().
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      1291e9d1
    • D
      rxrpc: Maintain an extra ref on a conn for the cache list · 001c1122
      David Howells 提交于
      Overhaul the usage count accounting for the rxrpc_connection struct to make
      it easier to implement RCU access from the data_ready handler.
      
      The problem is that currently we're using a lock to prevent the garbage
      collector from trying to clean up a connection that we're contemplating
      unidling.  We could just stick incoming packets on the connection we find,
      but we've then got a problem that we may race when dispatching a work item
      to process it as we need to give that a ref to prevent the rxrpc_connection
      struct from disappearing in the meantime.
      
      Further, incoming packets may get discarded if attached to an
      rxrpc_connection struct that is going away.  Whilst this is not a total
      disaster - the client will presumably resend - it would delay processing of
      the call.  This would affect the AFS client filesystem's service manager
      operation.
      
      To this end:
      
       (1) We now maintain an extra count on the connection usage count whilst it
           is on the connection list.  This mean it is not in use when its
           refcount is 1.
      
       (2) When trying to reuse an old connection, we only increment the refcount
           if it is greater than 0.  If it is 0, we replace it in the tree with a
           new candidate connection.
      
       (3) Two connection flags are added to indicate whether or not a connection
           is in the local's client connection tree (used by sendmsg) or the
           peer's service connection tree (used by data_ready).  This makes sure
           that we don't try and remove a connection if it got replaced.
      
           The flags are tested under lock with the removal operation to prevent
           the reaper from killing the rxrpc_connection struct whilst someone
           else is trying to effect a replacement.
      
           This could probably be alleviated by using memory barriers between the
           flag set/test and the rb_tree ops.  The rb_tree op would still need to
           be under the lock, however.
      
       (4) When trying to reap an old connection, we try to flip the usage count
           from 1 to 0.  If it's not 1 at that point, then it must've come back
           to life temporarily and we ignore it.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      001c1122
    • D
      rxrpc: Split service connection code out into its own file · 7877a4a4
      David Howells 提交于
      Split the service-specific connection code out into into its own file.  The
      client-specific code has already been split out.  This will leave just the
      common code in the original file.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      7877a4a4
    • D
      rxrpc: Split client connection code out into its own file · c6d2b8d7
      David Howells 提交于
      Split the client-specific connection code out into its own file.  It will
      behave somewhat differently from the service-specific connection code, so
      it makes sense to separate them.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      c6d2b8d7
    • D
      rxrpc: Call channels should have separate call number spaces · a1399f8b
      David Howells 提交于
      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
           conn->channels[].
      
       (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
           number.
      
           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: NDavid Howells <dhowells@redhat.com>
      a1399f8b
    • D
      rxrpc: Add RCU destruction for connections and calls · dee46364
      David Howells 提交于
      Add RCU destruction for connections and calls as the RCU lookup from the
      transport socket data_ready handler is going to come along shortly.
      
      Whilst we're at it, move the cleanup workqueue flushing and RCU barrierage
      into the destruction code for the objects that need it (locals and
      connections) and add the extra RCU barrier required for connection cleanup.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      dee46364
    • D
      rxrpc: Release a call's connection ref on call disconnection · e653cfe4
      David Howells 提交于
      When a call is disconnected, clear the call's pointer to the connection and
      release the associated ref on that connection.  This means that the call no
      longer pins the connection and the connection can be discarded even before
      the call is.
      
      As the code currently stands, the call struct is effectively pinned by
      userspace until userspace has enacted a recvmsg() to retrieve the final
      call state as sk_buffs on the receive queue pin the call to which they're
      related because:
      
       (1) The rxrpc_call struct contains the userspace ID that recvmsg() has to
           include in the control message buffer to indicate which call is being
           referred to.  This ID must remain valid until the terminal packet is
           completely read and must be invalidated immediately at that point as
           userspace is entitled to immediately reuse it.
      
       (2) The final ACK to the reply to a client call isn't sent until the last
           data packet is entirely read (it's probably worth altering this in
           future to be send the ACK as soon as all the data has been received).
      
      
      This change requires a bit of rearrangement to make sure that the call
      isn't going to try and access the connection again after protocol
      completion:
      
       (1) Delete the error link earlier when we're releasing the call.  Possibly
           network errors should be distributed via connections at the cost of
           adding in an access to the rxrpc_connection struct.
      
       (2) Remove the call from the connection's call tree before disconnecting
           the call.  The call tree needs to be removed anyway and incoming
           packets delivered by channel pointer instead.
      
       (3) The release call event should be considered last after all other
           events have been processed so that we don't need access to the
           connection again.
      
       (4) Move the channel_lock taking from rxrpc_release_call() to
           rxrpc_disconnect_call() where it will be required in future.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      e653cfe4
    • D
      rxrpc: Turn connection #defines into enums and put outside struct def · bba304db
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      bba304db
    • H
      rxrpc: Avoid using stack memory in SG lists in rxkad · a263629d
      Herbert Xu 提交于
      rxkad uses stack memory in SG lists which would not work if stacks were
      allocated from vmalloc memory.  In fact, in most cases this isn't even
      necessary as the stack memory ends up getting copied over to kmalloc
      memory.
      
      This patch eliminates all the unnecessary stack memory uses by supplying
      the final destination directly to the crypto API.  In two instances where a
      temporary buffer is actually needed we also switch use a scratch area in
      the rxrpc_call struct (only one DATA packet will be being secured or
      verified at a time).
      
      Finally there is no need to split a split-page buffer into two SG entries
      so code dealing with that has been removed.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      a263629d
    • D
      rxrpc: Check the source of a packet to a client conn · 689f4c64
      David Howells 提交于
      When looking up a client connection to which to route a packet, we need to
      check that the packet came from the correct source so that a peer can't try
      to muck around with another peer's connection.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      689f4c64
    • D
      rxrpc: Fix some sparse errors · 88b99d0b
      David Howells 提交于
      Fix the following sparse errors:
      
      ../net/rxrpc/conn_object.c:77:17: warning: incorrect type in assignment (different base types)
      ../net/rxrpc/conn_object.c:77:17:    expected restricted __be32 [usertype] call_id
      ../net/rxrpc/conn_object.c:77:17:    got unsigned int [unsigned] [usertype] call_id
      ../net/rxrpc/conn_object.c:84:21: warning: restricted __be32 degrades to integer
      ../net/rxrpc/conn_object.c:86:26: warning: restricted __be32 degrades to integer
      ../net/rxrpc/conn_object.c:357:15: warning: incorrect type in assignment (different base types)
      ../net/rxrpc/conn_object.c:357:15:    expected restricted __be32 [usertype] epoch
      ../net/rxrpc/conn_object.c:357:15:    got unsigned int [unsigned] [usertype] epoch
      ../net/rxrpc/conn_object.c:369:21: warning: restricted __be32 degrades to integer
      ../net/rxrpc/conn_object.c:371:26: warning: restricted __be32 degrades to integer
      ../net/rxrpc/conn_object.c:411:21: warning: restricted __be32 degrades to integer
      ../net/rxrpc/conn_object.c:413:26: warning: restricted __be32 degrades to integer
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      88b99d0b
  18. 22 6月, 2016 4 次提交
    • D
      rxrpc: Kill off the rxrpc_transport struct · aa390bbe
      David Howells 提交于
      The rxrpc_transport struct is now redundant, given that the rxrpc_peer
      struct is now per peer port rather than per peer host, so get rid of it.
      
      Service connection lists are transferred to the rxrpc_peer struct, as is
      the conn_lock.  Previous patches moved the client connection handling out
      of the rxrpc_transport struct and discarded the connection bundling code.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      aa390bbe
    • D
      rxrpc: Kill the client connection bundle concept · 999b69f8
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      999b69f8
    • D
      rxrpc: Provide more refcount helper functions · 5627cc8b
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      5627cc8b
    • D
      rxrpc: Use IDR to allocate client conn IDs on a machine-wide basis · 4a3388c8
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      4a3388c8