diff options
| author | Jakub Kicinski <jakub.kicinski@netronome.com> | 2019-06-03 15:17:00 -0700 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2019-06-04 14:33:50 -0700 |
| commit | 87b11e0638c3dbf029a7c9020f8a779062db58fc (patch) | |
| tree | f57c4b71396f007c1e9436414595ef78912015db /Documentation/networking | |
| parent | aeb11ff0dc46be309ba000af7e608f8d3695fd6e (diff) | |
| download | linux-0-day-87b11e0638c3dbf029a7c9020f8a779062db58fc.tar.gz linux-0-day-87b11e0638c3dbf029a7c9020f8a779062db58fc.tar.xz | |
net/tls: remove false positive warning
It's possible that TCP stack will decide to retransmit a packet
right when that packet's data gets acked, especially in presence
of packet reordering. This means that packets may be in flight,
even though tls_device code has already freed their record state.
Make fill_sg_in() and in turn tls_sw_fallback() not generate a
warning in that case, and quietly proceed to drop such frames.
Make the exit path from tls_sw_fallback() drop monitor friendly,
for users to be able to troubleshoot dropped retransmissions.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/networking')
| -rw-r--r-- | Documentation/networking/tls-offload.rst | 19 |
1 files changed, 0 insertions, 19 deletions
diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst index cb85af559dff1..eb7c9b81ccf56 100644 --- a/Documentation/networking/tls-offload.rst +++ b/Documentation/networking/tls-offload.rst @@ -379,7 +379,6 @@ by the driver: but did not arrive in the expected order * ``tx_tls_drop_no_sync_data`` - number of TX packets dropped because they arrived out of order and associated record could not be found - (see also :ref:`pre_tls_data`) Notable corner cases, exceptions and additional requirements ============================================================ @@ -462,21 +461,3 @@ Redirects leak clear text In the RX direction, if segment has already been decrypted by the device and it gets redirected or mirrored - clear text will be transmitted out. - -.. _pre_tls_data: - -Transmission of pre-TLS data ----------------------------- - -User can enqueue some already encrypted and framed records before enabling -``ktls`` on the socket. Those records have to get sent as they are. This is -perfectly easy to handle in the software case - such data will be waiting -in the TCP layer, TLS ULP won't see it. In the offloaded case when pre-queued -segment reaches transmission point it appears to be out of order (before the -expected TCP sequence number) and the stack does not have a record information -associated. - -All segments without record information cannot, however, be assumed to be -pre-queued data, because a race condition exists between TCP stack queuing -a retransmission, the driver seeing the retransmission and TCP ACK arriving -for the retransmitted data. |