rxrpc: Don't expose skbs to in-kernel users [ver #2]
Don't expose skbs to in-kernel users, such as the AFS filesystem, but instead provide a notification hook the indicates that a call needs attention and another that indicates that there's a new call to be collected. This makes the following possibilities more achievable: (1) Call refcounting can be made simpler if skbs don't hold refs to calls. (2) skbs referring to non-data events will be able to be freed much sooner rather than being queued for AFS to pick up as rxrpc_kernel_recv_data will be able to consult the call state. (3) We can shortcut the receive phase when a call is remotely aborted because we don't have to go through all the packets to get to the one cancelling the operation. (4) It makes it easier to do encryption/decryption directly between AFS's buffers and sk_buffs. (5) Encryption/decryption can more easily be done in the AFS's thread contexts - usually that of the userspace process that issued a syscall - rather than in one of rxrpc's background threads on a workqueue. (6) AFS will be able to wait synchronously on a call inside AF_RXRPC. To make this work, the following interface function has been added: int rxrpc_kernel_recv_data( struct socket *sock, struct rxrpc_call *call, void *buffer, size_t bufsize, size_t *_offset, bool want_more, u32 *_abort_code); This is the recvmsg equivalent. It allows the caller to find out about the state of a specific call and to transfer received data into a buffer piecemeal. afs_extract_data() and rxrpc_kernel_recv_data() now do all the extraction logic between them. They don't wait synchronously yet because the socket lock needs to be dealt with. Five interface functions have been removed: rxrpc_kernel_is_data_last() rxrpc_kernel_get_abort_code() rxrpc_kernel_get_error_number() rxrpc_kernel_free_skb() rxrpc_kernel_data_consumed() As a temporary hack, sk_buffs going to an in-kernel call are queued on the rxrpc_call struct (->knlrecv_queue) rather than being handed over to the in-kernel user. To process the queue internally, a temporary function, temp_deliver_data() has been added. This will be replaced with common code between the rxrpc_recvmsg() path and the kernel_rxrpc_recv_data() path in a future patch. Signed-off-by:David Howells <dhowells@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
Showing
- Documentation/networking/rxrpc.txt 31 additions, 41 deletionsDocumentation/networking/rxrpc.txt
- fs/afs/cmservice.c 77 additions, 65 deletionsfs/afs/cmservice.c
- fs/afs/fsclient.c 62 additions, 86 deletionsfs/afs/fsclient.c
- fs/afs/internal.h 9 additions, 24 deletionsfs/afs/internal.h
- fs/afs/rxrpc.c 158 additions, 281 deletionsfs/afs/rxrpc.c
- fs/afs/vlclient.c 3 additions, 4 deletionsfs/afs/vlclient.c
- include/net/af_rxrpc.h 11 additions, 24 deletionsinclude/net/af_rxrpc.h
- net/rxrpc/af_rxrpc.c 15 additions, 14 deletionsnet/rxrpc/af_rxrpc.c
- net/rxrpc/ar-internal.h 21 additions, 2 deletionsnet/rxrpc/ar-internal.h
- net/rxrpc/call_accept.c 9 additions, 4 deletionsnet/rxrpc/call_accept.c
- net/rxrpc/call_object.c 3 additions, 2 deletionsnet/rxrpc/call_object.c
- net/rxrpc/conn_event.c 0 additions, 1 deletionnet/rxrpc/conn_event.c
- net/rxrpc/input.c 8 additions, 2 deletionsnet/rxrpc/input.c
- net/rxrpc/output.c 1 addition, 1 deletionnet/rxrpc/output.c
- net/rxrpc/recvmsg.c 157 additions, 34 deletionsnet/rxrpc/recvmsg.c
- net/rxrpc/skbuff.c 0 additions, 1 deletionnet/rxrpc/skbuff.c
Loading
Please register or sign in to comment