From: Jakub Kicinski <kuba@kernel.org>
To: rjethwani@purestorage.com
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, saeedm@nvidia.com, tariqt@nvidia.com,
mbloch@nvidia.com, borisp@nvidia.com, john.fastabend@gmail.com,
sd@queasysnail.net, davem@davemloft.net, pabeni@redhat.com,
edumazet@google.com, leon@kernel.org,
andrew.gospodarek@broadcom.com
Subject: Re: [PATCH v16 06/10] tls: prep helpers and refactors for HW offload KeyUpdate
Date: Mon, 17 Aug 2026 15:11:42 -0700 [thread overview]
Message-ID: <20260817221142.3666425-1-kuba@kernel.org> (raw)
In-Reply-To: <20260807183853.2288959-7-rjethwani@purestorage.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
tls: prep helpers and refactors for HW offload KeyUpdate
This patch hoists cipher_context / tls_crypto_context above
tls_offload_context_tx, adds a tls_tx_cipher_ctx() accessor plus a
tls_sw_ctx_tx_init() helper, splits tls_set_device_offload() and factors out
tls_device_dev_add_tx() / tls_device_commit_start_marker(), and moves
crypto_aead_setauthsize() into the !*aead block. It is described as no
functional change.
No Link: tags present in the commit header.
> diff --git a/include/net/tls.h b/include/net/tls.h
> index e57bef58851e..eb258bcd62bc 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
[ ... ]
> @@ -392,6 +392,12 @@ static inline struct tls_sw_context_tx *tls_sw_ctx_tx(
> return (struct tls_sw_context_tx *)tls_ctx->priv_ctx_tx;
> }
>
> +static inline struct cipher_context *tls_tx_cipher_ctx(
> + const struct tls_context *tls_ctx)
> +{
> + return (struct cipher_context *)&tls_ctx->tx;
> +}
> +
[Severity: Low]
The commit message says this accessor exists "so the TX path can redirect to
a temporary SW context during rekey", but only some TX-side users are
converted here. Is the remaining set intentional?
tls_fill_prepend() in net/tls/tls.h still reads the explicit nonce straight
from ctx->tx:
if (prot->version != TLS_1_3_VERSION &&
prot->cipher_type != TLS_CIPHER_CHACHA20_POLY1305) {
pkt_len += iv_size;
memcpy(buf + TLS_NONCE_OFFSET,
ctx->tx.iv + prot->salt_size, iv_size);
}
and on the HW TX side tls_device.c's tls_push_record() advances
&ctx->tx while tls_device_resync_tx() reads tls_ctx->tx.rec_seq directly.
tls_sw_ctx_finalize() and do_tls_getsockopt_conf() also still use &ctx->tx.
Walking the paths, none of these look reachable while the accessor points
somewhere else: do_tls_setsockopt_conf() rejects a second crypto info for
anything but TLS 1.3 with -EBUSY, so the TLS 1.2 nonce branch above cannot
run during a rekey, and the device record/resync paths are entered from
tls_push_data(), which the later series patch diverts to the SW helpers while
the rekey-pending flag is set. So there does not appear to be a live
mismatch today.
Would it be worth a short comment on tls_fill_prepend()'s ctx->tx.iv use
noting that it is safe because rekey is TLS 1.3 only, so a future reader
does not have to redo this reasoning?
> diff --git a/net/tls/tls.h b/net/tls/tls.h
> index 5a6ee1ea00f8..e8b552c2f4fb 100644
> --- a/net/tls/tls.h
> +++ b/net/tls/tls.h
> @@ -157,7 +157,10 @@ void tls_update_rx_zc_capable(struct tls_context *tls_ctx);
> void tls_sw_strparser_arm(struct sock *sk, struct tls_context *ctx);
> void tls_sw_strparser_done(struct tls_context *tls_ctx);
> int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size);
> +void tls_sw_ctx_tx_init(struct sock *sk, struct tls_sw_context_tx *sw_ctx);
> +int tls_sw_push_pending_record(struct sock *sk, int flags);
> void tls_sw_splice_eof(struct socket *sock);
> +void tls_sw_splice_eof_locked(struct socket *sock);
[Severity: Low]
The changelog lists five refactors, but two of the changes here are not among
them. Could the commit message be extended to cover them?
tls_sw_push_pending_record() loses static and becomes a global symbol, and
tls_sw_splice_eof() is split into a new externally visible
tls_sw_splice_eof_locked() plus a locking wrapper. Neither appears in the
bullet list.
tls_sw_splice_eof_locked() also gains an entry contract that is not written
down anywhere: the caller must already hold tls_ctx->tx_lock and the socket
lock, and is expected to have checked ctx->open_rec. Would a comment above
it, or a lockdep assertion, be worth adding?
> void tls_sw_cancel_work_tx(struct tls_context *tls_ctx);
> void tls_sw_release_resources_tx(struct sock *sk);
> void tls_sw_free_ctx_tx(struct tls_context *tls_ctx);
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index 63c83247f9a3..7b6ab992c86e 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -555,11 +555,11 @@ static int tls_do_encryption(struct sock *sk,
> break;
> }
>
> - memcpy(&rec->iv_data[iv_offset], tls_ctx->tx.iv,
> + memcpy(&rec->iv_data[iv_offset], tls_tx_cipher_ctx(tls_ctx)->iv,
> prot->iv_size + prot->salt_size);
>
> tls_xor_iv_with_seq(prot, rec->iv_data + iv_offset,
> - tls_ctx->tx.rec_seq);
> + tls_tx_cipher_ctx(tls_ctx)->rec_seq);
>
> sge->offset += prot->prepend_size;
> sge->length -= prot->prepend_size;
[ ... ]
> @@ -676,7 +676,7 @@ static int tls_push_record(struct sock *sk, int flags,
> sg_chain(rec->sg_aead_out, 2, &msg_en->sg.data[i]);
>
> tls_make_aad(rec->aad_space, msg_pl->sg.size + prot->tail_size,
> - tls_ctx->tx.rec_seq, record_type, prot);
> + tls_tx_cipher_ctx(tls_ctx)->rec_seq, record_type, prot);
>
> tls_fill_prepend(tls_ctx,
> page_address(sg_page(&msg_en->sg.data[i])) +
[ ... ]
> @@ -712,7 +712,7 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk,
> return err;
> }
>
> -static int tls_sw_push_pending_record(struct sock *sk, int flags)
> +int tls_sw_push_pending_record(struct sock *sk, int flags)
> {
> struct tls_context *tls_ctx = tls_get_ctx(sk);
> struct tls_sw_context_tx *ctx = tls_sw_ctx_tx(tls_ctx);
[ ... ]
> @@ -1028,7 +1028,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> /*
> * Handle unexpected EOF during splice without SPLICE_F_MORE set.
> */
> -void tls_sw_splice_eof(struct socket *sock)
> +void tls_sw_splice_eof_locked(struct socket *sock)
> {
> struct sock *sk = sock->sk;
> struct tls_context *tls_ctx = tls_get_ctx(sk);
> @@ -1039,21 +1039,15 @@ void tls_sw_splice_eof(struct socket *sock)
> bool retrying = false;
> int ret = 0;
>
> - if (!ctx->open_rec)
> - return;
> -
> - mutex_lock(&tls_ctx->tx_lock);
> - lock_sock(sk);
> -
> retry:
> /* same checks as in tls_sw_push_pending_record() */
> rec = ctx->open_rec;
[ ... ]
> /* Transmit if any encryptions have completed */
> if (test_and_clear_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask)) {
> cancel_delayed_work(&ctx->tx_work.work);
> tls_tx_records(sk, 0);
> }
> +}
> +
> +void tls_sw_splice_eof(struct socket *sock)
> +{
> + struct sock *sk = sock->sk;
> + struct tls_context *tls_ctx = tls_get_ctx(sk);
> + struct tls_sw_context_tx *ctx = tls_sw_ctx_tx(tls_ctx);
>
> -unlock:
> + if (!ctx->open_rec)
> + return;
> +
> + mutex_lock(&tls_ctx->tx_lock);
> + lock_sock(sk);
> + tls_sw_splice_eof_locked(sock);
> release_sock(sk);
> mutex_unlock(&tls_ctx->tx_lock);
> }
Both observations are documentation level; the code changes themselves look
equivalent to the previous behaviour.
next prev parent reply other threads:[~2026-08-17 22:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 18:38 [PATCH net-next v16 00/10] tls: Add TLS 1.3 hardware offload support Rishikesh Jethwani
2026-08-07 18:38 ` [PATCH v16 01/10] net: tls: reject TLS 1.3 offload in chcr_ktls and nfp drivers Rishikesh Jethwani
2026-08-07 18:38 ` [PATCH v16 02/10] net/mlx5e: add TLS 1.3 hardware offload support Rishikesh Jethwani
2026-08-07 18:38 ` [PATCH v16 03/10] tls: reject rekey attempts on an existing HW-offloaded connection Rishikesh Jethwani
2026-08-07 18:38 ` [PATCH v16 04/10] tls: add TLS 1.3 hardware offload support Rishikesh Jethwani
2026-08-17 22:11 ` Jakub Kicinski
2026-08-07 18:38 ` [PATCH v16 05/10] tls: split tls_set_sw_offload into init and finalize stages Rishikesh Jethwani
2026-08-17 22:11 ` Jakub Kicinski
2026-08-07 18:38 ` [PATCH v16 06/10] tls: prep helpers and refactors for HW offload KeyUpdate Rishikesh Jethwani
2026-08-17 22:11 ` Jakub Kicinski [this message]
2026-08-07 18:38 ` [PATCH v16 07/10] tls: device: add TX KeyUpdate support Rishikesh Jethwani
2026-08-17 22:11 ` Jakub Kicinski
2026-08-07 18:38 ` [PATCH v16 08/10] tls: device: add RX " Rishikesh Jethwani
2026-08-17 22:11 ` Jakub Kicinski
2026-08-07 18:38 ` [PATCH v16 09/10] tls: device: add tracepoints for the KeyUpdate path Rishikesh Jethwani
2026-08-17 22:11 ` Jakub Kicinski
2026-08-07 18:38 ` [PATCH v16 10/10] selftests: net: add TLS hardware offload test Rishikesh Jethwani
2026-08-17 22:10 ` Jakub Kicinski
2026-08-17 22:11 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260817221142.3666425-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew.gospodarek@broadcom.com \
--cc=borisp@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=john.fastabend@gmail.com \
--cc=leon@kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rjethwani@purestorage.com \
--cc=saeedm@nvidia.com \
--cc=sd@queasysnail.net \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.