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

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