#
9f8eeea1 |
| 28-Apr-2024 |
Yunsheng Lin <linyunsheng@huawei.com> |
rxrpc: Fix using alignmask being zero for __page_frag_alloc_align()
rxrpc_alloc_data_txbuf() may be called with data_align being zero in none_alloc_txbuf() and rxkad_alloc_txbuf(), data_align is sup
rxrpc: Fix using alignmask being zero for __page_frag_alloc_align()
rxrpc_alloc_data_txbuf() may be called with data_align being zero in none_alloc_txbuf() and rxkad_alloc_txbuf(), data_align is supposed to be an order-based alignment value, but zero is not a valid order-based alignment value, and '~(data_align - 1)' doesn't result in a valid mask-based alignment value for __page_frag_alloc_align().
Fix it by passing a valid order-based alignment value in none_alloc_txbuf() and rxkad_alloc_txbuf().
Also use page_frag_alloc_align() expecting an order-based alignment value in rxrpc_alloc_data_txbuf() to avoid doing the alignment converting operation and to catch possible invalid alignment value in the future. Remove the 'if (data_align)' checking too, as it is always true for a valid order-based alignment value.
Fixes: 6b2536462fd4 ("rxrpc: Fix use of changed alignment param to page_frag_alloc_align()") Fixes: 49489bb03a50 ("rxrpc: Do zerocopy using MSG_SPLICE_PAGES and page frags") CC: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Acked-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/20240428111640.27306-1-linyunsheng@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
49489bb0 |
| 29-Jan-2024 |
David Howells <dhowells@redhat.com> |
rxrpc: Do zerocopy using MSG_SPLICE_PAGES and page frags
Switch from keeping the transmission buffers in the rxrpc_txbuf struct and allocated from the slab, to allocating them using page fragment al
rxrpc: Do zerocopy using MSG_SPLICE_PAGES and page frags
Switch from keeping the transmission buffers in the rxrpc_txbuf struct and allocated from the slab, to allocating them using page fragment allocators (which uses raw pages), thereby allowing them to be passed to MSG_SPLICE_PAGES and avoid copying into the UDP buffers.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
show more ...
|
#
a1c9af4d |
| 30-Jan-2024 |
David Howells <dhowells@redhat.com> |
rxrpc: Don't pick values out of the wire header when setting up security
Don't pick values out of the wire header in rxkad when setting up DATA packet security, but rather use other sources. This m
rxrpc: Don't pick values out of the wire header when setting up security
Don't pick values out of the wire header in rxkad when setting up DATA packet security, but rather use other sources. This makes it easier to get rid of txb->wire.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
show more ...
|
#
d3263698 |
| 29-Jan-2024 |
David Howells <dhowells@redhat.com> |
rxrpc: Do lazy DF flag resetting
Don't reset the DF flag after transmission, but rather set it when needed since it should be a fast op now that we call IP directly.
This includes turning it off fo
rxrpc: Do lazy DF flag resetting
Don't reset the DF flag after transmission, but rather set it when needed since it should be a fast op now that we call IP directly.
This includes turning it off for RESPONSE packets and, for the moment, ACK packets. In future, we will need to turn it on for ACK packets used to do path MTU discovery.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
show more ...
|
#
41b8debb |
| 29-Jan-2024 |
David Howells <dhowells@redhat.com> |
rxrpc: Note cksum in txbuf
Add a field to rxrpc_txbuf in which to store the checksum to go in the header as this may get overwritten in the wire header struct when transmitting as part of a jumbo pa
rxrpc: Note cksum in txbuf
Add a field to rxrpc_txbuf in which to store the checksum to go in the header as this may get overwritten in the wire header struct when transmitting as part of a jumbo packet.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
show more ...
|
#
f3104141 |
| 02-Feb-2024 |
David Howells <dhowells@redhat.com> |
rxrpc: Fix generation of serial numbers to skip zero
In the Rx protocol, every packet generated is marked with a per-connection monotonically increasing serial number. This number can be referenced
rxrpc: Fix generation of serial numbers to skip zero
In the Rx protocol, every packet generated is marked with a per-connection monotonically increasing serial number. This number can be referenced in an ACK packet generated in response to an incoming packet - thereby allowing the sender to use this for RTT determination, amongst other things.
However, if the reference field in the ACK is zero, it doesn't refer to any incoming packet (it could be a ping to find out if a packet got lost, for example) - so we shouldn't generate zero serial numbers.
Fix the generation of serial numbers to retry if it comes up with a zero.
Furthermore, since the serial numbers are only ever allocated within the I/O thread this connection is bound to, there's no need for atomics so remove that too.
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: "David S. Miller" <davem@davemloft.net> cc: Eric Dumazet <edumazet@google.com> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
87220143 |
| 09-Jan-2024 |
David Howells <dhowells@redhat.com> |
rxrpc: Fix use of Don't Fragment flag
rxrpc normally has the Don't Fragment flag set on the UDP packets it transmits, except when it has decided that DATA packets aren't getting through - in which c
rxrpc: Fix use of Don't Fragment flag
rxrpc normally has the Don't Fragment flag set on the UDP packets it transmits, except when it has decided that DATA packets aren't getting through - in which case it turns it off just for the DATA transmissions. This can be a problem, however, for RESPONSE packets that convey authentication and crypto data from the client to the server as ticket may be larger than can fit in the MTU.
In such a case, rxrpc gets itself into an infinite loop as the sendmsg returns an error (EMSGSIZE), which causes rxkad_send_response() to return -EAGAIN - and the CHALLENGE packet is put back on the Rx queue to retry, leading to the I/O thread endlessly attempting to perform the transmission.
Fix this by disabling DF on RESPONSE packets for now. The use of DF and best data MTU determination needs reconsidering at some point in the future.
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: linux-afs@lists.infradead.org Acked-by: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/1581852.1704813048@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
9d35d880 |
| 19-Oct-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Move client call connection to the I/O thread
Move the connection setup of client calls to the I/O thread so that a whole load of locking and barrierage can be eliminated. This necessitates
rxrpc: Move client call connection to the I/O thread
Move the connection setup of client calls to the I/O thread so that a whole load of locking and barrierage can be eliminated. This necessitates the app thread waiting for connection to complete before it can begin encrypting data.
This also completes the fix for a race that exists between call connection and call disconnection whereby the data transmission code adds the call to the peer error distribution list after the call has been disconnected (say by the rxrpc socket getting closed).
The fix is to complete the process of moving call connection, data transmission and call disconnection into the I/O thread and thus forcibly serialising them.
Note that the issue may predate the overhaul to an I/O thread model that were included in the merge window for v6.2, but the timing is very much changed by the change given below.
Fixes: cf37b5987508 ("rxrpc: Move DATA transmission into call processor work item") Reported-by: syzbot+c22650d2844392afdcfd@syzkaller.appspotmail.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
96b4059f |
| 27-Oct-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Remove call->state_lock
All the setters of call->state are now in the I/O thread and thus the state lock is now unnecessary.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionn
rxrpc: Remove call->state_lock
All the setters of call->state are now in the I/O thread and thus the state lock is now unnecessary.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
57af281e |
| 06-Oct-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Tidy up abort generation infrastructure
Tidy up the abort generation infrastructure in the following ways:
(1) Create an enum and string mapping table to list the reasons an abort migh
rxrpc: Tidy up abort generation infrastructure
Tidy up the abort generation infrastructure in the following ways:
(1) Create an enum and string mapping table to list the reasons an abort might be generated in tracing.
(2) Replace the 3-char string with the values from (1) in the places that use that to log the abort source. This gets rid of a memcpy() in the tracepoint.
(3) Subsume the rxrpc_rx_eproto tracepoint with the rxrpc_abort tracepoint and use values from (1) to indicate the trace reason.
(4) Always make a call to an abort function at the point of the abort rather than stashing the values into variables and using goto to get to a place where it reported. The C optimiser will collapse the calls together as appropriate. The abort functions return a value that can be returned directly if appropriate.
Note that this extends into afs also at the points where that generates an abort. To aid with this, the afs sources need to #define RXRPC_TRACE_ONLY_DEFINE_ENUMS before including the rxrpc tracing header because they don't have access to the rxrpc internal structures that some of the tracepoints make use of.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
a00ce28b |
| 20-Oct-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Clean up connection abort
Clean up connection abort, using the connection state_lock to gate access to change that state, and use an rxrpc_call_completion value to indicate the difference bet
rxrpc: Clean up connection abort
Clean up connection abort, using the connection state_lock to gate access to change that state, and use an rxrpc_call_completion value to indicate the difference between local and remote aborts as these can be pasted directly into the call state.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
2cc80086 |
| 19-Oct-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Drop rxrpc_conn_parameters from rxrpc_connection and rxrpc_bundle
Remove the rxrpc_conn_parameters struct from the rxrpc_connection and rxrpc_bundle structs and emplace the members directly.
rxrpc: Drop rxrpc_conn_parameters from rxrpc_connection and rxrpc_bundle
Remove the rxrpc_conn_parameters struct from the rxrpc_connection and rxrpc_bundle structs and emplace the members directly. These are going to get filled in from the rxrpc_call struct in future.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
2ebdb26e |
| 20-Oct-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Remove the [k_]proto() debugging macros
Remove the kproto() and _proto() debugging macros in preference to using tracepoints for this.
Signed-off-by: David Howells <dhowells@redhat.com> cc:
rxrpc: Remove the [k_]proto() debugging macros
Remove the kproto() and _proto() debugging macros in preference to using tracepoints for this.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
101c1bb6 |
| 17-Nov-2022 |
Dan Carpenter <error27@gmail.com> |
rxrpc: fix rxkad_verify_response()
The error handling for if skb_copy_bits() fails was accidentally deleted so the rxkad_decrypt_ticket() function is not called.
Fixes: 5d7edbc9231e ("rxrpc: Get ri
rxrpc: fix rxkad_verify_response()
The error handling for if skb_copy_bits() fails was accidentally deleted so the rxkad_decrypt_ticket() function is not called.
Fixes: 5d7edbc9231e ("rxrpc: Get rid of the Rx ring") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
30d95efe |
| 04-Nov-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Allocate an skcipher each time needed rather than reusing
In the rxkad security class, allocate the skcipher used to do packet encryption and decription rather than allocating one up front an
rxrpc: Allocate an skcipher each time needed rather than reusing
In the rxkad security class, allocate the skcipher used to do packet encryption and decription rather than allocating one up front and reusing it for each packet. Reusing the skcipher precludes doing crypto in parallel.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
a4ea4c47 |
| 31-Mar-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Don't use a ring buffer for call Tx queue
Change the way the Tx queueing works to make the following ends easier to achieve:
(1) The filling of packets, the encryption of packets and the tr
rxrpc: Don't use a ring buffer for call Tx queue
Change the way the Tx queueing works to make the following ends easier to achieve:
(1) The filling of packets, the encryption of packets and the transmission of packets can be handled in parallel by separate threads, rather than rxrpc_sendmsg() allocating, filling, encrypting and transmitting each packet before moving onto the next one.
(2) Get rid of the fixed-size ring which sets a hard limit on the number of packets that can be retained in the ring. This allows the number of packets to increase without having to allocate a very large ring or having variable-sized rings.
[Note: the downside of this is that it's then less efficient to locate a packet for retransmission as we then have to step through a list and examine each buffer in the list.]
(3) Allow the filler/encrypter to run ahead of the transmission window.
(4) Make it easier to do zero copy UDP from the packet buffers.
(5) Make it easier to do zero copy from userspace to the packet buffers - and thence to UDP (only if for unauthenticated connections).
To that end, the following changes are made:
(1) Use the new rxrpc_txbuf struct instead of sk_buff for keeping packets to be transmitted in. This allows them to be placed on multiple queues simultaneously. An sk_buff isn't really necessary as it's never passed on to lower-level networking code.
(2) Keep the transmissable packets in a linked list on the call struct rather than in a ring. As a consequence, the annotation buffer isn't used either; rather a flag is set on the packet to indicate ackedness.
(3) Use the RXRPC_CALL_TX_LAST flag to indicate that the last packet to be transmitted has been queued. Add RXRPC_CALL_TX_ALL_ACKED to indicate that all packets up to and including the last got hard acked.
(4) Wire headers are now stored in the txbuf rather than being concocted on the stack and they're stored immediately before the data, thereby allowing zerocopy of a single span.
(5) Don't bother with instant-resend on transmission failure; rather, leave it for a timer or an ACK packet to trigger.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
5d7edbc9 |
| 27-Aug-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Get rid of the Rx ring
Get rid of the Rx ring and replace it with a pair of queues instead. One queue gets the packets that are in-sequence and are ready for processing by recvmsg(); the oth
rxrpc: Get rid of the Rx ring
Get rid of the Rx ring and replace it with a pair of queues instead. One queue gets the packets that are in-sequence and are ready for processing by recvmsg(); the other queue gets the out-of-sequence packets for addition to the first queue as the holes get filled.
The annotation ring is removed and replaced with a SACK table. The SACK table has the bits set that correspond exactly to the sequence number of the packet being acked. The SACK ring is copied when an ACK packet is being assembled and rotated so that the first ACK is in byte 0.
Flow control handling is altered so that packets that are moved to the in-sequence queue are hard-ACK'd even before they're consumed - and then the Rx window size in the ACK packet (rsize) is shrunk down to compensate (even going to 0 if the window is full).
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
d4d02d8b |
| 07-Oct-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Clone received jumbo subpackets and queue separately
Split up received jumbo packets into separate skbuffs by cloning the original skbuff for each subpacket and setting the offset and length
rxrpc: Clone received jumbo subpackets and queue separately
Split up received jumbo packets into separate skbuffs by cloning the original skbuff for each subpacket and setting the offset and length of the data in that subpacket in the skbuff's private data. The subpackets are then placed on the recvmsg queue separately. The security class then gets to revise the offset and length to remove its metadata.
If we fail to clone a packet, we just drop it and let the peer resend it. The original packet gets used for the final subpacket.
This should make it easier to handle parallel decryption of the subpackets. It also simplifies the handling of lost or misordered packets in the queuing/buffering loop as the possibility of overlapping jumbo packets no longer needs to be considered.
Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
0d40f728 |
| 24-Aug-2022 |
David Howells <dhowells@redhat.com> |
rxrpc: Fix an insufficiently large sglist in rxkad_verify_packet_2()
rxkad_verify_packet_2() has a small stack-allocated sglist of 4 elements, but if that isn't sufficient for the number of fragment
rxrpc: Fix an insufficiently large sglist in rxkad_verify_packet_2()
rxkad_verify_packet_2() has a small stack-allocated sglist of 4 elements, but if that isn't sufficient for the number of fragments in the socket buffer, we try to allocate an sglist large enough to hold all the fragments.
However, for large packets with a lot of fragments, this isn't sufficient and we need at least one additional fragment.
The problem manifests as skb_to_sgvec() returning -EMSGSIZE and this then getting returned by userspace. Most of the time, this isn't a problem as rxrpc sets a limit of 5692, big enough for 4 jumbo subpackets to be glued together; occasionally, however, the server will ignore the reported limit and give a packet that's a lot bigger - say 19852 bytes with ->nr_frags being 7. skb_to_sgvec() then tries to return a "zeroth" fragment that seems to occur before the fragments counted by ->nr_frags and we hit the end of the sglist too early.
Note that __skb_to_sgvec() also has an skb_walk_frags() loop that is recursive up to 24 deep. I'm not sure if I need to take account of that too - or if there's an easy way of counting those frags too.
Fix this by counting an extra frag and allocating a larger sglist based on that.
Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: linux-afs@lists.infradead.org
show more ...
|
#
5b47d236 |
| 07-Jul-2022 |
Justin Stitt <justinstitt@google.com> |
net: rxrpc: fix clang -Wformat warning
When building with Clang we encounter this warning: | net/rxrpc/rxkad.c:434:33: error: format specifies type 'unsigned short' | but the argument has type 'u32'
net: rxrpc: fix clang -Wformat warning
When building with Clang we encounter this warning: | net/rxrpc/rxkad.c:434:33: error: format specifies type 'unsigned short' | but the argument has type 'u32' (aka 'unsigned int') [-Werror,-Wformat] | _leave(" = %d [set %hx]", ret, y);
y is a u32 but the format specifier is `%hx`. Going from unsigned int to short int results in a loss of data. This is surely not intended behavior. If it is intended, the warning should be suppressed through other means.
This patch should get us closer to the goal of enabling the -Wformat flag for Clang builds.
Link: https://github.com/ClangBuiltLinux/linux/issues/378 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/20220707182052.769989-1-justinstitt@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
6c375d79 |
| 26-Apr-2021 |
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> |
rxrpc: rxkad: Remove redundant variable offset
Variable offset is being assigned a value from a calculation however the variable is never read, so this redundant variable can be removed.
Cleans up
rxrpc: rxkad: Remove redundant variable offset
Variable offset is being assigned a value from a calculation however the variable is never read, so this redundant variable can be removed.
Cleans up the following clang-analyzer warning:
net/rxrpc/rxkad.c:579:2: warning: Value stored to 'offset' is never read [clang-analyzer-deadcode.DeadStores].
net/rxrpc/rxkad.c:485:2: warning: Value stored to 'offset' is never read [clang-analyzer-deadcode.DeadStores].
Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d7d775b1 |
| 16-Sep-2020 |
David Howells <dhowells@redhat.com> |
rxrpc: Ask the security class how much space to allow in a packet
Ask the security class how much header and trailer space to allow for when allocating a packet, given how much data is remaining.
T
rxrpc: Ask the security class how much space to allow in a packet
Ask the security class how much header and trailer space to allow for when allocating a packet, given how much data is remaining.
This will allow the rxgk security class to stick both a trailer in as well as a header as appropriate in the future.
Signed-off-by: David Howells <dhowells@redhat.com>
show more ...
|
#
ceff522d |
| 29-Sep-2020 |
David Howells <dhowells@redhat.com> |
rxrpc: rxkad: Don't use pskb_pull() to advance through the response packet
In the rxkad security class, don't use pskb_pull() to advance through the contents of the response packet. There's no poin
rxrpc: rxkad: Don't use pskb_pull() to advance through the response packet
In the rxkad security class, don't use pskb_pull() to advance through the contents of the response packet. There's no point, especially as the next and last access to the skbuff still has to allow for the wire header in the offset (which we didn't advance over).
Better to just add the displacement to the next offset.
Signed-off-by: David Howells <dhowells@redhat.com>
show more ...
|
#
521bb304 |
| 22-Sep-2020 |
David Howells <dhowells@redhat.com> |
rxrpc: Organise connection security to use a union
Organise the security information in the rxrpc_connection struct to use a union to allow for different data for different security classes.
Signed
rxrpc: Organise connection security to use a union
Organise the security information in the rxrpc_connection struct to use a union to allow for different data for different security classes.
Signed-off-by: David Howells <dhowells@redhat.com>
show more ...
|
#
f4bdf3d6 |
| 17-Sep-2020 |
David Howells <dhowells@redhat.com> |
rxrpc: Don't reserve security header in Tx DATA skbuff
Insert the security header into the skbuff representing a DATA packet to be transmitted rather than using skb_reserve() when the packet is allo
rxrpc: Don't reserve security header in Tx DATA skbuff
Insert the security header into the skbuff representing a DATA packet to be transmitted rather than using skb_reserve() when the packet is allocated. This makes it easier to apply crypto that spans the security header and the data, particularly in the upcoming RxGK class where we have a common encrypt-and-checksum function that is used in a number of circumstances.
Signed-off-by: David Howells <dhowells@redhat.com>
show more ...
|