kernel/linux.git/net/rxrpc/Makefile, branch v6.19.12

rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)

2025-04-15T00:36:42+00:00

Implement the basic parts of the yfs-rxgk security class (security index 6) to support GSSAPI-negotiated security. Signed-off-by: David Howells cc: Marc Dionne cc: Herbert Xu cc: Chuck Lever cc: Simon Horman cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/20250411095303.2316168-9-dhowells@redhat.com Signed-off-by: Jakub Kicinski

rxrpc: rxgk: Provide infrastructure and key derivation

2025-04-15T00:36:41+00:00

Provide some infrastructure for implementing the RxGK transport security class: (1) A definition of an encoding type, including: - Relevant crypto-layer names - Lengths of the crypto keys and checksums involved - Crypto functions specific to the encoding type - Crypto scheme used for that type (2) A definition of a crypto scheme, including: - Underlying crypto handlers - The pseudo-random function, PRF, used in base key derivation - Functions for deriving usage keys Kc, Ke and Ki - Functions for en/decrypting parts of an sk_buff (3) A key context, with the usage keys required for a derivative of a transport key for a specific key number. This includes keys for securing packets for transmission, extracting received packets and dealing with response packets. (3) A function to look up an encoding type by number. (4) A function to set up a key context and derive the keys. (5) A function to set up the keys required to extract the ticket obtained from the GSS negotiation in the server. (6) Miscellaneous functions for context handling. The keys and key derivation functions are described in: tools.ietf.org/html/draft-wilkinson-afs3-rxgk-11 Signed-off-by: David Howells cc: Marc Dionne cc: Herbert Xu cc: Chuck Lever cc: Simon Horman cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/20250411095303.2316168-8-dhowells@redhat.com Signed-off-by: Jakub Kicinski

rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE

2025-04-15T00:36:41+00:00

Allow the app to request that CHALLENGEs be passed to it through an out-of-band queue that allows recvmsg() to pick it up so that the app can add data to it with sendmsg(). This will allow the application (AFS or userspace) to interact with the process if it wants to and put values into user-defined fields. This will be used by AFS when talking to a fileserver to supply that fileserver with a crypto key by which callback RPCs can be encrypted (ie. notifications from the fileserver to the client). Signed-off-by: David Howells cc: Marc Dionne cc: Simon Horman cc: linux-afs@lists.infradead.org Link: https://patch.msgid.link/20250411095303.2316168-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski

rxrpc: Implement RACK/TLP to deal with transmission stalls [RFC8985]

2024-12-09T21:48:33+00:00

When an rxrpc call is in its transmission phase and is sending a lot of packets, stalls occasionally occur that cause severe performance degradation (eg. increasing the transmission time for a 256MiB payload from 0.7s to 2.5s over a 10G link). rxrpc already implements TCP-style congestion control [RFC5681] and this helps mitigate the effects, but occasionally we're missing a time event that deals with a missing ACK, leading to a stall until the RTO expires. Fix this by implementing RACK/TLP in rxrpc. Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Jakub Kicinski

rxrpc: Split out the call state changing functions into their own file

2023-01-06T09:43:32+00:00

Split out the functions that change the state of an rxrpc call into their own file. The idea being to remove anything to do with changing the state of a call directly from the rxrpc sendmsg() and recvmsg() paths and have all that done in the I/O thread only, with the ultimate aim of removing the state lock entirely. Moving the code out of sendmsg.c and recvmsg.c makes that easier to manage. Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org

rxrpc: Split the receive code

2022-12-01T13:36:40+00:00

Split the code that handles packet reception in softirq mode as a prelude to moving all the packet processing beyond routing to the appropriate call and setting up of a new call out into process context. Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org

rxrpc: Implement an in-kernel rxperf server for testing purposes

2022-12-01T13:36:37+00:00

Implement an in-kernel rxperf server to allow kernel-based rxrpc services to be tested directly, unlike with AFS where they're accessed by the fileserver when the latter decides it wants to. This is implemented as a module that, if loaded, opens UDP port 7009 (afs3-rmtsys) and listens on it for incoming calls. Calls can be generated using the rxperf command shipped with OpenAFS, for example. Changes ======= ver #2) - Use min_t() instead of min(). Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: Jakub Kicinski

rxrpc: Define rxrpc_txbuf struct to carry data to be transmitted

2022-11-08T16:42:28+00:00

Define a struct, rxrpc_txbuf, to carry data to be transmitted instead of a socket buffer so that it can be placed onto multiple queues at once. This also allows the data buffer to be in the same allocation as the internal data. Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org

rxrpc: Split the server key type (rxrpc_s) into its own file

2020-11-23T18:09:29+00:00

Split the server private key type (rxrpc_s) out into its own file rather than mingling it with the authentication/client key type (rxrpc) since they don't really bear any relation. Signed-off-by: David Howells

rxrpc: Fix the excessive initial retransmission timeout

2020-05-11T15:42:28+00:00

rxrpc currently uses a fixed 4s retransmission timeout until the RTT is sufficiently sampled. This can cause problems with some fileservers with calls to the cache manager in the afs filesystem being dropped from the fileserver because a packet goes missing and the retransmission timeout is greater than the call expiry timeout. Fix this by: (1) Copying the RTT/RTO calculation code from Linux's TCP implementation and altering it to fit rxrpc. (2) Altering the various users of the RTT to make use of the new SRTT value. (3) Replacing the use of rxrpc_resend_timeout to use the calculated RTO value instead (which is needed in jiffies), along with a backoff. Notes: (1) rxrpc provides RTT samples by matching the serial numbers on outgoing DATA packets that have the RXRPC_REQUEST_ACK set and PING ACK packets against the reference serial number in incoming REQUESTED ACK and PING-RESPONSE ACK packets. (2) Each packet that is transmitted on an rxrpc connection gets a new per-connection serial number, even for retransmissions, so an ACK can be cross-referenced to a specific trigger packet. This allows RTT information to be drawn from retransmitted DATA packets also. (3) rxrpc maintains the RTT/RTO state on the rxrpc_peer record rather than on an rxrpc_call because many RPC calls won't live long enough to generate more than one sample. (4) The calculated SRTT value is in units of 8ths of a microsecond rather than nanoseconds. The (S)RTT and RTO values are displayed in /proc/net/rxrpc/peers. Fixes: 17926a79320a ([AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both"") Signed-off-by: David Howells