Re: [PATCH net 2/3] rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg

[David Howells <dhowells@redhat.com>]

David Howells <dhowells@redhat.com> wrote:

> > > + kfree(call->rx_dec_buffer);
> > 
> > It might be better to avoid deallocating the buffer on the error
> > path and permit it to be freed during normal call (or call channel)
> > deallocation.
> 
> Hmmm.  But I then need some other way to note that the buffer is no longer
> occupied by valid data.  I suppose I could set ->rx_dec_offset to USHRT_MAX.

Actually, I'm not sure that just freeing the buffer is all that bad.

If skb_copy_bits() fails (ie. EFAULT), then the sk_buff is unrecoverably
broken somehow and the app will may have to abandon the call.  Possibly the
call should be aborted directly here.  The case really shouldn't happen and
probably merits a pr_warn().

If ->verify_packet() fails with ENOMEM, then it's retryable.  Releasing the
buffer temporarily might help the system.

If ->verify_packet() fails with anything else, then the call should have been
aborted.

David