summaryrefslogtreecommitdiffstats
path: root/crypto/fcrypt.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2019-11-06 17:33:32 -0800
committerDavid S. Miller <davem@davemloft.net>2019-11-06 17:33:32 -0800
commit9990a79d8fe21ba9598e8d98383552a9fea632da (patch)
treec15a43aa3ea0d35d17e7e2bcbadd19a07439bfd2 /crypto/fcrypt.c
parent17fdd7638cb687cd7f15a48545f25d738f0101e0 (diff)
parent41098af59d8d753aa8d3bb4310cc4ecb61fc82c7 (diff)
downloadlinux-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