diff options
| author | Jakub Kicinski <kuba@kernel.org> | 2026-06-09 06:10:23 +0300 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-06-09 06:10:23 +0300 |
| commit | 67ad35a58a88c360136d893cbc4c7f5b14100bb9 (patch) | |
| tree | bd3780c8728b06d14e7c1473df836f5a958848a6 /include/linux/stacktrace.h | |
| parent | 69710a37bad62afc3d2f1fbf7b108e5f8b3808cd (diff) | |
| parent | edcf32b8a48f5882b5b7a91b21c89d233d4aecf2 (diff) | |
| download | linux-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/stacktrace.h')
0 files changed, 0 insertions, 0 deletions
