linux-toradex.git/net/rxrpc, branch master

rxrpc: Fix return in rxrpc_recvmsg_data() for service calls

2026-10-15T09:43:02+00:00

When rxrpc_recvmsg_data() gets called on a service call that has received
all of the request, RXRPC_CALL_RECVMSG_READ_ALL has been set, and this
causes rxrpc_recvmsg_data() to jump straight out, indicating the end of the
call (ie. rxrpc_kernel_recv_data() returns 1) without waiting for the call
to be processed or the reply to be transmitted.

rxperf_deliver_to_call() also has to be altered to call
rxrpc_kernel_recv_data() to collect the final ACK on a service call as does
afs_deliver_to_call().

Fixes: d001648ec7cf ("rxrpc: Don't expose skbs to in-kernel users [ver #2]")
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260914151340.3227501-1-dhowells%40redhat.com
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Jeffrey Altman 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261006133011.531806-10-dhowells@redhat.com
Signed-off-by: Paolo Abeni

rxrpc: Fix double IRQ enablement

2026-10-15T09:43:02+00:00

rxrpc_notify_socket() explicitly disables and then re-enables IRQs, but one
of its call chains (rxrpc_input_queue_data() -> rxrpc_end_rx_phase() ->
rxrpc_call_completed() -> rxrpc_set_call_completion()) has IRQs disabled
around it.

Fix this by making rxrpc_notify_socket() use irqsave spinlocks.

Fixes: a2ea9a907260 ("rxrpc: Use irq-disabling spinlocks between app and I/O thread")
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260812110129.979970-6-dhowells@redhat.com
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org
Link: https://patch.msgid.link/20261006133011.531806-9-dhowells@redhat.com
Signed-off-by: Paolo Abeni

rxrpc: Fix sendmsg length

2026-10-15T09:43:01+00:00

rxrpc_send_data() is given two data lengths (len and msg->msg_iter.count)
and is inconsistent about how it uses them.  Fix this by using len in
preference to msg->msg_iter.count.  Also limit the amount copied to either
len or msg->msg_iter.count, whichever is smaller.

Note that, currently, all the callers have len and msg->msg_iter.count the
same and so the problem won't occur.  This is a prerequisite for another
patch that fixes the handling of encryption errors.

Fixes: 382d7974de31 ("RxRPC: Use iov_iter_count() in rxrpc_send_data() instead of the len argument")
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Jeffrey Altman 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
Link: https://patch.msgid.link/20261006133011.531806-8-dhowells@redhat.com
Signed-off-by: Paolo Abeni

rxrpc: Fix aborting in rxperf test server

2026-10-15T09:43:01+00:00

Fix rxperf_process_call() to always abort if it gets a send error rather
than only aborting on ENOMEM.

Fixes: 75bfdbf2fca3 ("rxrpc: Implement an in-kernel rxperf server for testing purposes")
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824091645.415423-1-dhowells%40redhat.com
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
Link: https://patch.msgid.link/20261006133011.531806-7-dhowells@redhat.com
Signed-off-by: Paolo Abeni

rxrpc: Fix lack of short-send handling in rxrpc_kernel_send_data()

2026-10-15T09:43:01+00:00

Fix rxrpc_kernel_send_data() to loop around if it detects a short send.
David Laight suggested doing it here rather than wrapping all the calls in
loops.  Further, remove the len argument and use the iterator count instead
and return 0 on success, not the amount copied.

Note this is also a prerequisite for changing the way rxrpc_send_data()
works to return a short send rather than an error if some data was
buffered.

Fixes: 651350d10f93 ("[AF_RXRPC]: Add an interface to the AF_RXRPC module for the AFS filesystem to use")
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824091645.415423-1-dhowells%40redhat.com
Suggested-by: David Laight 
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261006133011.531806-5-dhowells@redhat.com
Signed-off-by: Paolo Abeni

rxrpc: Fix update of call->tx_pending without holding lock

2026-10-15T09:43:01+00:00

Currently, rxrpc_send_data() updates call->tx_pending just before it
returns - but it won't be holding the call->user_mutex when it does this if
a wait was interrupted by a signal.  This would allow a parallel sendmsg()
to race.

Further, both the callers of rxrpc_send_data() call it with the lock held,
and then it returns an indication through the parameter list to say whether
it has dropped the lock or not - after which the callers both just drop the
lock if it's still held.

Fix this by:

 (1) Moving the release of call->user_mutex down into rxrpc_send_data() and
     get rid of the indicator parameter.  This makes it easier to see where
     the lock is held.

 (2) After waiting, if the attempt to reacquire the mutex is interrupted,
     just return directly there rather than going to out_unlock

 (3) Restricting the txb variable to inside the buffering loop and leaving
     ->tx_pending set until we've queued the buffer.

Note that there's a slight change in behaviour in that wait_for_space
failure now doesn't check for completion because it doesn't hold the call
user_mutex.  The caller, however, should re-issue the send and pick up any
error at a second attempt.

Fixes: b0f571ecd794 ("rxrpc: Fix locking in rxrpc's sendmsg")
Closes: https://sashiko.dev/#/patchset/20260702144919.172295-1-dhowells%40redhat.com
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261006133011.531806-4-dhowells@redhat.com
Signed-off-by: Paolo Abeni

rxrpc: Fix rxperf test rxgk key kvno to be 0

2026-10-15T09:43:01+00:00

Fix the test rxgk keys in the rxperf test server to have kvno 0 to match
other implementations.

Fixes: aa2199088a39 ("rxrpc: rxperf: Add test RxGK server keys")
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Jeffrey Altman 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
Link: https://patch.msgid.link/20261006133011.531806-3-dhowells@redhat.com
Signed-off-by: Paolo Abeni

rxrpc: Revert "rxrpc: rxperf: Fix missing decoding of terminal magic cookie"

2026-10-15T09:43:01+00:00

Revert commit c34d999ca3145d9fe858258cc3342ec493f47d2e:

    The rxperf RPCs seem to have a magic cookie at the end of the request
    that was failing to be taken account of by the unmarshalling of the
    request.  Fix the rxperf code to expect this.

Actually, this isn't true; it's just that other Rx implementations ignore
the extra data in the request and so my test programs are sending too much
data without noticeable consequence.

Fixes: c34d999ca314 ("rxrpc: rxperf: Fix missing decoding of terminal magic cookie")
Signed-off-by: David Howells 
cc: Marc Dionne 
cc: Eric Dumazet 
cc: "David S. Miller" 
cc: Jakub Kicinski 
cc: Paolo Abeni 
cc: Simon Horman 
cc: linux-afs@lists.infradead.org
Link: https://patch.msgid.link/20261006133011.531806-2-dhowells@redhat.com
Signed-off-by: Paolo Abeni

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci

This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.

Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.

Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook

rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()

2026-07-21T09:52:29+00:00

rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but
then reloads the pointer for wake_up_process().

local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so
the second load can see NULL even if the first load did not.

Take a READ_ONCE() snapshot and use it for both the NULL check and the
wake_up_process() call, as rxrpc_encap_rcv() already does.

Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE")
Signed-off-by: Xuanqiang Luo 
Reviewed-by: Simon Horman 
Link: https://patch.msgid.link/20260708093534.53486-1-xuanqiang.luo@linux.dev
Signed-off-by: Paolo Abeni