2019-05-27 14:55:01 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2007-04-27 06:55:03 +08:00
|
|
|
/* Maintain an RxRPC server socket to do AFS communications through
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
|
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
|
*/
|
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2017-02-03 02:15:33 +08:00
|
|
|
#include <linux/sched/signal.h>
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
#include <net/sock.h>
|
|
|
|
|
#include <net/af_rxrpc.h>
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
#include "afs_cm.h"
|
2018-10-20 07:57:58 +08:00
|
|
|
#include "protocol_yfs.h"
|
2022-10-07 04:45:42 +08:00
|
|
|
#define RXRPC_TRACE_ONLY_DEFINE_ENUMS
|
|
|
|
|
#include <trace/events/rxrpc.h>
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
struct workqueue_struct *afs_async_calls;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
static void afs_wake_up_call_waiter(struct sock *, struct rxrpc_call *, unsigned long);
|
|
|
|
|
static void afs_wake_up_async_call(struct sock *, struct rxrpc_call *, unsigned long);
|
|
|
|
|
static void afs_process_async_call(struct work_struct *);
|
2016-09-08 18:10:12 +08:00
|
|
|
static void afs_rx_new_call(struct sock *, struct rxrpc_call *, unsigned long);
|
|
|
|
|
static void afs_rx_discard_new_call(struct rxrpc_call *, unsigned long);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
static int afs_deliver_cm_op_id(struct afs_call *);
|
2007-04-27 06:55:03 +08:00
|
|
|
|
|
|
|
|
/* asynchronous incoming call initial processing */
|
|
|
|
|
static const struct afs_call_type afs_RXCMxxxx = {
|
2007-04-27 06:57:07 +08:00
|
|
|
.name = "CB.xxxx",
|
2007-04-27 06:55:03 +08:00
|
|
|
.deliver = afs_deliver_cm_op_id,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* open an RxRPC socket and bind it to be a server for callback notifications
|
|
|
|
|
* - the socket is left in blocking mode and non-blocking ops use MSG_DONTWAIT
|
|
|
|
|
*/
|
2017-11-02 23:27:45 +08:00
|
|
|
int afs_open_socket(struct afs_net *net)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
|
|
|
|
struct sockaddr_rxrpc srx;
|
|
|
|
|
struct socket *socket;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
_enter("");
|
|
|
|
|
|
2018-05-18 18:46:15 +08:00
|
|
|
ret = sock_create_kern(net->net, AF_RXRPC, SOCK_DGRAM, PF_INET6, &socket);
|
2016-06-11 05:30:37 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
goto error_1;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
|
|
|
|
socket->sk->sk_allocation = GFP_NOFS;
|
|
|
|
|
|
|
|
|
|
/* bind the callback manager's address to make this a server socket */
|
2017-11-02 23:27:47 +08:00
|
|
|
memset(&srx, 0, sizeof(srx));
|
2007-04-27 06:55:03 +08:00
|
|
|
srx.srx_family = AF_RXRPC;
|
|
|
|
|
srx.srx_service = CM_SERVICE;
|
|
|
|
|
srx.transport_type = SOCK_DGRAM;
|
2017-11-02 23:27:47 +08:00
|
|
|
srx.transport_len = sizeof(srx.transport.sin6);
|
|
|
|
|
srx.transport.sin6.sin6_family = AF_INET6;
|
|
|
|
|
srx.transport.sin6.sin6_port = htons(AFS_CM_PORT);
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2020-05-28 13:12:35 +08:00
|
|
|
ret = rxrpc_sock_set_min_security_level(socket->sk,
|
|
|
|
|
RXRPC_SECURITY_ENCRYPT);
|
2018-05-11 06:10:40 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
goto error_2;
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
ret = kernel_bind(socket, (struct sockaddr *) &srx, sizeof(srx));
|
2017-11-02 23:27:52 +08:00
|
|
|
if (ret == -EADDRINUSE) {
|
|
|
|
|
srx.transport.sin6.sin6_port = 0;
|
|
|
|
|
ret = kernel_bind(socket, (struct sockaddr *) &srx, sizeof(srx));
|
|
|
|
|
}
|
2016-06-11 05:30:37 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
goto error_2;
|
|
|
|
|
|
2018-10-20 07:57:58 +08:00
|
|
|
srx.srx_service = YFS_CM_SERVICE;
|
|
|
|
|
ret = kernel_bind(socket, (struct sockaddr *) &srx, sizeof(srx));
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
goto error_2;
|
|
|
|
|
|
2018-10-20 07:57:59 +08:00
|
|
|
/* Ideally, we'd turn on service upgrade here, but we can't because
|
|
|
|
|
* OpenAFS is buggy and leaks the userStatus field from packet to
|
|
|
|
|
* packet and between FS packets and CB packets - so if we try to do an
|
|
|
|
|
* upgrade on an FS packet, OpenAFS will leak that into the CB packet
|
|
|
|
|
* it sends back to us.
|
|
|
|
|
*/
|
2018-10-20 07:57:58 +08:00
|
|
|
|
2016-09-08 18:10:12 +08:00
|
|
|
rxrpc_kernel_new_call_notification(socket, afs_rx_new_call,
|
|
|
|
|
afs_rx_discard_new_call);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
|
2016-06-11 05:30:37 +08:00
|
|
|
ret = kernel_listen(socket, INT_MAX);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
goto error_2;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
net->socket = socket;
|
|
|
|
|
afs_charge_preallocation(&net->charge_preallocation_work);
|
2007-04-27 06:55:03 +08:00
|
|
|
_leave(" = 0");
|
|
|
|
|
return 0;
|
2016-06-11 05:30:37 +08:00
|
|
|
|
|
|
|
|
error_2:
|
|
|
|
|
sock_release(socket);
|
|
|
|
|
error_1:
|
|
|
|
|
_leave(" = %d", ret);
|
|
|
|
|
return ret;
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* close the RxRPC socket AFS was using
|
|
|
|
|
*/
|
2017-11-02 23:27:45 +08:00
|
|
|
void afs_close_socket(struct afs_net *net)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
|
|
|
|
_enter("");
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
kernel_listen(net->socket, 0);
|
2017-01-05 18:38:36 +08:00
|
|
|
flush_workqueue(afs_async_calls);
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
if (net->spare_incoming_call) {
|
|
|
|
|
afs_put_call(net->spare_incoming_call);
|
|
|
|
|
net->spare_incoming_call = NULL;
|
2016-09-08 18:10:12 +08:00
|
|
|
}
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
_debug("outstanding %u", atomic_read(&net->nr_outstanding_calls));
|
2018-03-15 18:42:28 +08:00
|
|
|
wait_var_event(&net->nr_outstanding_calls,
|
|
|
|
|
!atomic_read(&net->nr_outstanding_calls));
|
2016-04-08 00:23:03 +08:00
|
|
|
_debug("no outstanding calls");
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
kernel_sock_shutdown(net->socket, SHUT_RDWR);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
flush_workqueue(afs_async_calls);
|
2017-11-02 23:27:45 +08:00
|
|
|
sock_release(net->socket);
|
2007-04-27 06:55:03 +08:00
|
|
|
|
|
|
|
|
_debug("dework");
|
|
|
|
|
_leave("");
|
|
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:57:07 +08:00
|
|
|
/*
|
2017-01-05 18:38:36 +08:00
|
|
|
* Allocate a call.
|
2007-04-27 06:57:07 +08:00
|
|
|
*/
|
2017-11-02 23:27:45 +08:00
|
|
|
static struct afs_call *afs_alloc_call(struct afs_net *net,
|
|
|
|
|
const struct afs_call_type *type,
|
2017-01-05 18:38:36 +08:00
|
|
|
gfp_t gfp)
|
2007-04-27 06:57:07 +08:00
|
|
|
{
|
2017-01-05 18:38:36 +08:00
|
|
|
struct afs_call *call;
|
|
|
|
|
int o;
|
2007-04-27 06:57:07 +08:00
|
|
|
|
2017-01-05 18:38:36 +08:00
|
|
|
call = kzalloc(sizeof(*call), gfp);
|
|
|
|
|
if (!call)
|
|
|
|
|
return NULL;
|
2007-04-27 06:57:07 +08:00
|
|
|
|
2017-01-05 18:38:36 +08:00
|
|
|
call->type = type;
|
2017-11-02 23:27:45 +08:00
|
|
|
call->net = net;
|
2018-03-28 06:03:00 +08:00
|
|
|
call->debug_id = atomic_inc_return(&rxrpc_debug_id);
|
2022-07-06 17:52:14 +08:00
|
|
|
refcount_set(&call->ref, 1);
|
2017-01-05 18:38:36 +08:00
|
|
|
INIT_WORK(&call->async_work, afs_process_async_call);
|
|
|
|
|
init_waitqueue_head(&call->waitq);
|
2017-11-02 23:27:53 +08:00
|
|
|
spin_lock_init(&call->state_lock);
|
2019-11-21 17:12:17 +08:00
|
|
|
call->iter = &call->def_iter;
|
2016-04-08 00:23:03 +08:00
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
o = atomic_inc_return(&net->nr_outstanding_calls);
|
2022-07-06 18:26:14 +08:00
|
|
|
trace_afs_call(call->debug_id, afs_call_trace_alloc, 1, o,
|
2017-01-05 18:38:36 +08:00
|
|
|
__builtin_return_address(0));
|
|
|
|
|
return call;
|
2007-04-27 06:57:07 +08:00
|
|
|
}
|
|
|
|
|
|
2014-05-21 21:48:05 +08:00
|
|
|
/*
|
2017-01-05 18:38:36 +08:00
|
|
|
* Dispose of a reference on a call.
|
2014-05-21 21:48:05 +08:00
|
|
|
*/
|
2017-01-05 18:38:36 +08:00
|
|
|
void afs_put_call(struct afs_call *call)
|
2014-05-21 21:48:05 +08:00
|
|
|
{
|
2017-11-02 23:27:45 +08:00
|
|
|
struct afs_net *net = call->net;
|
2022-07-06 18:26:14 +08:00
|
|
|
unsigned int debug_id = call->debug_id;
|
2022-07-06 17:52:14 +08:00
|
|
|
bool zero;
|
|
|
|
|
int r, o;
|
2017-01-05 18:38:36 +08:00
|
|
|
|
2022-07-06 17:52:14 +08:00
|
|
|
zero = __refcount_dec_and_test(&call->ref, &r);
|
|
|
|
|
o = atomic_read(&net->nr_outstanding_calls);
|
2022-07-06 18:26:14 +08:00
|
|
|
trace_afs_call(debug_id, afs_call_trace_put, r - 1, o,
|
2017-01-05 18:38:36 +08:00
|
|
|
__builtin_return_address(0));
|
|
|
|
|
|
2022-07-06 17:52:14 +08:00
|
|
|
if (zero) {
|
2017-01-05 18:38:36 +08:00
|
|
|
ASSERT(!work_pending(&call->async_work));
|
|
|
|
|
ASSERT(call->type->name != NULL);
|
|
|
|
|
|
2023-10-27 01:13:13 +08:00
|
|
|
rxrpc_kernel_put_peer(call->peer);
|
|
|
|
|
|
2017-01-05 18:38:36 +08:00
|
|
|
if (call->rxcall) {
|
2023-04-22 06:03:46 +08:00
|
|
|
rxrpc_kernel_shutdown_call(net->socket, call->rxcall);
|
|
|
|
|
rxrpc_kernel_put_call(net->socket, call->rxcall);
|
2017-01-05 18:38:36 +08:00
|
|
|
call->rxcall = NULL;
|
|
|
|
|
}
|
|
|
|
|
if (call->type->destructor)
|
|
|
|
|
call->type->destructor(call);
|
|
|
|
|
|
2020-04-18 00:31:26 +08:00
|
|
|
afs_unuse_server_notime(call->net, call->server, afs_server_trace_put_call);
|
2017-01-05 18:38:36 +08:00
|
|
|
kfree(call->request);
|
|
|
|
|
|
2022-07-06 18:26:14 +08:00
|
|
|
trace_afs_call(call->debug_id, afs_call_trace_free, 0, o,
|
2017-01-05 18:38:36 +08:00
|
|
|
__builtin_return_address(0));
|
2018-03-28 06:03:00 +08:00
|
|
|
kfree(call);
|
|
|
|
|
|
|
|
|
|
o = atomic_dec_return(&net->nr_outstanding_calls);
|
2017-01-05 18:38:36 +08:00
|
|
|
if (o == 0)
|
2018-03-15 18:42:28 +08:00
|
|
|
wake_up_var(&net->nr_outstanding_calls);
|
2014-05-21 21:48:05 +08:00
|
|
|
}
|
2014-05-21 23:04:11 +08:00
|
|
|
}
|
|
|
|
|
|
2019-01-10 23:14:29 +08:00
|
|
|
static struct afs_call *afs_get_call(struct afs_call *call,
|
|
|
|
|
enum afs_call_trace why)
|
|
|
|
|
{
|
2022-07-06 17:52:14 +08:00
|
|
|
int r;
|
2019-01-10 23:14:29 +08:00
|
|
|
|
2022-07-06 17:52:14 +08:00
|
|
|
__refcount_inc(&call->ref, &r);
|
|
|
|
|
|
2022-07-06 18:26:14 +08:00
|
|
|
trace_afs_call(call->debug_id, why, r + 1,
|
2019-01-10 23:14:29 +08:00
|
|
|
atomic_read(&call->net->nr_outstanding_calls),
|
|
|
|
|
__builtin_return_address(0));
|
|
|
|
|
return call;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-21 23:04:11 +08:00
|
|
|
/*
|
2018-10-20 07:57:59 +08:00
|
|
|
* Queue the call for actual work.
|
2014-05-21 23:04:11 +08:00
|
|
|
*/
|
2018-10-20 07:57:59 +08:00
|
|
|
static void afs_queue_call_work(struct afs_call *call)
|
2014-05-21 23:04:11 +08:00
|
|
|
{
|
2018-10-20 07:57:59 +08:00
|
|
|
if (call->type->work) {
|
|
|
|
|
INIT_WORK(&call->work, call->type->work);
|
2017-01-05 18:38:36 +08:00
|
|
|
|
2019-01-10 23:14:29 +08:00
|
|
|
afs_get_call(call, afs_call_trace_work);
|
2018-10-20 07:57:59 +08:00
|
|
|
if (!queue_work(afs_wq, &call->work))
|
|
|
|
|
afs_put_call(call);
|
|
|
|
|
}
|
2014-05-21 21:48:05 +08:00
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/*
|
|
|
|
|
* allocate a call with flat request and reply buffers
|
|
|
|
|
*/
|
2017-11-02 23:27:45 +08:00
|
|
|
struct afs_call *afs_alloc_flat_call(struct afs_net *net,
|
|
|
|
|
const struct afs_call_type *type,
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
size_t request_size, size_t reply_max)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
|
|
|
|
struct afs_call *call;
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
call = afs_alloc_call(net, type, GFP_NOFS);
|
2007-04-27 06:55:03 +08:00
|
|
|
if (!call)
|
|
|
|
|
goto nomem_call;
|
|
|
|
|
|
|
|
|
|
if (request_size) {
|
2017-01-05 18:38:36 +08:00
|
|
|
call->request_size = request_size;
|
2007-04-27 06:55:03 +08:00
|
|
|
call->request = kmalloc(request_size, GFP_NOFS);
|
|
|
|
|
if (!call->request)
|
2007-04-27 06:57:07 +08:00
|
|
|
goto nomem_free;
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
if (reply_max) {
|
2017-01-05 18:38:36 +08:00
|
|
|
call->reply_max = reply_max;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
call->buffer = kmalloc(reply_max, GFP_NOFS);
|
2007-04-27 06:55:03 +08:00
|
|
|
if (!call->buffer)
|
2007-04-27 06:57:07 +08:00
|
|
|
goto nomem_free;
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
2018-10-20 07:57:56 +08:00
|
|
|
afs_extract_to_buf(call, call->reply_max);
|
2017-11-02 23:27:51 +08:00
|
|
|
call->operation_ID = type->op;
|
2007-04-27 06:55:03 +08:00
|
|
|
init_waitqueue_head(&call->waitq);
|
|
|
|
|
return call;
|
|
|
|
|
|
2007-04-27 06:57:07 +08:00
|
|
|
nomem_free:
|
2017-01-05 18:38:36 +08:00
|
|
|
afs_put_call(call);
|
2007-04-27 06:55:03 +08:00
|
|
|
nomem_call:
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* clean up a call with flat buffer
|
|
|
|
|
*/
|
|
|
|
|
void afs_flat_call_destructor(struct afs_call *call)
|
|
|
|
|
{
|
|
|
|
|
_enter("");
|
|
|
|
|
|
|
|
|
|
kfree(call->request);
|
|
|
|
|
call->request = NULL;
|
|
|
|
|
kfree(call->buffer);
|
|
|
|
|
call->buffer = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-29 17:18:56 +08:00
|
|
|
/*
|
|
|
|
|
* Advance the AFS call state when the RxRPC call ends the transmit phase.
|
|
|
|
|
*/
|
|
|
|
|
static void afs_notify_end_request_tx(struct sock *sock,
|
|
|
|
|
struct rxrpc_call *rxcall,
|
|
|
|
|
unsigned long call_user_ID)
|
|
|
|
|
{
|
|
|
|
|
struct afs_call *call = (struct afs_call *)call_user_ID;
|
|
|
|
|
|
2017-11-02 23:27:53 +08:00
|
|
|
afs_set_call_state(call, AFS_CALL_CL_REQUESTING, AFS_CALL_CL_AWAIT_REPLY);
|
2017-08-29 17:18:56 +08:00
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/*
|
2019-04-25 21:26:50 +08:00
|
|
|
* Initiate a call and synchronously queue up the parameters for dispatch. Any
|
|
|
|
|
* error is stored into the call struct, which the caller must check for.
|
2007-04-27 06:55:03 +08:00
|
|
|
*/
|
2023-10-20 23:13:03 +08:00
|
|
|
void afs_make_call(struct afs_call *call, gfp_t gfp)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
|
|
|
|
struct rxrpc_call *rxcall;
|
|
|
|
|
struct msghdr msg;
|
|
|
|
|
struct kvec iov[1];
|
2020-02-06 22:22:28 +08:00
|
|
|
size_t len;
|
2017-06-07 19:40:03 +08:00
|
|
|
s64 tx_total_len;
|
2007-04-27 06:55:03 +08:00
|
|
|
int ret;
|
|
|
|
|
|
2023-10-27 01:13:13 +08:00
|
|
|
_enter(",{%pISp+%u},", rxrpc_kernel_remote_addr(call->peer), call->service_id);
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2007-04-27 06:57:07 +08:00
|
|
|
ASSERT(call->type != NULL);
|
|
|
|
|
ASSERT(call->type->name != NULL);
|
|
|
|
|
|
AFS: implement basic file write support
Implement support for writing to regular AFS files, including:
(1) write
(2) truncate
(3) fsync, fdatasync
(4) chmod, chown, chgrp, utime.
AFS writeback attempts to batch writes into as chunks as large as it can manage
up to the point that it writes back 65535 pages in one chunk or it meets a
locked page.
Furthermore, if a page has been written to using a particular key, then should
another write to that page use some other key, the first write will be flushed
before the second is allowed to take place. If the first write fails due to a
security error, then the page will be scrapped and reread before the second
write takes place.
If a page is dirty and the callback on it is broken by the server, then the
dirty data is not discarded (same behaviour as NFS).
Shared-writable mappings are not supported by this patch.
[akpm@linux-foundation.org: fix a bunch of warnings]
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-09 17:33:46 +08:00
|
|
|
_debug("____MAKE %p{%s,%x} [%d]____",
|
|
|
|
|
call, call->type->name, key_serial(call->key),
|
2017-11-02 23:27:45 +08:00
|
|
|
atomic_read(&call->net->nr_outstanding_calls));
|
2007-04-27 06:57:07 +08:00
|
|
|
|
2023-11-17 17:20:28 +08:00
|
|
|
trace_afs_make_call(call);
|
|
|
|
|
|
2017-06-07 19:40:03 +08:00
|
|
|
/* Work out the length we're going to transmit. This is awkward for
|
|
|
|
|
* calls such as FS.StoreData where there's an extra injection of data
|
|
|
|
|
* after the initial fixed part.
|
|
|
|
|
*/
|
|
|
|
|
tx_total_len = call->request_size;
|
2020-02-06 22:22:28 +08:00
|
|
|
if (call->write_iter)
|
|
|
|
|
tx_total_len += iov_iter_count(call->write_iter);
|
2017-06-07 19:40:03 +08:00
|
|
|
|
2019-01-10 23:40:50 +08:00
|
|
|
/* If the call is going to be asynchronous, we need an extra ref for
|
|
|
|
|
* the call to hold itself so the caller need not hang on to its ref.
|
|
|
|
|
*/
|
2020-03-13 21:46:08 +08:00
|
|
|
if (call->async) {
|
2019-01-10 23:40:50 +08:00
|
|
|
afs_get_call(call, afs_call_trace_get);
|
2020-03-13 21:46:08 +08:00
|
|
|
call->drop_ref = true;
|
|
|
|
|
}
|
2019-01-10 23:40:50 +08:00
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/* create a call */
|
2023-10-27 01:13:13 +08:00
|
|
|
rxcall = rxrpc_kernel_begin_call(call->net->socket, call->peer, call->key,
|
2017-06-07 19:40:03 +08:00
|
|
|
(unsigned long)call,
|
2023-04-29 04:27:56 +08:00
|
|
|
tx_total_len,
|
|
|
|
|
call->max_lifespan,
|
|
|
|
|
gfp,
|
2019-04-25 21:26:50 +08:00
|
|
|
(call->async ?
|
2017-01-05 18:38:36 +08:00
|
|
|
afs_wake_up_async_call :
|
2017-10-18 18:36:39 +08:00
|
|
|
afs_wake_up_call_waiter),
|
2023-10-27 01:13:13 +08:00
|
|
|
call->service_id,
|
2018-03-28 06:03:00 +08:00
|
|
|
call->upgrade,
|
2020-03-13 17:22:09 +08:00
|
|
|
(call->intr ? RXRPC_PREINTERRUPTIBLE :
|
|
|
|
|
RXRPC_UNINTERRUPTIBLE),
|
2018-03-28 06:03:00 +08:00
|
|
|
call->debug_id);
|
2007-04-27 06:55:03 +08:00
|
|
|
if (IS_ERR(rxcall)) {
|
|
|
|
|
ret = PTR_ERR(rxcall);
|
2018-10-20 07:57:59 +08:00
|
|
|
call->error = ret;
|
2007-04-27 06:55:03 +08:00
|
|
|
goto error_kill_call;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
call->rxcall = rxcall;
|
2022-08-31 20:16:42 +08:00
|
|
|
call->issue_time = ktime_get_real();
|
2019-05-16 20:21:59 +08:00
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/* send the request */
|
|
|
|
|
iov[0].iov_base = call->request;
|
|
|
|
|
iov[0].iov_len = call->request_size;
|
|
|
|
|
|
|
|
|
|
msg.msg_name = NULL;
|
|
|
|
|
msg.msg_namelen = 0;
|
2022-09-16 08:25:47 +08:00
|
|
|
iov_iter_kvec(&msg.msg_iter, ITER_SOURCE, iov, 1, call->request_size);
|
2007-04-27 06:55:03 +08:00
|
|
|
msg.msg_control = NULL;
|
|
|
|
|
msg.msg_controllen = 0;
|
2020-02-06 22:22:28 +08:00
|
|
|
msg.msg_flags = MSG_WAITALL | (call->write_iter ? MSG_MORE : 0);
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
ret = rxrpc_kernel_send_data(call->net->socket, rxcall,
|
2017-08-29 17:18:56 +08:00
|
|
|
&msg, call->request_size,
|
|
|
|
|
afs_notify_end_request_tx);
|
2007-04-27 06:55:03 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
goto error_do_abort;
|
|
|
|
|
|
2020-02-06 22:22:28 +08:00
|
|
|
if (call->write_iter) {
|
|
|
|
|
msg.msg_iter = *call->write_iter;
|
|
|
|
|
msg.msg_flags &= ~MSG_MORE;
|
|
|
|
|
trace_afs_send_data(call, &msg);
|
|
|
|
|
|
|
|
|
|
ret = rxrpc_kernel_send_data(call->net->socket,
|
|
|
|
|
call->rxcall, &msg,
|
|
|
|
|
iov_iter_count(&msg.msg_iter),
|
|
|
|
|
afs_notify_end_request_tx);
|
|
|
|
|
*call->write_iter = msg.msg_iter;
|
|
|
|
|
|
|
|
|
|
trace_afs_sent_data(call, &msg, ret);
|
AFS: implement basic file write support
Implement support for writing to regular AFS files, including:
(1) write
(2) truncate
(3) fsync, fdatasync
(4) chmod, chown, chgrp, utime.
AFS writeback attempts to batch writes into as chunks as large as it can manage
up to the point that it writes back 65535 pages in one chunk or it meets a
locked page.
Furthermore, if a page has been written to using a particular key, then should
another write to that page use some other key, the first write will be flushed
before the second is allowed to take place. If the first write fails due to a
security error, then the page will be scrapped and reread before the second
write takes place.
If a page is dirty and the callback on it is broken by the server, then the
dirty data is not discarded (same behaviour as NFS).
Shared-writable mappings are not supported by this patch.
[akpm@linux-foundation.org: fix a bunch of warnings]
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-09 17:33:46 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
goto error_do_abort;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-10 23:40:50 +08:00
|
|
|
/* Note that at this point, we may have received the reply or an abort
|
|
|
|
|
* - and an asynchronous call may already have completed.
|
2019-04-25 21:26:50 +08:00
|
|
|
*
|
2023-10-20 23:13:03 +08:00
|
|
|
* afs_wait_for_call_to_complete(call)
|
2019-04-25 21:26:50 +08:00
|
|
|
* must be called to synchronously clean up.
|
2019-01-10 23:40:50 +08:00
|
|
|
*/
|
2019-04-25 21:26:50 +08:00
|
|
|
return;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
|
|
|
|
error_do_abort:
|
2017-03-17 00:27:47 +08:00
|
|
|
if (ret != -ECONNABORTED) {
|
2017-11-02 23:27:45 +08:00
|
|
|
rxrpc_kernel_abort_call(call->net->socket, rxcall,
|
2022-10-07 04:45:42 +08:00
|
|
|
RX_USER_ABORT, ret,
|
|
|
|
|
afs_abort_send_data_error);
|
2017-03-17 00:27:47 +08:00
|
|
|
} else {
|
2020-02-06 22:22:28 +08:00
|
|
|
len = 0;
|
2022-09-16 08:25:47 +08:00
|
|
|
iov_iter_kvec(&msg.msg_iter, ITER_DEST, NULL, 0, 0);
|
2018-08-04 00:06:56 +08:00
|
|
|
rxrpc_kernel_recv_data(call->net->socket, rxcall,
|
2020-02-06 22:22:28 +08:00
|
|
|
&msg.msg_iter, &len, false,
|
2018-08-04 00:06:56 +08:00
|
|
|
&call->abort_code, &call->service_id);
|
2023-10-26 00:53:33 +08:00
|
|
|
call->responded = true;
|
2017-03-17 00:27:47 +08:00
|
|
|
}
|
2017-11-02 23:27:51 +08:00
|
|
|
call->error = ret;
|
|
|
|
|
trace_afs_call_done(call);
|
2007-04-27 06:55:03 +08:00
|
|
|
error_kill_call:
|
2018-10-20 07:57:59 +08:00
|
|
|
if (call->type->done)
|
|
|
|
|
call->type->done(call);
|
2019-01-10 23:40:50 +08:00
|
|
|
|
|
|
|
|
/* We need to dispose of the extra ref we grabbed for an async call.
|
|
|
|
|
* The call, however, might be queued on afs_async_calls and we need to
|
|
|
|
|
* make sure we don't get any more notifications that might requeue it.
|
|
|
|
|
*/
|
2023-04-22 06:03:46 +08:00
|
|
|
if (call->rxcall)
|
|
|
|
|
rxrpc_kernel_shutdown_call(call->net->socket, call->rxcall);
|
2019-01-10 23:40:50 +08:00
|
|
|
if (call->async) {
|
|
|
|
|
if (cancel_work_sync(&call->async_work))
|
|
|
|
|
afs_put_call(call);
|
afs: Fix refcount underflow from error handling race
If an AFS cell that has an unreachable (eg. ENETUNREACH) server listed (VL
server or fileserver), an asynchronous probe to one of its addresses may
fail immediately because sendmsg() returns an error. When this happens, a
refcount underflow can happen if certain events hit a very small window.
The way this occurs is:
(1) There are two levels of "call" object, the afs_call and the
rxrpc_call. Each of them can be transitioned to a "completed" state
in the event of success or failure.
(2) Asynchronous afs_calls are self-referential whilst they are active to
prevent them from evaporating when they're not being processed. This
reference is disposed of when the afs_call is completed.
Note that an afs_call may only be completed once; once completed
completing it again will do nothing.
(3) When a call transmission is made, the app-side rxrpc code queues a Tx
buffer for the rxrpc I/O thread to transmit. The I/O thread invokes
sendmsg() to transmit it - and in the case of failure, it transitions
the rxrpc_call to the completed state.
(4) When an rxrpc_call is completed, the app layer is notified. In this
case, the app is kafs and it schedules a work item to process events
pertaining to an afs_call.
(5) When the afs_call event processor is run, it goes down through the
RPC-specific handler to afs_extract_data() to retrieve data from rxrpc
- and, in this case, it picks up the error from the rxrpc_call and
returns it.
The error is then propagated to the afs_call and that is completed
too. At this point the self-reference is released.
(6) If the rxrpc I/O thread manages to complete the rxrpc_call within the
window between rxrpc_send_data() queuing the request packet and
checking for call completion on the way out, then
rxrpc_kernel_send_data() will return the error from sendmsg() to the
app.
(7) Then afs_make_call() will see an error and will jump to the error
handling path which will attempt to clean up the afs_call.
(8) The problem comes when the error handling path in afs_make_call()
tries to unconditionally drop an async afs_call's self-reference.
This self-reference, however, may already have been dropped by
afs_extract_data() completing the afs_call
(9) The refcount underflows when we return to afs_do_probe_vlserver() and
that tries to drop its reference on the afs_call.
Fix this by making afs_make_call() attempt to complete the afs_call rather
than unconditionally putting it. That way, if afs_extract_data() manages
to complete the call first, afs_make_call() won't do anything.
The bug can be forced by making do_udp_sendmsg() return -ENETUNREACH and
sticking an msleep() in rxrpc_send_data() after the 'success:' label to
widen the race window.
The error message looks something like:
refcount_t: underflow; use-after-free.
WARNING: CPU: 3 PID: 720 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
...
RIP: 0010:refcount_warn_saturate+0xba/0x110
...
afs_put_call+0x1dc/0x1f0 [kafs]
afs_fs_get_capabilities+0x8b/0xe0 [kafs]
afs_fs_probe_fileserver+0x188/0x1e0 [kafs]
afs_lookup_server+0x3bf/0x3f0 [kafs]
afs_alloc_server_list+0x130/0x2e0 [kafs]
afs_create_volume+0x162/0x400 [kafs]
afs_get_tree+0x266/0x410 [kafs]
vfs_get_tree+0x25/0xc0
fc_mount+0xe/0x40
afs_d_automount+0x1b3/0x390 [kafs]
__traverse_mounts+0x8f/0x210
step_into+0x340/0x760
path_openat+0x13a/0x1260
do_filp_open+0xaf/0x160
do_sys_openat2+0xaf/0x170
or something like:
refcount_t: underflow; use-after-free.
...
RIP: 0010:refcount_warn_saturate+0x99/0xda
...
afs_put_call+0x4a/0x175
afs_send_vl_probes+0x108/0x172
afs_select_vlserver+0xd6/0x311
afs_do_cell_detect_alias+0x5e/0x1e9
afs_cell_detect_alias+0x44/0x92
afs_validate_fc+0x9d/0x134
afs_get_tree+0x20/0x2e6
vfs_get_tree+0x1d/0xc9
fc_mount+0xe/0x33
afs_d_automount+0x48/0x9d
__traverse_mounts+0xe0/0x166
step_into+0x140/0x274
open_last_lookups+0x1c1/0x1df
path_openat+0x138/0x1c3
do_filp_open+0x55/0xb4
do_sys_openat2+0x6c/0xb6
Fixes: 34fa47612bfe ("afs: Fix race in async call refcounting")
Reported-by: Bill MacAllister <bill@ca-zephyr.org>
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052304
Suggested-by: Jeffrey E Altman <jaltman@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Link: https://lore.kernel.org/r/2633992.1702073229@warthog.procyon.org.uk/ # v1
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-12-12 05:43:52 +08:00
|
|
|
afs_set_call_complete(call, ret, 0);
|
2019-01-10 23:40:50 +08:00
|
|
|
}
|
|
|
|
|
|
2023-10-26 00:53:33 +08:00
|
|
|
call->error = ret;
|
2019-01-10 23:40:50 +08:00
|
|
|
call->state = AFS_CALL_COMPLETE;
|
2007-04-27 06:55:03 +08:00
|
|
|
_leave(" = %d", ret);
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-08 04:50:29 +08:00
|
|
|
/*
|
|
|
|
|
* Log remote abort codes that indicate that we have a protocol disagreement
|
|
|
|
|
* with the server.
|
|
|
|
|
*/
|
|
|
|
|
static void afs_log_error(struct afs_call *call, s32 remote_abort)
|
|
|
|
|
{
|
|
|
|
|
static int max = 0;
|
|
|
|
|
const char *msg;
|
|
|
|
|
int m;
|
|
|
|
|
|
|
|
|
|
switch (remote_abort) {
|
|
|
|
|
case RX_EOF: msg = "unexpected EOF"; break;
|
|
|
|
|
case RXGEN_CC_MARSHAL: msg = "client marshalling"; break;
|
|
|
|
|
case RXGEN_CC_UNMARSHAL: msg = "client unmarshalling"; break;
|
|
|
|
|
case RXGEN_SS_MARSHAL: msg = "server marshalling"; break;
|
|
|
|
|
case RXGEN_SS_UNMARSHAL: msg = "server unmarshalling"; break;
|
|
|
|
|
case RXGEN_DECODE: msg = "opcode decode"; break;
|
|
|
|
|
case RXGEN_SS_XDRFREE: msg = "server XDR cleanup"; break;
|
|
|
|
|
case RXGEN_CC_XDRFREE: msg = "client XDR cleanup"; break;
|
|
|
|
|
case -32: msg = "insufficient data"; break;
|
|
|
|
|
default:
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m = max;
|
|
|
|
|
if (m < 3) {
|
|
|
|
|
max = m + 1;
|
|
|
|
|
pr_notice("kAFS: Peer reported %s failure on %s [%pISp]\n",
|
|
|
|
|
msg, call->type->name,
|
2023-10-27 01:13:13 +08:00
|
|
|
rxrpc_kernel_remote_addr(call->peer));
|
2020-06-08 04:50:29 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/*
|
|
|
|
|
* deliver messages to a call
|
|
|
|
|
*/
|
|
|
|
|
static void afs_deliver_to_call(struct afs_call *call)
|
|
|
|
|
{
|
2017-11-02 23:27:53 +08:00
|
|
|
enum afs_call_state state;
|
2020-02-06 22:22:28 +08:00
|
|
|
size_t len;
|
2017-11-02 23:27:53 +08:00
|
|
|
u32 abort_code, remote_abort = 0;
|
2007-04-27 06:55:03 +08:00
|
|
|
int ret;
|
|
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
_enter("%s", call->type->name);
|
|
|
|
|
|
2017-11-02 23:27:53 +08:00
|
|
|
while (state = READ_ONCE(call->state),
|
|
|
|
|
state == AFS_CALL_CL_AWAIT_REPLY ||
|
|
|
|
|
state == AFS_CALL_SV_AWAIT_OP_ID ||
|
|
|
|
|
state == AFS_CALL_SV_AWAIT_REQUEST ||
|
|
|
|
|
state == AFS_CALL_SV_AWAIT_ACK
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
) {
|
2017-11-02 23:27:53 +08:00
|
|
|
if (state == AFS_CALL_SV_AWAIT_ACK) {
|
2020-02-06 22:22:28 +08:00
|
|
|
len = 0;
|
2022-09-16 08:25:47 +08:00
|
|
|
iov_iter_kvec(&call->def_iter, ITER_DEST, NULL, 0, 0);
|
2017-11-02 23:27:45 +08:00
|
|
|
ret = rxrpc_kernel_recv_data(call->net->socket,
|
2019-11-21 17:12:17 +08:00
|
|
|
call->rxcall, &call->def_iter,
|
2020-02-06 22:22:28 +08:00
|
|
|
&len, false, &remote_abort,
|
2017-10-18 18:36:39 +08:00
|
|
|
&call->service_id);
|
2019-11-21 17:12:17 +08:00
|
|
|
trace_afs_receive_data(call, &call->def_iter, false, ret);
|
2017-01-05 18:38:34 +08:00
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
if (ret == -EINPROGRESS || ret == -EAGAIN)
|
|
|
|
|
return;
|
2017-11-02 23:27:53 +08:00
|
|
|
if (ret < 0 || ret == 1) {
|
|
|
|
|
if (ret == 1)
|
|
|
|
|
ret = 0;
|
2017-11-02 23:27:51 +08:00
|
|
|
goto call_complete;
|
2017-11-02 23:27:53 +08:00
|
|
|
}
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
return;
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
ret = call->type->deliver(call);
|
2017-11-02 23:27:53 +08:00
|
|
|
state = READ_ONCE(call->state);
|
2020-04-08 23:13:20 +08:00
|
|
|
if (ret == 0 && call->unmarshalling_error)
|
|
|
|
|
ret = -EBADMSG;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
switch (ret) {
|
|
|
|
|
case 0:
|
2023-10-26 00:53:33 +08:00
|
|
|
call->responded = true;
|
2018-10-20 07:57:59 +08:00
|
|
|
afs_queue_call_work(call);
|
2018-05-10 21:12:50 +08:00
|
|
|
if (state == AFS_CALL_CL_PROC_REPLY) {
|
2020-04-30 08:03:49 +08:00
|
|
|
if (call->op)
|
2018-05-10 21:12:50 +08:00
|
|
|
set_bit(AFS_SERVER_FL_MAY_HAVE_CB,
|
2020-04-30 08:03:49 +08:00
|
|
|
&call->op->server->flags);
|
2017-11-02 23:27:51 +08:00
|
|
|
goto call_complete;
|
2018-05-10 21:12:50 +08:00
|
|
|
}
|
2017-11-02 23:27:53 +08:00
|
|
|
ASSERTCMP(state, >, AFS_CALL_CL_PROC_REPLY);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
goto done;
|
|
|
|
|
case -EINPROGRESS:
|
|
|
|
|
case -EAGAIN:
|
|
|
|
|
goto out;
|
2017-03-17 00:27:47 +08:00
|
|
|
case -ECONNABORTED:
|
2017-11-02 23:27:53 +08:00
|
|
|
ASSERTCMP(state, ==, AFS_CALL_COMPLETE);
|
2023-10-26 00:53:33 +08:00
|
|
|
call->responded = true;
|
2020-06-08 04:50:29 +08:00
|
|
|
afs_log_error(call, call->abort_code);
|
2017-11-02 23:27:53 +08:00
|
|
|
goto done;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
case -ENOTSUPP:
|
2023-10-26 00:53:33 +08:00
|
|
|
call->responded = true;
|
2017-03-17 00:27:47 +08:00
|
|
|
abort_code = RXGEN_OPCODE;
|
2017-11-02 23:27:45 +08:00
|
|
|
rxrpc_kernel_abort_call(call->net->socket, call->rxcall,
|
2022-10-07 04:45:42 +08:00
|
|
|
abort_code, ret,
|
|
|
|
|
afs_abort_op_not_supported);
|
2017-11-02 23:27:53 +08:00
|
|
|
goto local_abort;
|
2018-10-20 07:57:57 +08:00
|
|
|
case -EIO:
|
|
|
|
|
pr_err("kAFS: Call %u in bad state %u\n",
|
|
|
|
|
call->debug_id, state);
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
case -ENODATA:
|
|
|
|
|
case -EBADMSG:
|
|
|
|
|
case -EMSGSIZE:
|
2022-05-21 15:45:48 +08:00
|
|
|
case -ENOMEM:
|
|
|
|
|
case -EFAULT:
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
abort_code = RXGEN_CC_UNMARSHAL;
|
2017-11-02 23:27:53 +08:00
|
|
|
if (state != AFS_CALL_CL_AWAIT_REPLY)
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
abort_code = RXGEN_SS_UNMARSHAL;
|
2017-11-02 23:27:45 +08:00
|
|
|
rxrpc_kernel_abort_call(call->net->socket, call->rxcall,
|
2022-10-07 04:45:42 +08:00
|
|
|
abort_code, ret,
|
|
|
|
|
afs_abort_unmarshal_error);
|
2017-11-02 23:27:53 +08:00
|
|
|
goto local_abort;
|
2019-04-13 15:37:37 +08:00
|
|
|
default:
|
2022-05-21 15:45:48 +08:00
|
|
|
abort_code = RX_CALL_DEAD;
|
2019-04-13 15:37:37 +08:00
|
|
|
rxrpc_kernel_abort_call(call->net->socket, call->rxcall,
|
2022-10-07 04:45:42 +08:00
|
|
|
abort_code, ret,
|
|
|
|
|
afs_abort_general_error);
|
2019-04-13 15:37:37 +08:00
|
|
|
goto local_abort;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
}
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
done:
|
2018-10-20 07:57:59 +08:00
|
|
|
if (call->type->done)
|
|
|
|
|
call->type->done(call);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
out:
|
2007-04-27 06:55:03 +08:00
|
|
|
_leave("");
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
return;
|
|
|
|
|
|
2017-11-02 23:27:53 +08:00
|
|
|
local_abort:
|
|
|
|
|
abort_code = 0;
|
2017-11-02 23:27:51 +08:00
|
|
|
call_complete:
|
2017-11-02 23:27:53 +08:00
|
|
|
afs_set_call_complete(call, ret, remote_abort);
|
|
|
|
|
state = AFS_CALL_COMPLETE;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
goto done;
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2023-10-26 00:53:33 +08:00
|
|
|
* Wait synchronously for a call to complete.
|
2007-04-27 06:55:03 +08:00
|
|
|
*/
|
2023-10-20 23:13:03 +08:00
|
|
|
void afs_wait_for_call_to_complete(struct afs_call *call)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
2019-04-12 23:34:02 +08:00
|
|
|
bool rxrpc_complete = false;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
|
|
|
|
_enter("");
|
|
|
|
|
|
2023-10-26 16:54:07 +08:00
|
|
|
if (!afs_check_call_state(call, AFS_CALL_COMPLETE)) {
|
|
|
|
|
DECLARE_WAITQUEUE(myself, current);
|
|
|
|
|
|
|
|
|
|
add_wait_queue(&call->waitq, &myself);
|
|
|
|
|
for (;;) {
|
|
|
|
|
set_current_state(TASK_UNINTERRUPTIBLE);
|
|
|
|
|
|
|
|
|
|
/* deliver any messages that are in the queue */
|
|
|
|
|
if (!afs_check_call_state(call, AFS_CALL_COMPLETE) &&
|
|
|
|
|
call->need_attention) {
|
|
|
|
|
call->need_attention = false;
|
|
|
|
|
__set_current_state(TASK_RUNNING);
|
|
|
|
|
afs_deliver_to_call(call);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (afs_check_call_state(call, AFS_CALL_COMPLETE))
|
|
|
|
|
break;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2023-10-26 16:54:07 +08:00
|
|
|
if (!rxrpc_kernel_check_life(call->net->socket, call->rxcall)) {
|
|
|
|
|
/* rxrpc terminated the call. */
|
|
|
|
|
rxrpc_complete = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2017-10-18 18:07:31 +08:00
|
|
|
|
2023-10-26 16:54:07 +08:00
|
|
|
schedule();
|
2019-04-12 23:34:02 +08:00
|
|
|
}
|
|
|
|
|
|
2023-10-26 16:54:07 +08:00
|
|
|
remove_wait_queue(&call->waitq, &myself);
|
|
|
|
|
__set_current_state(TASK_RUNNING);
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
2017-11-02 23:27:53 +08:00
|
|
|
if (!afs_check_call_state(call, AFS_CALL_COMPLETE)) {
|
2019-04-12 23:34:02 +08:00
|
|
|
if (rxrpc_complete) {
|
|
|
|
|
afs_set_call_complete(call, call->error, call->abort_code);
|
|
|
|
|
} else {
|
|
|
|
|
/* Kill off the call if it's still live. */
|
|
|
|
|
_debug("call interrupted");
|
|
|
|
|
if (rxrpc_kernel_abort_call(call->net->socket, call->rxcall,
|
2022-10-07 04:45:42 +08:00
|
|
|
RX_USER_ABORT, -EINTR,
|
|
|
|
|
afs_abort_interrupted))
|
2019-04-12 23:34:02 +08:00
|
|
|
afs_set_call_complete(call, -EINTR, 0);
|
|
|
|
|
}
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* wake up a waiting call
|
|
|
|
|
*/
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
static void afs_wake_up_call_waiter(struct sock *sk, struct rxrpc_call *rxcall,
|
|
|
|
|
unsigned long call_user_ID)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
struct afs_call *call = (struct afs_call *)call_user_ID;
|
|
|
|
|
|
|
|
|
|
call->need_attention = true;
|
2007-04-27 06:55:03 +08:00
|
|
|
wake_up(&call->waitq);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* wake up an asynchronous call
|
|
|
|
|
*/
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
static void afs_wake_up_async_call(struct sock *sk, struct rxrpc_call *rxcall,
|
|
|
|
|
unsigned long call_user_ID)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
struct afs_call *call = (struct afs_call *)call_user_ID;
|
2022-07-06 17:52:14 +08:00
|
|
|
int r;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
|
2017-01-05 18:38:34 +08:00
|
|
|
trace_afs_notify_call(rxcall, call);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
call->need_attention = true;
|
2017-01-05 18:38:36 +08:00
|
|
|
|
2022-07-06 17:52:14 +08:00
|
|
|
if (__refcount_inc_not_zero(&call->ref, &r)) {
|
2022-07-06 18:26:14 +08:00
|
|
|
trace_afs_call(call->debug_id, afs_call_trace_wake, r + 1,
|
2017-11-02 23:27:45 +08:00
|
|
|
atomic_read(&call->net->nr_outstanding_calls),
|
2017-01-05 18:38:36 +08:00
|
|
|
__builtin_return_address(0));
|
|
|
|
|
|
|
|
|
|
if (!queue_work(afs_async_calls, &call->async_work))
|
|
|
|
|
afs_put_call(call);
|
|
|
|
|
}
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2017-01-05 18:38:36 +08:00
|
|
|
* Perform I/O processing on an asynchronous call. The work item carries a ref
|
|
|
|
|
* to the call struct that we either need to release or to pass on.
|
2007-04-27 06:55:03 +08:00
|
|
|
*/
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
static void afs_process_async_call(struct work_struct *work)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
struct afs_call *call = container_of(work, struct afs_call, async_work);
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
_enter("");
|
|
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
if (call->state < AFS_CALL_COMPLETE && call->need_attention) {
|
|
|
|
|
call->need_attention = false;
|
2007-04-27 06:55:03 +08:00
|
|
|
afs_deliver_to_call(call);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
}
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2017-01-05 18:38:36 +08:00
|
|
|
afs_put_call(call);
|
2007-04-27 06:55:03 +08:00
|
|
|
_leave("");
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-08 18:10:12 +08:00
|
|
|
static void afs_rx_attach(struct rxrpc_call *rxcall, unsigned long user_call_ID)
|
|
|
|
|
{
|
|
|
|
|
struct afs_call *call = (struct afs_call *)user_call_ID;
|
|
|
|
|
|
|
|
|
|
call->rxcall = rxcall;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Charge the incoming call preallocation.
|
|
|
|
|
*/
|
2017-11-02 23:27:45 +08:00
|
|
|
void afs_charge_preallocation(struct work_struct *work)
|
2016-09-08 18:10:12 +08:00
|
|
|
{
|
2017-11-02 23:27:45 +08:00
|
|
|
struct afs_net *net =
|
|
|
|
|
container_of(work, struct afs_net, charge_preallocation_work);
|
|
|
|
|
struct afs_call *call = net->spare_incoming_call;
|
2016-09-08 18:10:12 +08:00
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
if (!call) {
|
2017-11-02 23:27:45 +08:00
|
|
|
call = afs_alloc_call(net, &afs_RXCMxxxx, GFP_KERNEL);
|
2016-09-08 18:10:12 +08:00
|
|
|
if (!call)
|
|
|
|
|
break;
|
|
|
|
|
|
2020-03-13 21:46:08 +08:00
|
|
|
call->drop_ref = true;
|
2017-01-05 18:38:36 +08:00
|
|
|
call->async = true;
|
2017-11-02 23:27:53 +08:00
|
|
|
call->state = AFS_CALL_SV_AWAIT_OP_ID;
|
2017-01-05 18:38:36 +08:00
|
|
|
init_waitqueue_head(&call->waitq);
|
2018-10-20 07:57:56 +08:00
|
|
|
afs_extract_to_tmp(call);
|
2016-09-08 18:10:12 +08:00
|
|
|
}
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
if (rxrpc_kernel_charge_accept(net->socket,
|
2016-09-08 18:10:12 +08:00
|
|
|
afs_wake_up_async_call,
|
|
|
|
|
afs_rx_attach,
|
|
|
|
|
(unsigned long)call,
|
2018-03-28 06:03:00 +08:00
|
|
|
GFP_KERNEL,
|
|
|
|
|
call->debug_id) < 0)
|
2016-09-08 18:10:12 +08:00
|
|
|
break;
|
|
|
|
|
call = NULL;
|
|
|
|
|
}
|
2017-11-02 23:27:45 +08:00
|
|
|
net->spare_incoming_call = call;
|
2016-09-08 18:10:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Discard a preallocated call when a socket is shut down.
|
|
|
|
|
*/
|
|
|
|
|
static void afs_rx_discard_new_call(struct rxrpc_call *rxcall,
|
|
|
|
|
unsigned long user_call_ID)
|
|
|
|
|
{
|
|
|
|
|
struct afs_call *call = (struct afs_call *)user_call_ID;
|
|
|
|
|
|
|
|
|
|
call->rxcall = NULL;
|
2017-01-05 18:38:36 +08:00
|
|
|
afs_put_call(call);
|
2016-09-08 18:10:12 +08:00
|
|
|
}
|
|
|
|
|
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
/*
|
|
|
|
|
* Notification of an incoming call.
|
|
|
|
|
*/
|
2016-09-08 18:10:12 +08:00
|
|
|
static void afs_rx_new_call(struct sock *sk, struct rxrpc_call *rxcall,
|
|
|
|
|
unsigned long user_call_ID)
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
{
|
2017-11-02 23:27:45 +08:00
|
|
|
struct afs_net *net = afs_sock2net(sk);
|
|
|
|
|
|
|
|
|
|
queue_work(afs_wq, &net->charge_preallocation_work);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/*
|
rxrpc: Fix races between skb free, ACK generation and replying
Inside the kafs filesystem it is possible to occasionally have a call
processed and terminated before we've had a chance to check whether we need
to clean up the rx queue for that call because afs_send_simple_reply() ends
the call when it is done, but this is done in a workqueue item that might
happen to run to completion before afs_deliver_to_call() completes.
Further, it is possible for rxrpc_kernel_send_data() to be called to send a
reply before the last request-phase data skb is released. The rxrpc skb
destructor is where the ACK processing is done and the call state is
advanced upon release of the last skb. ACK generation is also deferred to
a work item because it's possible that the skb destructor is not called in
a context where kernel_sendmsg() can be invoked.
To this end, the following changes are made:
(1) kernel_rxrpc_data_consumed() is added. This should be called whenever
an skb is emptied so as to crank the ACK and call states. This does
not release the skb, however. kernel_rxrpc_free_skb() must now be
called to achieve that. These together replace
rxrpc_kernel_data_delivered().
(2) kernel_rxrpc_data_consumed() is wrapped by afs_data_consumed().
This makes afs_deliver_to_call() easier to work as the skb can simply
be discarded unconditionally here without trying to work out what the
return value of the ->deliver() function means.
The ->deliver() functions can, via afs_data_complete(),
afs_transfer_reply() and afs_extract_data() mark that an skb has been
consumed (thereby cranking the state) without the need to
conditionally free the skb to make sure the state is correct on an
incoming call for when the call processor tries to send the reply.
(3) rxrpc_recvmsg() now has to call kernel_rxrpc_data_consumed() when it
has finished with a packet and MSG_PEEK isn't set.
(4) rxrpc_packet_destructor() no longer calls rxrpc_hard_ACK_data().
Because of this, we no longer need to clear the destructor and put the
call before we free the skb in cases where we don't want the ACK/call
state to be cranked.
(5) The ->deliver() call-type callbacks are made to return -EAGAIN rather
than 0 if they expect more data (afs_extract_data() returns -EAGAIN to
the delivery function already), and the caller is now responsible for
producing an abort if that was the last packet.
(6) There are many bits of unmarshalling code where:
ret = afs_extract_data(call, skb, last, ...);
switch (ret) {
case 0: break;
case -EAGAIN: return 0;
default: return ret;
}
is to be found. As -EAGAIN can now be passed back to the caller, we
now just return if ret < 0:
ret = afs_extract_data(call, skb, last, ...);
if (ret < 0)
return ret;
(7) Checks for trailing data and empty final data packets has been
consolidated as afs_data_complete(). So:
if (skb->len > 0)
return -EBADMSG;
if (!last)
return 0;
becomes:
ret = afs_data_complete(call, skb, last);
if (ret < 0)
return ret;
(8) afs_transfer_reply() now checks the amount of data it has against the
amount of data desired and the amount of data in the skb and returns
an error to induce an abort if we don't get exactly what we want.
Without these changes, the following oops can occasionally be observed,
particularly if some printks are inserted into the delivery path:
general protection fault: 0000 [#1] SMP
Modules linked in: kafs(E) af_rxrpc(E) [last unloaded: af_rxrpc]
CPU: 0 PID: 1305 Comm: kworker/u8:3 Tainted: G E 4.7.0-fsdevel+ #1303
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
Workqueue: kafsd afs_async_workfn [kafs]
task: ffff88040be041c0 ti: ffff88040c070000 task.ti: ffff88040c070000
RIP: 0010:[<ffffffff8108fd3c>] [<ffffffff8108fd3c>] __lock_acquire+0xcf/0x15a1
RSP: 0018:ffff88040c073bc0 EFLAGS: 00010002
RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000000 RCX: ffff88040d29a710
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88040d29a710
RBP: ffff88040c073c70 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88040be041c0 R15: ffffffff814c928f
FS: 0000000000000000(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa4595f4750 CR3: 0000000001c14000 CR4: 00000000001406f0
Stack:
0000000000000006 000000000be04930 0000000000000000 ffff880400000000
ffff880400000000 ffffffff8108f847 ffff88040be041c0 ffffffff81050446
ffff8803fc08a920 ffff8803fc08a958 ffff88040be041c0 ffff88040c073c38
Call Trace:
[<ffffffff8108f847>] ? mark_held_locks+0x5e/0x74
[<ffffffff81050446>] ? __local_bh_enable_ip+0x9b/0xa1
[<ffffffff8108f9ca>] ? trace_hardirqs_on_caller+0x16d/0x189
[<ffffffff810915f4>] lock_acquire+0x122/0x1b6
[<ffffffff810915f4>] ? lock_acquire+0x122/0x1b6
[<ffffffff814c928f>] ? skb_dequeue+0x18/0x61
[<ffffffff81609dbf>] _raw_spin_lock_irqsave+0x35/0x49
[<ffffffff814c928f>] ? skb_dequeue+0x18/0x61
[<ffffffff814c928f>] skb_dequeue+0x18/0x61
[<ffffffffa009aa92>] afs_deliver_to_call+0x344/0x39d [kafs]
[<ffffffffa009ab37>] afs_process_async_call+0x4c/0xd5 [kafs]
[<ffffffffa0099e9c>] afs_async_workfn+0xe/0x10 [kafs]
[<ffffffff81063a3a>] process_one_work+0x29d/0x57c
[<ffffffff81064ac2>] worker_thread+0x24a/0x385
[<ffffffff81064878>] ? rescuer_thread+0x2d0/0x2d0
[<ffffffff810696f5>] kthread+0xf3/0xfb
[<ffffffff8160a6ff>] ret_from_fork+0x1f/0x40
[<ffffffff81069602>] ? kthread_create_on_node+0x1cf/0x1cf
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-03 21:11:40 +08:00
|
|
|
* Grab the operation ID from an incoming cache manager call. The socket
|
|
|
|
|
* buffer is discarded on error or if we don't yet have sufficient data.
|
2007-04-27 06:55:03 +08:00
|
|
|
*/
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
static int afs_deliver_cm_op_id(struct afs_call *call)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
int ret;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2019-11-21 17:12:17 +08:00
|
|
|
_enter("{%zu}", iov_iter_count(call->iter));
|
2007-04-27 06:55:03 +08:00
|
|
|
|
|
|
|
|
/* the operation ID forms the first four bytes of the request data */
|
2018-10-20 07:57:56 +08:00
|
|
|
ret = afs_extract_data(call, true);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2016-10-13 15:27:10 +08:00
|
|
|
call->operation_ID = ntohl(call->tmp);
|
2017-11-02 23:27:53 +08:00
|
|
|
afs_set_call_state(call, AFS_CALL_SV_AWAIT_OP_ID, AFS_CALL_SV_AWAIT_REQUEST);
|
2007-04-27 06:55:03 +08:00
|
|
|
|
|
|
|
|
/* ask the cache manager to route the call (it'll change the call type
|
|
|
|
|
* if successful) */
|
|
|
|
|
if (!afs_cm_incoming_call(call))
|
|
|
|
|
return -ENOTSUPP;
|
|
|
|
|
|
2017-01-05 18:38:34 +08:00
|
|
|
trace_afs_cb_call(call);
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/* pass responsibility for the remainer of this message off to the
|
|
|
|
|
* cache manager op */
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
return call->type->deliver(call);
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
|
|
|
|
|
2017-08-29 17:18:56 +08:00
|
|
|
/*
|
|
|
|
|
* Advance the AFS call state when an RxRPC service call ends the transmit
|
|
|
|
|
* phase.
|
|
|
|
|
*/
|
|
|
|
|
static void afs_notify_end_reply_tx(struct sock *sock,
|
|
|
|
|
struct rxrpc_call *rxcall,
|
|
|
|
|
unsigned long call_user_ID)
|
|
|
|
|
{
|
|
|
|
|
struct afs_call *call = (struct afs_call *)call_user_ID;
|
|
|
|
|
|
2017-11-02 23:27:53 +08:00
|
|
|
afs_set_call_state(call, AFS_CALL_SV_REPLYING, AFS_CALL_SV_AWAIT_ACK);
|
2017-08-29 17:18:56 +08:00
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/*
|
|
|
|
|
* send an empty reply
|
|
|
|
|
*/
|
|
|
|
|
void afs_send_empty_reply(struct afs_call *call)
|
|
|
|
|
{
|
2017-11-02 23:27:45 +08:00
|
|
|
struct afs_net *net = call->net;
|
2007-04-27 06:55:03 +08:00
|
|
|
struct msghdr msg;
|
|
|
|
|
|
|
|
|
|
_enter("");
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
rxrpc_kernel_set_tx_length(net->socket, call->rxcall, 0);
|
2017-06-07 19:40:03 +08:00
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
msg.msg_name = NULL;
|
|
|
|
|
msg.msg_namelen = 0;
|
2022-09-16 08:25:47 +08:00
|
|
|
iov_iter_kvec(&msg.msg_iter, ITER_SOURCE, NULL, 0, 0);
|
2007-04-27 06:55:03 +08:00
|
|
|
msg.msg_control = NULL;
|
|
|
|
|
msg.msg_controllen = 0;
|
|
|
|
|
msg.msg_flags = 0;
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
switch (rxrpc_kernel_send_data(net->socket, call->rxcall, &msg, 0,
|
2017-08-29 17:18:56 +08:00
|
|
|
afs_notify_end_reply_tx)) {
|
2007-04-27 06:55:03 +08:00
|
|
|
case 0:
|
|
|
|
|
_leave(" [replied]");
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
case -ENOMEM:
|
|
|
|
|
_debug("oom");
|
2017-11-02 23:27:45 +08:00
|
|
|
rxrpc_kernel_abort_call(net->socket, call->rxcall,
|
2022-10-07 04:45:42 +08:00
|
|
|
RXGEN_SS_MARSHAL, -ENOMEM,
|
|
|
|
|
afs_abort_oom);
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2007-04-27 06:55:03 +08:00
|
|
|
default:
|
|
|
|
|
_leave(" [error]");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:58:17 +08:00
|
|
|
/*
|
|
|
|
|
* send a simple reply
|
|
|
|
|
*/
|
|
|
|
|
void afs_send_simple_reply(struct afs_call *call, const void *buf, size_t len)
|
|
|
|
|
{
|
2017-11-02 23:27:45 +08:00
|
|
|
struct afs_net *net = call->net;
|
2007-04-27 06:58:17 +08:00
|
|
|
struct msghdr msg;
|
2014-11-28 10:50:31 +08:00
|
|
|
struct kvec iov[1];
|
2007-07-20 17:59:41 +08:00
|
|
|
int n;
|
2007-04-27 06:58:17 +08:00
|
|
|
|
|
|
|
|
_enter("");
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
rxrpc_kernel_set_tx_length(net->socket, call->rxcall, len);
|
2017-06-07 19:40:03 +08:00
|
|
|
|
2007-04-27 06:58:17 +08:00
|
|
|
iov[0].iov_base = (void *) buf;
|
|
|
|
|
iov[0].iov_len = len;
|
|
|
|
|
msg.msg_name = NULL;
|
|
|
|
|
msg.msg_namelen = 0;
|
2022-09-16 08:25:47 +08:00
|
|
|
iov_iter_kvec(&msg.msg_iter, ITER_SOURCE, iov, 1, len);
|
2007-04-27 06:58:17 +08:00
|
|
|
msg.msg_control = NULL;
|
|
|
|
|
msg.msg_controllen = 0;
|
|
|
|
|
msg.msg_flags = 0;
|
|
|
|
|
|
2017-11-02 23:27:45 +08:00
|
|
|
n = rxrpc_kernel_send_data(net->socket, call->rxcall, &msg, len,
|
2017-08-29 17:18:56 +08:00
|
|
|
afs_notify_end_reply_tx);
|
2007-07-20 17:59:41 +08:00
|
|
|
if (n >= 0) {
|
2014-05-21 21:48:05 +08:00
|
|
|
/* Success */
|
2007-04-27 06:58:17 +08:00
|
|
|
_leave(" [replied]");
|
|
|
|
|
return;
|
2007-07-20 17:59:41 +08:00
|
|
|
}
|
2014-05-21 21:48:05 +08:00
|
|
|
|
2007-07-20 17:59:41 +08:00
|
|
|
if (n == -ENOMEM) {
|
2007-04-27 06:58:17 +08:00
|
|
|
_debug("oom");
|
2017-11-02 23:27:45 +08:00
|
|
|
rxrpc_kernel_abort_call(net->socket, call->rxcall,
|
2022-10-07 04:45:42 +08:00
|
|
|
RXGEN_SS_MARSHAL, -ENOMEM,
|
|
|
|
|
afs_abort_oom);
|
2007-04-27 06:58:17 +08:00
|
|
|
}
|
2007-07-20 17:59:41 +08:00
|
|
|
_leave(" [error]");
|
2007-04-27 06:58:17 +08:00
|
|
|
}
|
|
|
|
|
|
2007-04-27 06:55:03 +08:00
|
|
|
/*
|
rxrpc: Fix races between skb free, ACK generation and replying
Inside the kafs filesystem it is possible to occasionally have a call
processed and terminated before we've had a chance to check whether we need
to clean up the rx queue for that call because afs_send_simple_reply() ends
the call when it is done, but this is done in a workqueue item that might
happen to run to completion before afs_deliver_to_call() completes.
Further, it is possible for rxrpc_kernel_send_data() to be called to send a
reply before the last request-phase data skb is released. The rxrpc skb
destructor is where the ACK processing is done and the call state is
advanced upon release of the last skb. ACK generation is also deferred to
a work item because it's possible that the skb destructor is not called in
a context where kernel_sendmsg() can be invoked.
To this end, the following changes are made:
(1) kernel_rxrpc_data_consumed() is added. This should be called whenever
an skb is emptied so as to crank the ACK and call states. This does
not release the skb, however. kernel_rxrpc_free_skb() must now be
called to achieve that. These together replace
rxrpc_kernel_data_delivered().
(2) kernel_rxrpc_data_consumed() is wrapped by afs_data_consumed().
This makes afs_deliver_to_call() easier to work as the skb can simply
be discarded unconditionally here without trying to work out what the
return value of the ->deliver() function means.
The ->deliver() functions can, via afs_data_complete(),
afs_transfer_reply() and afs_extract_data() mark that an skb has been
consumed (thereby cranking the state) without the need to
conditionally free the skb to make sure the state is correct on an
incoming call for when the call processor tries to send the reply.
(3) rxrpc_recvmsg() now has to call kernel_rxrpc_data_consumed() when it
has finished with a packet and MSG_PEEK isn't set.
(4) rxrpc_packet_destructor() no longer calls rxrpc_hard_ACK_data().
Because of this, we no longer need to clear the destructor and put the
call before we free the skb in cases where we don't want the ACK/call
state to be cranked.
(5) The ->deliver() call-type callbacks are made to return -EAGAIN rather
than 0 if they expect more data (afs_extract_data() returns -EAGAIN to
the delivery function already), and the caller is now responsible for
producing an abort if that was the last packet.
(6) There are many bits of unmarshalling code where:
ret = afs_extract_data(call, skb, last, ...);
switch (ret) {
case 0: break;
case -EAGAIN: return 0;
default: return ret;
}
is to be found. As -EAGAIN can now be passed back to the caller, we
now just return if ret < 0:
ret = afs_extract_data(call, skb, last, ...);
if (ret < 0)
return ret;
(7) Checks for trailing data and empty final data packets has been
consolidated as afs_data_complete(). So:
if (skb->len > 0)
return -EBADMSG;
if (!last)
return 0;
becomes:
ret = afs_data_complete(call, skb, last);
if (ret < 0)
return ret;
(8) afs_transfer_reply() now checks the amount of data it has against the
amount of data desired and the amount of data in the skb and returns
an error to induce an abort if we don't get exactly what we want.
Without these changes, the following oops can occasionally be observed,
particularly if some printks are inserted into the delivery path:
general protection fault: 0000 [#1] SMP
Modules linked in: kafs(E) af_rxrpc(E) [last unloaded: af_rxrpc]
CPU: 0 PID: 1305 Comm: kworker/u8:3 Tainted: G E 4.7.0-fsdevel+ #1303
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
Workqueue: kafsd afs_async_workfn [kafs]
task: ffff88040be041c0 ti: ffff88040c070000 task.ti: ffff88040c070000
RIP: 0010:[<ffffffff8108fd3c>] [<ffffffff8108fd3c>] __lock_acquire+0xcf/0x15a1
RSP: 0018:ffff88040c073bc0 EFLAGS: 00010002
RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000000 RCX: ffff88040d29a710
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88040d29a710
RBP: ffff88040c073c70 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88040be041c0 R15: ffffffff814c928f
FS: 0000000000000000(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa4595f4750 CR3: 0000000001c14000 CR4: 00000000001406f0
Stack:
0000000000000006 000000000be04930 0000000000000000 ffff880400000000
ffff880400000000 ffffffff8108f847 ffff88040be041c0 ffffffff81050446
ffff8803fc08a920 ffff8803fc08a958 ffff88040be041c0 ffff88040c073c38
Call Trace:
[<ffffffff8108f847>] ? mark_held_locks+0x5e/0x74
[<ffffffff81050446>] ? __local_bh_enable_ip+0x9b/0xa1
[<ffffffff8108f9ca>] ? trace_hardirqs_on_caller+0x16d/0x189
[<ffffffff810915f4>] lock_acquire+0x122/0x1b6
[<ffffffff810915f4>] ? lock_acquire+0x122/0x1b6
[<ffffffff814c928f>] ? skb_dequeue+0x18/0x61
[<ffffffff81609dbf>] _raw_spin_lock_irqsave+0x35/0x49
[<ffffffff814c928f>] ? skb_dequeue+0x18/0x61
[<ffffffff814c928f>] skb_dequeue+0x18/0x61
[<ffffffffa009aa92>] afs_deliver_to_call+0x344/0x39d [kafs]
[<ffffffffa009ab37>] afs_process_async_call+0x4c/0xd5 [kafs]
[<ffffffffa0099e9c>] afs_async_workfn+0xe/0x10 [kafs]
[<ffffffff81063a3a>] process_one_work+0x29d/0x57c
[<ffffffff81064ac2>] worker_thread+0x24a/0x385
[<ffffffff81064878>] ? rescuer_thread+0x2d0/0x2d0
[<ffffffff810696f5>] kthread+0xf3/0xfb
[<ffffffff8160a6ff>] ret_from_fork+0x1f/0x40
[<ffffffff81069602>] ? kthread_create_on_node+0x1cf/0x1cf
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-03 21:11:40 +08:00
|
|
|
* Extract a piece of data from the received data socket buffers.
|
2007-04-27 06:55:03 +08:00
|
|
|
*/
|
2018-10-20 07:57:56 +08:00
|
|
|
int afs_extract_data(struct afs_call *call, bool want_more)
|
2007-04-27 06:55:03 +08:00
|
|
|
{
|
2017-11-02 23:27:45 +08:00
|
|
|
struct afs_net *net = call->net;
|
2019-11-21 17:12:17 +08:00
|
|
|
struct iov_iter *iter = call->iter;
|
2017-11-02 23:27:53 +08:00
|
|
|
enum afs_call_state state;
|
2018-01-02 18:02:19 +08:00
|
|
|
u32 remote_abort = 0;
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
int ret;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2020-02-06 22:22:28 +08:00
|
|
|
_enter("{%s,%zu,%zu},%d",
|
|
|
|
|
call->type->name, call->iov_len, iov_iter_count(iter), want_more);
|
2018-08-04 00:06:56 +08:00
|
|
|
|
2018-10-20 07:57:56 +08:00
|
|
|
ret = rxrpc_kernel_recv_data(net->socket, call->rxcall, iter,
|
2020-02-06 22:22:28 +08:00
|
|
|
&call->iov_len, want_more, &remote_abort,
|
2017-10-18 18:36:39 +08:00
|
|
|
&call->service_id);
|
2022-10-27 06:43:00 +08:00
|
|
|
trace_afs_receive_data(call, call->iter, want_more, ret);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
if (ret == 0 || ret == -EAGAIN)
|
|
|
|
|
return ret;
|
2007-04-27 06:55:03 +08:00
|
|
|
|
2017-11-02 23:27:53 +08:00
|
|
|
state = READ_ONCE(call->state);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
if (ret == 1) {
|
2017-11-02 23:27:53 +08:00
|
|
|
switch (state) {
|
|
|
|
|
case AFS_CALL_CL_AWAIT_REPLY:
|
|
|
|
|
afs_set_call_state(call, state, AFS_CALL_CL_PROC_REPLY);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
break;
|
2017-11-02 23:27:53 +08:00
|
|
|
case AFS_CALL_SV_AWAIT_REQUEST:
|
|
|
|
|
afs_set_call_state(call, state, AFS_CALL_SV_REPLYING);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
break;
|
2017-11-02 23:27:53 +08:00
|
|
|
case AFS_CALL_COMPLETE:
|
|
|
|
|
kdebug("prem complete %d", call->error);
|
2018-10-20 07:57:57 +08:00
|
|
|
return afs_io_error(call, afs_io_error_extract);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
|
2017-11-02 23:27:53 +08:00
|
|
|
afs_set_call_complete(call, ret, remote_abort);
|
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>
2016-08-31 03:42:14 +08:00
|
|
|
return ret;
|
2007-04-27 06:55:03 +08:00
|
|
|
}
|
2018-04-06 21:17:25 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Log protocol error production.
|
|
|
|
|
*/
|
2020-04-08 23:49:08 +08:00
|
|
|
noinline int afs_protocol_error(struct afs_call *call,
|
2018-10-20 07:57:56 +08:00
|
|
|
enum afs_eproto_cause cause)
|
2018-04-06 21:17:25 +08:00
|
|
|
{
|
2020-04-08 23:49:08 +08:00
|
|
|
trace_afs_protocol_error(call, cause);
|
2020-04-08 23:13:20 +08:00
|
|
|
if (call)
|
|
|
|
|
call->unmarshalling_error = true;
|
2020-04-08 23:49:08 +08:00
|
|
|
return -EBADMSG;
|
2018-04-06 21:17:25 +08:00
|
|
|
}
|
