diff options
| author | Paolo Abeni <pabeni@redhat.com> | 2026-08-11 15:39:02 +0200 |
|---|---|---|
| committer | Paolo Abeni <pabeni@redhat.com> | 2026-08-11 15:39:02 +0200 |
| commit | 71b3ced5047a94c2776e796fe79c387ad9c31d5a (patch) | |
| tree | 0fd46ea753d432a7eb993fda696f9c69a0915459 /tools/perf/scripts/python/bin | |
| parent | 5f3a13e0bb5ebcc1ca2dfda42ea40b9f3c2be6ea (diff) | |
| parent | 8a422297391328b8128e5f6b7e1c49b0240ffa82 (diff) | |
Merge branch 'net-tls-fail-splice-after-a-failed-async-decrypt'
Chuck Lever says:
====================
net/tls: Fail splice after a failed async decrypt
tls_sw_recvmsg() and tls_sw_read_sock() both read ctx->async_wait.err
once they hold the reader lock, so a record that failed
authentication fails the call. tls_sw_splice_read() has no such
check. sk_err does not stand in for one. The first reader to reach
sock_error() clears sk_err, while async_wait.err persists. A splice
therefore keeps delivering records on a connection the other two
readers have already refused.
Both patches come from a receive-path series for zero-length data
records. Jakub asked for them separately, since the rest of that
series is still under discussion.
Link to the original series:
https://patch.msgid.link/20260726-tls-follow-on-v1-0-99bf4cc1c729@kernel.org
====================
Link: https://patch.msgid.link/20260806-tls-splice-crypto-fix-v1-0-a2624005a286@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
