Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

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

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

Documentation/networking/tls-offload.rst

+0 −19
Original line number Diff line number Diff line
@@ -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.

net/tls/tls_device_fallback.c

+4 −2
Original line number Diff line number Diff line
@@ -240,7 +240,6 @@ static int fill_sg_in(struct scatterlist *sg_in, 
	record = tls_get_record(ctx, tcp_seq, rcd_sn);

	if (!record) {

		spin_unlock_irqrestore(&ctx->lock, flags);

		WARN(1, "Record not found for seq %u\n", tcp_seq);

		return -EINVAL;

	}
@@ -409,6 +408,9 @@ static struct sk_buff *tls_sw_fallback(struct sock *sk, struct sk_buff *skb) 
		put_page(sg_page(&sg_in[--resync_sgs]));

	kfree(sg_in);

free_orig:

	if (nskb)

		consume_skb(skb);

	else

		kfree_skb(skb);

	return nskb;

}