summaryrefslogtreecommitdiffstats
path: root/arch/mips/pci/pci-bcm1480.c
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2020-07-01 11:15:32 +0100
committerDavid Howells <dhowells@redhat.com>2020-09-08 21:11:43 +0100
commit245500d853e9f20036cec7df4f6984ece4c6bf26 (patch)
tree5481d1dda93820eb262f8bd80d754c4f71fb4d5a /arch/mips/pci/pci-bcm1480.c
parentb7a7d67408032843c14071711d6259aada9392f0 (diff)
downloadlinux-stable-245500d853e9f20036cec7df4f6984ece4c6bf26.tar.gz
linux-stable-245500d853e9f20036cec7df4f6984ece4c6bf26.tar.bz2
linux-stable-245500d853e9f20036cec7df4f6984ece4c6bf26.zip
rxrpc: Rewrite the client connection manager
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: David Howells <dhowells@redhat.com>
Diffstat (limited to 'arch/mips/pci/pci-bcm1480.c')
0 files changed, 0 insertions, 0 deletions