[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191105222436.27359-1-jakub.kicinski@netronome.com>
Date: Tue, 5 Nov 2019 14:24:33 -0800
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: davem@...emloft.net
Cc: netdev@...r.kernel.org, oss-drivers@...ronome.com,
borisp@...lanox.com, aviadye@...lanox.com,
john.fastabend@...il.com, daniel@...earbox.net,
Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: [PATCH net 0/3] net/tls: add a TX lock
Hi!
Some time ago Pooja and Mallesham started reporting crashes with
an async accelerator. After trying to poke the existing logic into
shape I came to the conclusion that it can't be trusted, and to
preserve our sanity we should just add a lock around the TX side.
First patch removes the sk_write_pending checks from the write
space callbacks. Those don't seem to have a logical justification.
Patch 2 adds the TX lock and patch 3 associated test (which should
hang with current net).
Mallesham reports that even with these fixes applied the async
accelerator workload still occasionally hangs waiting for socket
memory. I suspect that's strictly related to the way async crypto
is integrated in TLS, so I think we should get these into net or
net-next and move from there.
Jakub Kicinski (3):
net/tls: don't pay attention to sk_write_pending when pushing partial
records
net/tls: add a TX lock
selftests/tls: add test for concurrent recv and send
include/net/tls.h | 5 ++
net/tls/tls_device.c | 10 ++-
net/tls/tls_main.c | 2 +
net/tls/tls_sw.c | 30 +++------
tools/testing/selftests/net/tls.c | 108 ++++++++++++++++++++++++++++++
5 files changed, 134 insertions(+), 21 deletions(-)
--
2.23.0
Powered by blists - more mailing lists