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>
This commit is contained in:
Jakub Kicinski 2019-06-03 15:17:00 -07:00 committed by David S. Miller
parent aeb11ff0dc
commit 87b11e0638
2 changed files with 4 additions and 21 deletions

View File

@ -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
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.

View File

@ -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,6 +408,9 @@ put_sg:
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:
if (nskb)
consume_skb(skb);
else
kfree_skb(skb); kfree_skb(skb);
return nskb; return nskb;
} }