Commit 87b11e06 authored by Jakub Kicinski's avatar Jakub Kicinski Committed by David S. Miller

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: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent aeb11ff0
...@@ -379,7 +379,6 @@ by the driver: ...@@ -379,7 +379,6 @@ by the driver:
but did not arrive in the expected order but did not arrive in the expected order
* ``tx_tls_drop_no_sync_data`` - number of TX packets dropped because * ``tx_tls_drop_no_sync_data`` - number of TX packets dropped because
they arrived out of order and associated record could not be found 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 Notable corner cases, exceptions and additional requirements
============================================================ ============================================================
...@@ -462,21 +461,3 @@ Redirects leak clear text ...@@ -462,21 +461,3 @@ Redirects leak clear text
In the RX direction, if segment has already been decrypted by the device 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. 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.
...@@ -240,7 +240,6 @@ static int fill_sg_in(struct scatterlist *sg_in, ...@@ -240,7 +240,6 @@ static int fill_sg_in(struct scatterlist *sg_in,
record = tls_get_record(ctx, tcp_seq, rcd_sn); record = tls_get_record(ctx, tcp_seq, rcd_sn);
if (!record) { if (!record) {
spin_unlock_irqrestore(&ctx->lock, flags); spin_unlock_irqrestore(&ctx->lock, flags);
WARN(1, "Record not found for seq %u\n", tcp_seq);
return -EINVAL; return -EINVAL;
} }
...@@ -409,7 +408,10 @@ static struct sk_buff *tls_sw_fallback(struct sock *sk, struct sk_buff *skb) ...@@ -409,7 +408,10 @@ static struct sk_buff *tls_sw_fallback(struct sock *sk, struct sk_buff *skb)
put_page(sg_page(&sg_in[--resync_sgs])); put_page(sg_page(&sg_in[--resync_sgs]));
kfree(sg_in); kfree(sg_in);
free_orig: free_orig:
kfree_skb(skb); if (nskb)
consume_skb(skb);
else
kfree_skb(skb);
return nskb; return nskb;
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment