Skip to content

L
linux
Switch branch/tag
  1. 09 Sep, 2020 36 commits
  3. 08 Sep, 2020 4 commits
    • David Howells's avatar
      rxrpc: Allow multiple client connections to the same peer · 288827d5
      David Howells authored 
      Allow the number of parallel connections to a machine to be expanded from a
single connection to a maximum of four.  This allows up to 16 calls to be
in progress at the same time to any particular peer instead of 4.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      288827d5
    • David Howells's avatar
      rxrpc: Rewrite the client connection manager · 245500d8
      David Howells authored 
      Rewrite the rxrpc client connection manager so that it can support multiple
connections for a given security key to a peer.  The following changes are
made:

 (1) For each open socket, the code currently maintains an rbtree with the
     connections placed into it, keyed by communications parameters.  This
     is tricky to maintain as connections can be culled from the tree or
     replaced within it.  Connections can require replacement for a number
     of reasons, e.g. their IDs span too great a range for the IDR data
     type to represent efficiently, the call ID numbers on that conn would
     overflow or the conn got aborted.

     This is changed so that there's now a connection bundle object placed
     in the tree, keyed on the same parameters.  The bundle, however, does
     not need to be replaced.

 (2) An rxrpc_bundle object can now manage the available channels for a set
     of parallel connections.  The lock that manages this is moved there
     from the rxrpc_connection struct (channel_lock).

 (3) There'a a dummy bundle for all incoming connections to share so that
     they have a channel_lock too.  It might be better to give each
     incoming connection its own bundle.  This bundle is not needed to
     manage which channels incoming calls are made on because that's the
     solely at whim of the client.

 (4) The restrictions on how many client connections are around are
     removed.  Instead, a previous patch limits the number of client calls
     that can be allocated.  Ordinarily, client connections are reaped
     after 2 minutes on the idle queue, but when more than a certain number
     of connections are in existence, the reaper starts reaping them after
     2s of idleness instead to get the numbers back down.

     It could also be made such that new call allocations are forced to
     wait until the number of outstanding connections subsides.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      245500d8
    • David Howells's avatar
      rxrpc: Impose a maximum number of client calls · b7a7d674
      David Howells authored 
      Impose a maximum on the number of client rxrpc calls that are allowed
simultaneously.  This will be in lieu of a maximum number of client
connections as this is easier to administed as, unlike connections, calls
aren't reusable (to be changed in a subsequent patch)..

This doesn't affect the limits on service calls and connections.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b7a7d674
    • Jose M. Guisado Gomez's avatar
      netfilter: nf_tables: add userdata support for nft_object · b131c964
      Jose M. Guisado Gomez authored 
      Enables storing userdata for nft_object. Initially this will store an
optional comment but can be extended in the future as needed.

Adds new attribute NFTA_OBJ_USERDATA to nft_object.
Signed-off-by: default avatarJose M. Guisado Gomez <guigom@riseup.net>
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      b131c964
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7