* [PATCH] tls: keep TX and RX hardware offload on the same device
@ 2026-10-13 20:26 Rishikesh Jethwani
2026-10-13 20:29 ` netdev-bot+sinfo
0 siblings, 1 reply; 2+ messages in thread
From: Rishikesh Jethwani @ 2026-10-13 20:26 UTC (permalink / raw)
To: netdev, John Fastabend, Sabrina Dubroca, Jakub Kicinski,
Eric Dumazet, Paolo Abeni, Simon Horman, Jonathan Corbet
Cc: linux-doc, Rishikesh Jethwani
After TX is offloaded on device A, a route change, or a change in the
usable-slave set of an 802.3ad or balance-xor (layer3+4) bond, can make
RX setup program device B. tls_device_attach() sees the existing TLS
destructor and keeps ctx->netdev pointing at A. The RX driver state on B
is then untracked: tls_dev_resync() and tls_dev_del() are invoked on A
for a context it never created, and neither socket close nor
NETDEV_DOWN on B calls tls_dev_del() for B, so the driver context leaks.
The reverse setup order has the same problem.
Check the shared device binding under device_offload_lock before each
tls_dev_add(). Permit the first attachment and a second direction on the
same device. Reject a different device, including when the old binding
was cleared by NETDEV_DOWN: the TLS destructor remains installed and
tls_device_attach() cannot establish a new binding. Setup then falls
back to software for the requested direction.
The RX check precedes allocation and software setup. TX uses its existing
resource unwind path without calling the driver. Document the shared
binding and clarify that fallback is per direction.
Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
Documentation/networking/tls-offload.rst | 16 ++++++++++------
net/tls/tls_device.c | 21 +++++++++++++++++++++
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst
index e5802bcd4d22..cf0e599c06a1 100644
--- a/Documentation/networking/tls-offload.rst
+++ b/Documentation/networking/tls-offload.rst
@@ -71,12 +71,16 @@ During driver initialization device sets the ``NETIF_F_HW_TLS_RX`` and
pointer in the :c:member:`tlsdev_ops` member of the
:c:type:`struct net_device <net_device>`.
-When TLS cryptographic connection state is installed on a ``ktls`` socket
-(note that it is done twice, once for RX and once for TX direction,
-and the two are completely independent), the kernel checks if the underlying
-network device is offload-capable and attempts the offload. In case offload
-fails the connection is handled entirely in software using the same mechanism
-as if the offload was never tried.
+TLS cryptographic connection state is installed separately for RX and TX
+on a ``ktls`` socket. For each direction, the kernel checks if the underlying
+network device is offload-capable and attempts the offload. If offload fails,
+that direction is handled in software as if offload had never been tried.
+
+Both hardware directions share one device binding. Once one direction is
+offloaded, the other direction must use the same device. If a route change
+selects a different device, or ``NETDEV_DOWN`` has cleared the binding,
+hardware offload of the other direction is declined and it uses software
+instead.
Offload request is performed via the :c:member:`tls_dev_add` callback of
:c:type:`struct tlsdev_ops <tlsdev_ops>`:
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index f11d0528fc43..d954e17a327b 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -1022,6 +1022,17 @@ int tls_device_decrypted(struct sock *sk, struct tls_context *tls_ctx)
return tls_device_reencrypt(sk, tls_ctx);
}
+/* Both directions share ctx->netdev. A second direction must use that
+ * device; after NETDEV_DOWN clears it, no new direction can be offloaded.
+ */
+static bool tls_device_can_attach(struct tls_context *ctx, struct sock *sk,
+ struct net_device *netdev)
+{
+ return sk->sk_destruct != tls_device_sk_destruct ||
+ rcu_dereference_protected(ctx->netdev,
+ lockdep_is_held(&device_offload_lock)) == netdev;
+}
+
static void tls_device_attach(struct tls_context *ctx, struct sock *sk,
struct net_device *netdev)
{
@@ -1157,6 +1168,11 @@ int tls_set_device_offload(struct sock *sk)
goto release_lock;
}
+ if (!tls_device_can_attach(ctx, sk, netdev)) {
+ rc = -EOPNOTSUPP;
+ goto release_lock;
+ }
+
ctx->priv_ctx_tx = offload_ctx;
rc = netdev->tlsdev_ops->tls_dev_add(netdev, sk, TLS_OFFLOAD_CTX_DIR_TX,
&ctx->crypto_send.info,
@@ -1227,6 +1243,11 @@ int tls_set_device_offload_rx(struct sock *sk, struct tls_context *ctx)
goto release_lock;
}
+ if (!tls_device_can_attach(ctx, sk, netdev)) {
+ rc = -EOPNOTSUPP;
+ goto release_lock;
+ }
+
context = kzalloc_obj(*context);
if (!context) {
rc = -ENOMEM;
--
2.50.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] tls: keep TX and RX hardware offload on the same device
2026-10-13 20:26 [PATCH] tls: keep TX and RX hardware offload on the same device Rishikesh Jethwani
@ 2026-10-13 20:29 ` netdev-bot+sinfo
0 siblings, 0 replies; 2+ messages in thread
From: netdev-bot+sinfo @ 2026-10-13 20:29 UTC (permalink / raw)
To: Rishikesh Jethwani
Cc: netdev, John Fastabend, Sabrina Dubroca, Jakub Kicinski,
Eric Dumazet, Paolo Abeni, Simon Horman, Jonathan Corbet,
linux-doc
Hi!
This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:
- How the issue was discovered, e.g. hit in production, hit during
development, syzbot report, manual code inspection, LLM or static
analysis tool scan.
- Whether the issue was actually triggered, or is only theoretical
(e.g. found by code inspection). If it was triggered please include
the symptoms, like the stack trace or error messages.
Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-10-13 20:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-13 20:26 [PATCH] tls: keep TX and RX hardware offload on the same device Rishikesh Jethwani
2026-10-13 20:29 ` netdev-bot+sinfo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox