diff options
author | David S. Miller <davem@davemloft.net> | 2019-11-06 17:33:32 -0800 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2019-11-06 17:33:32 -0800 |
commit | 9990a79d8fe21ba9598e8d98383552a9fea632da (patch) | |
tree | c15a43aa3ea0d35d17e7e2bcbadd19a07439bfd2 /crypto/fcrypt.c | |
parent | 17fdd7638cb687cd7f15a48545f25d738f0101e0 (diff) | |
parent | 41098af59d8d753aa8d3bb4310cc4ecb61fc82c7 (diff) | |
download | linux-9990a79d8fe21ba9598e8d98383552a9fea632da.tar.gz linux-9990a79d8fe21ba9598e8d98383552a9fea632da.tar.bz2 linux-9990a79d8fe21ba9598e8d98383552a9fea632da.zip |
Merge branch 'net-tls-add-a-TX-lock'
Jakub Kicinski says:
====================
net/tls: add a TX lock
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.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'crypto/fcrypt.c')
0 files changed, 0 insertions, 0 deletions