lkml.org 
[lkml]   [2022]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 5.10 092/452] rxrpc: Return an error to sendmsg if call failed
    Date
    From: David Howells <dhowells@redhat.com>

    [ Upstream commit 4ba68c5192554876bd8c3afd904e3064d2915341 ]

    If at the end of rxrpc sendmsg() or rxrpc_kernel_send_data() the call that
    was being given data was aborted remotely or otherwise failed, return an
    error rather than returning the amount of data buffered for transmission.

    The call (presumably) did not complete, so there's not much point
    continuing with it. AF_RXRPC considers it "complete" and so will be
    unwilling to do anything else with it - and won't send a notification for
    it, deeming the return from sendmsg sufficient.

    Not returning an error causes afs to incorrectly handle a StoreData
    operation that gets interrupted by a change of address due to NAT
    reconfiguration.

    This doesn't normally affect most operations since their request parameters
    tend to fit into a single UDP packet and afs_make_call() returns before the
    server responds; StoreData is different as it involves transmission of a
    lot of data.

    This can be triggered on a client by doing something like:

    dd if=/dev/zero of=/afs/example.com/foo bs=1M count=512

    at one prompt, and then changing the network address at another prompt,
    e.g.:

    ifconfig enp6s0 inet 192.168.6.2 && route add 192.168.6.1 dev enp6s0

    Tracing packets on an Auristor fileserver looks something like:

    192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001
    192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538)
    192.168.6.3 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(64538) (64538)
    192.168.6.1 -> 192.168.6.3 RX 107 ACK Idle Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001
    <ARP exchange for 192.168.6.2>
    192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0)
    192.168.6.2 -> 192.168.6.1 AFS (RX) 1482 FS Request: Unknown(0) (0)
    192.168.6.1 -> 192.168.6.2 RX 107 ACK Exceeds Window Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001
    192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 0 Call: 4 Source Port: 7000 Destination Port: 7001
    192.168.6.1 -> 192.168.6.2 RX 74 ABORT Seq: 29321 Call: 4 Source Port: 7000 Destination Port: 7001

    The Auristor fileserver logs code -453 (RXGEN_SS_UNMARSHAL), but the abort
    code received by kafs is -5 (RX_PROTOCOL_ERROR) as the rx layer sees the
    condition and generates an abort first and the unmarshal error is a
    consequence of that at the application layer.

    Reported-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: linux-afs@lists.infradead.org
    Link: http://lists.infradead.org/pipermail/linux-afs/2021-December/004810.html # v1
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    ---
    net/rxrpc/sendmsg.c | 6 ++++++
    1 file changed, 6 insertions(+)

    diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
    index d27140c836cc..aa23ba4e2566 100644
    --- a/net/rxrpc/sendmsg.c
    +++ b/net/rxrpc/sendmsg.c
    @@ -461,6 +461,12 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,

    success:
    ret = copied;
    + if (READ_ONCE(call->state) == RXRPC_CALL_COMPLETE) {
    + read_lock_bh(&call->state_lock);
    + if (call->error < 0)
    + ret = call->error;
    + read_unlock_bh(&call->state_lock);
    + }
    out:
    call->tx_pending = skb;
    _leave(" = %d", ret);
    --
    2.35.1


    \
     
     \ /
      Last update: 2022-06-07 19:29    [W:2.238 / U:0.916 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site