summaryrefslogtreecommitdiff
path: root/include/linux/workqueue_api.h
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2026-06-09 06:10:23 +0300
committerJakub Kicinski <kuba@kernel.org>2026-06-09 06:10:23 +0300
commit67ad35a58a88c360136d893cbc4c7f5b14100bb9 (patch)
treebd3780c8728b06d14e7c1473df836f5a958848a6 /include/linux/workqueue_api.h
parent69710a37bad62afc3d2f1fbf7b108e5f8b3808cd (diff)
parentedcf32b8a48f5882b5b7a91b21c89d233d4aecf2 (diff)
downloadlinux-67ad35a58a88c360136d893cbc4c7f5b14100bb9.tar.xz
Merge branch 'tls-receive-path-fixes-and-clean-ups'
Chuck Lever says: ==================== tls: receive-path fixes and clean-ups I'd like to encourage in-kernel kTLS consumers (NFSD, NVMe/TCP) to coalesce on the use of read_sock. While auditing read_sock for that purpose, Hannes and Sabrina flagged a few rough edges in the receive paths. This series is a set of clean-ups, not a performance series. Async batch decryption and its submit/deliver scaffolding were dropped during previous review: async_capable is always false for TLS 1.3, the version NFSD and NVMe/TCP both require, so async-related improvements were unreachable for the in-kernel consumers this work targets. A subsequent series will introduce infrastructure to support KeyUpdate for in-kernel kTLS consumers, which need to handle TLS Alert messages that trigger a tlshd upcall. ==================== Link: https://patch.msgid.link/20260604-tls-read-sock-v12-0-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include/linux/workqueue_api.h')
0 files changed, 0 insertions, 0 deletions