af_rxrpc: RXRPC reorganisation

[Tim Smith]

I think I need to re-organise a chunk of the RXRPC code...

The race that's happening that's causing the server to send a BUSY is a bit 
nastier than I thought. Rather than being a race between the input and the 
output, it's a race between inputs.

What's happening is, the final ACKs from the client are getting into the call 
work queues and then not getting processed for a while, and the new call 
setups are arriving and getting processed first.

struct rxrpc_call seems to contain a lot of stuff which is per-channel (really 
it describes a channel), but it gets created anew for each call. I really want 
to feed the new call setup to a per-channel work queue, but no such queue 
exists at the right time...

So I was thinking of reorganising things as follows:

Each connection has RXRPC_MAXCALLS (practically, 4) pre-allocated channels 
which live as long as the connection, and whose state is never modified except 
by the workqueue each has for processing packets.

Thus getting a packet into the right queue becomes a pretty simple lookup: 
find the connection (instead of the call/channel as at present) using a hash 
table, and drop the packet into the correct channel's queue with a straight 
array-dereference. Connection-level packets can be dealt with at this time, 
but the channel manages its own state machine.

Nothing the channel workqueue does ever modifies any shared state, so no 
locking is required (provided everything done by a single workqueue is 
strictly ordered - is that true?). If I can guarantee never to destroy a 
connection while its channels are active or a local endpoint while its 
connections are active, I don't need to hold locks (or even reference 
counts?), which means I can cheerfully manage whatever memory I need to 
allocate on a per-call basis in the channel worker without needing much in the 
way of destructor queues.

This'll be a rather big patch though. You up for a big patch?


-- 
Tim Smith <tim at electronghost.co.uk>
"Dude." "Dude." "Dentist." "Dude."
    -- Conversation overheard between two eCos hackers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20140526/3a17a03f/attachment.sig>