Re: [PATCH net v8 00/12] rxrpc: Fix CHALLENGE packet handling

[Paolo Abeni <pabeni@redhat.com>]

On 8/24/26 11:16 AM, David Howells wrote:
> Here's a fix for AF_RXRPC's CHALLENGE packet handling, addressing an issue
> raised by Sashiko[1], plus some miscellaneous fixes found in the process of
> fixing this, plus a number of things raised by Sashiko[2-8].
> 
> Firstly, the miscellaneous patches:
> 
>  (1) Fix rxrpc_sendmsg so that it doesn't return an error if it queued the
>      last packet of a call.  After that point, the error will be returned
>      by recvmsg() and returned it twice in two different places may
>      complicate userspace cleaning up its own structures.
> 
>  (2) Fix the use of len vs msg->msg_iter.count in rxrpc_send_data().
> 
>  (3) Fix error handling in rxrpc_send_data() for if ->secure_packet()
>      returns an error.
> 
>  (4) Fix the update of call->pending in rxrpc_send_data() in paths when the
>      call lock has been dropped.
> 
>  (5) Fix double IRQ enablement in __rxrpc_notify_socket() when called
>      indirectly from rxrpc_end_rx_phase().
> 
>  (6) Fix the generation of notifications from rxrpc after call completion.
> 
> And then there are the patches to fix CHALLENGE packet overqueuing and
> simplify RESPONSE packet generation by pre-creating the RxGK application
> data up front and passing it in a user key (thereby allowing userspace to
> partake).  This is split into five patches:
> 
>  (7) Expand the abort trace enum to be larger than a signed char as the
>      number of elements will exceed 128.
> 
>  (8) Add a refcount to the user key payload.
> 
>  (9) Make the AFS filesystem generate per-server appdata keys.
> 
> (10) Pass the appdata from AFS (or userspace) to rxrpc.
> 
> (11) Change over to using the appdata key to supply the appdata.
> 
> (12) Remove all the OOB stuff.
> 
> [!] Note that this entails a significant change in the UAPI for AF_RXRPC,
> with the CMSG types and sockopt to support the OOB queuing being removed
> and replaced with a new single CMSG type that conveys the user key ID.  I
> don't think it likely anyone is using this outside of my kafs-utils
> package.
> 
> This also involves a change to the user-defined key type, making the
> payload refcounted so that it can be accessed and the length read, then a
> buffer allocated that will hold it and other data, and then the content
> copied.  The problem is that the user is perfectly at liberty to change the
> content of a user-defined key (which will RCU-replace the content of the
> key), so the length might change when we drop the RCU read lock in order to
> allocate.  This could be got around by locking the key->rwsem sharedly, but
> that might be able to deadlock part of the rxrpc protocol engine if memory
> reclaim occurs.
> 
> David
> 
> The patches can be found here also:
> 
> 	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes
It looks like  some of the comment raised by sashiko are new,
especially on patch 9/12:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260812110129.979970-1-dhowells%40redhat.com

Do you think later follow-ups (i.e. in another series) would be ok?

/P