linux-toradex.git/net/tls, branch master Linux kernel for Apalis and Colibri modules tls: Honor O_NONBLOCK in tls_sw_splice_read() 2026-10-28T23:50:20+00:00 Chuck Lever cel@kernel.org 2026-10-27T01:52:14+00:00 78ded647d43e335891f981f68c5992a2e763cfcc tls_sw_splice_read() takes its blocking behavior from SPLICE_F_NONBLOCK alone. When splicing from a socket to a pipe, do_splice() sets that flag from the pipe's O_NONBLOCK, not the socket's. On a nonblocking socket, a splice(2) call without SPLICE_F_NONBLOCK therefore sleeps in tls_rx_rec_wait() until a record arrives. tcp_splice_read() instead reads sock->file->f_flags and returns -EAGAIN. Polling first does not avoid the sleep once tls_sw_splice_read() consumes zero-length records, as it does after a later patch in this series. tls_sw_sock_is_readable() reports the socket readable while any record sits on rx_list, including a zero-length record that delivers no bytes to the pipe. For TLS 1.3 the strparser announces a record before decryption, when its plaintext length is still unknown, so the readiness test cannot screen such a record out. A splice that consumes the record and waits for the next stalls every connection an event loop multiplexes. An LLM audit of the TLS read paths found this defect. Treat the socket's O_NONBLOCK as nonblocking too. A caller that sets O_NONBLOCK on the socket and splices without SPLICE_F_NONBLOCK now gets -EAGAIN where the splice blocked before. sendfile(2) from a TLS socket changes the same way, because do_sendfile() leaves the input file's O_NONBLOCK out of the splice flags. Both now behave as they do on a plain TCP socket. Fixes: c46234ebb4d1 ("tls: RX path for ktls") Signed-off-by: Chuck Lever <cel@kernel.org> Link: https://patch.msgid.link/20261027015215.605919-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
tls_sw_splice_read() takes its blocking behavior from
SPLICE_F_NONBLOCK alone. When splicing from a socket to a pipe,
do_splice() sets that flag from the pipe's O_NONBLOCK, not the
socket's. On a nonblocking socket, a splice(2) call without
SPLICE_F_NONBLOCK therefore sleeps in tls_rx_rec_wait() until a
record arrives. tcp_splice_read() instead reads sock->file->f_flags
and returns -EAGAIN.

Polling first does not avoid the sleep once tls_sw_splice_read()
consumes zero-length records, as it does after a later patch in this
series. tls_sw_sock_is_readable() reports the socket readable while
any record sits on rx_list, including a zero-length record that
delivers no bytes to the pipe. For TLS 1.3 the strparser announces a
record before decryption, when its plaintext length is still unknown,
so the readiness test cannot screen such a record out. A splice that
consumes the record and waits for the next stalls every connection
an event loop multiplexes.

An LLM audit of the TLS read paths found this defect.

Treat the socket's O_NONBLOCK as nonblocking too. A caller that
sets O_NONBLOCK on the socket and splices without SPLICE_F_NONBLOCK
now gets -EAGAIN where the splice blocked before. sendfile(2) from
a TLS socket changes the same way, because do_sendfile() leaves the
input file's O_NONBLOCK out of the splice flags. Both now behave as
they do on a plain TCP socket.

Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Signed-off-by: Chuck Lever <cel@kernel.org>
Link: https://patch.msgid.link/20261027015215.605919-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tls: keep TX and RX hardware offload on the same device 2026-10-28T08:45:02+00:00 Rishikesh Jethwani rjethwani@purestorage.com 2026-10-20T21:44:59+00:00 1c8a70075235cd733095532a97f2405037c52a7b 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. This issue was discovered during code review and subsequently reproduced on hardware using mlx5 and TLS 1.2 AES-GCM-128. Changing the route between TX and RX setup installed the second direction on a different device. Driver traces showed successful adds on both devices, but both deletes at socket close targeted the first device, leaving an orphaned context on the second. Both setup orders reproduced the leak, even though all current core TLS context counters returned to zero. No crash was observed. With the fix, the same tests correctly fall back to software for the second direction and leave no orphaned hardware context. Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload") Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com> Signed-off-by: Dave Miller <davem@davem-thinkpadp1gen8.ibmlond.csb> 
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.

This issue was discovered during code review and subsequently
reproduced on hardware using mlx5 and TLS 1.2 AES-GCM-128.

Changing the route between TX and RX setup installed the second
direction on a different device. Driver traces showed successful adds
on both devices, but both deletes at socket close targeted the first
device, leaving an orphaned context on the second. Both setup orders
reproduced the leak, even though all current core TLS context counters
returned to zero. No crash was observed.

With the fix, the same tests correctly fall back to software for the
second direction and leave no orphaned hardware context.

Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
Signed-off-by: Dave Miller <davem@davem-thinkpadp1gen8.ibmlond.csb>
tls: avoid field-spanning write when copying crypto info 2026-10-23T23:05:59+00:00 Nandor Kracser nandor@riptides.io 2026-10-21T07:32:33+00:00 c43c1c24f3cdc0d2d3f59e5686573ac3129637aa do_tls_setsockopt_conf() copies the cipher-specific part of the crypto info to crypto_info + 1, where crypto_info points at the 4-byte info member of union tls_crypto_context. When optval is a kernel sockptr, copy_from_sockptr_offset() is a memcpy(), and FORTIFY_SOURCE bounds the destination by that member: [ 6.948348] memcpy: detected field-spanning write (size 52) of single field "dst" at include/linux/sockptr.h:49 (size 0) [ 6.948480] WARNING: include/linux/sockptr.h:49 at tls_setsockopt+0x9b2/0xa30, CPU#1: init/1 [ 7.001355] Call Trace: [ 7.003146] do_sock_setsockopt+0xb0/0x190 [ 7.003975] __sys_setsockopt+0x76/0xc0 [ 7.005368] do_syscall_64+0xda/0x4b0 tls_setsockopt() gets a kernel sockptr whenever a cgroup setsockopt BPF program is attached, even one that leaves the option alone, because __cgroup_bpf_run_filter_setsockopt() passes optval on in a kernel buffer. With a no-op program on the root cgroup, a plain TLS_TX setsockopt() with AES-GCM-256 triggers the warning above on an x86_64 build with CONFIG_FORTIFY_SOURCE. Copy into the union at offset sizeof(struct tls_crypto_info) instead. crypto_ctx already points at the right union for both the first set and the TLS 1.3 rekey (tmp) case, and the address is unchanged. Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt") Signed-off-by: Nandor Kracser <nandor@riptides.io> Link: https://patch.msgid.link/20261021073233.16720-1-nandor@riptides.io Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
do_tls_setsockopt_conf() copies the cipher-specific part of the crypto
info to crypto_info + 1, where crypto_info points at the 4-byte info
member of union tls_crypto_context. When optval is a kernel sockptr,
copy_from_sockptr_offset() is a memcpy(), and FORTIFY_SOURCE bounds the
destination by that member:

  [    6.948348] memcpy: detected field-spanning write (size 52) of single field "dst" at include/linux/sockptr.h:49 (size 0)
  [    6.948480] WARNING: include/linux/sockptr.h:49 at tls_setsockopt+0x9b2/0xa30, CPU#1: init/1
  [    7.001355] Call Trace:
  [    7.003146]  do_sock_setsockopt+0xb0/0x190
  [    7.003975]  __sys_setsockopt+0x76/0xc0
  [    7.005368]  do_syscall_64+0xda/0x4b0

tls_setsockopt() gets a kernel sockptr whenever a cgroup setsockopt BPF
program is attached, even one that leaves the option alone, because
__cgroup_bpf_run_filter_setsockopt() passes optval on in a kernel
buffer. With a no-op program on the root cgroup, a plain TLS_TX
setsockopt() with AES-GCM-256 triggers the warning above on an x86_64
build with CONFIG_FORTIFY_SOURCE.

Copy into the union at offset sizeof(struct tls_crypto_info) instead.
crypto_ctx already points at the right union for both the first set
and the TLS 1.3 rekey (tmp) case, and the address is unchanged.

Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt")
Signed-off-by: Nandor Kracser <nandor@riptides.io>
Link: https://patch.msgid.link/20261021073233.16720-1-nandor@riptides.io
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tls: fix the open record check in the max payload size setsockopt 2026-10-23T21:09:01+00:00 Jiayuan Chen jiayuan.chen@linux.dev 2026-10-20T12:12:39+00:00 ed642349d87dd7067a44c30319f0cffd22780376 do_tls_setsockopt_tx_payload_len() refuses to resize records while one is open, but the check is broken in two ways. It reaches for the open record through tls_sw_ctx_tx(), an unchecked cast of ctx->priv_ctx_tx. Under device offload that pointer is a tls_offload_context_tx, so the check reads a field of the wrong struct: it returns EBUSY on whatever happens to be there, and never sees the record that really is open. Dispatch on tx_conf. The socket lock alone is also not enough to tell no sender is in flight. The device tx path drops it in sk_stream_wait_memory() after tls_push_record() cleared open_record, so setsockopt can slip in mid-sendmsg and shrink the limit. tls_push_data() latches the limit once per call, and a record left open by MSG_MORE can then be bigger than the new limit, making the u32 subtraction in the copy clamp wrap around and build an oversized record. Take tx_lock like the sendmsg paths do so setsockopt waits for in-flight senders. Re-reading the limit inside the tls_push_data() loop could close the wrap too, but a parked sender would still finish with the old limit, so serializing on tx_lock is simpler. Take tx_lock interruptible, as tls_sw_sendmsg() does. Both sendmsg paths keep it across sk_stream_wait_memory(), which sleeps until the peer reads, so a plain mutex_lock() could park setsockopt in D state for as long as the sender waits. The lock_sock() after it is fine uninterruptible: a sender sleeping for memory has released the socket lock, so that wait only covers short critical sections, like every other setsockopt. Fixes: 82cb5be6ad64 ("net/tls: support setting the maximum payload size") Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://patch.msgid.link/20261020121240.29082-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
do_tls_setsockopt_tx_payload_len() refuses to resize records while one is
open, but the check is broken in two ways.

It reaches for the open record through tls_sw_ctx_tx(), an unchecked cast
of ctx->priv_ctx_tx.  Under device offload that pointer is a
tls_offload_context_tx, so the check reads a field of the wrong struct: it
returns EBUSY on whatever happens to be there, and never sees the record
that really is open.  Dispatch on tx_conf.

The socket lock alone is also not enough to tell no sender is in flight.
The device tx path drops it in sk_stream_wait_memory() after
tls_push_record() cleared open_record, so setsockopt can slip in
mid-sendmsg and shrink the limit.  tls_push_data() latches the limit once
per call, and a record left open by MSG_MORE can then be bigger than the
new limit, making the u32 subtraction in the copy clamp wrap around and
build an oversized record.  Take tx_lock like the sendmsg paths do so
setsockopt waits for in-flight senders.  Re-reading the limit inside the
tls_push_data() loop could close the wrap too, but a parked sender would
still finish with the old limit, so serializing on tx_lock is simpler.

Take tx_lock interruptible, as tls_sw_sendmsg() does.  Both sendmsg paths
keep it across sk_stream_wait_memory(), which sleeps until the peer reads,
so a plain mutex_lock() could park setsockopt in D state for as long as
the sender waits.  The lock_sock() after it is fine uninterruptible: a
sender sleeping for memory has released the socket lock, so that wait only
covers short critical sections, like every other setsockopt.

Fixes: 82cb5be6ad64 ("net/tls: support setting the maximum payload size")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20261020121240.29082-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netmem: rename get/put_netmem() to netmem_inc/dec_ref() 2026-10-22T00:00:00+00:00 Mina Almasry almasrymina@google.com 2026-10-21T01:55:58+00:00 2620efb2cec11628ff419dc876981e1f8fed664a Follow the object_action() naming convention for netmem non-page_pool reference helpers by renaming get_netmem() and put_netmem() to netmem_inc_ref() and netmem_dec_ref(). Use netmem_inc_ref() and netmem_dec_ref() rather than netmem_ref() and netmem_unref() because netmem_ref is already a typedef (typedef unsigned long __bitwise netmem_ref). Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mina Almasry <almasrymina@google.com> Link: https://patch.msgid.link/20261021015558.4124825-3-almasrymina@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Follow the object_action() naming convention for netmem non-page_pool
reference helpers by renaming get_netmem() and put_netmem() to
netmem_inc_ref() and netmem_dec_ref().

Use netmem_inc_ref() and netmem_dec_ref() rather than netmem_ref() and
netmem_unref() because netmem_ref is already a typedef (typedef unsigned
long __bitwise netmem_ref).

Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20261021015558.4124825-3-almasrymina@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tls: device: protect async RX resync state during device-down 2026-10-20T19:32:50+00:00 Rishikesh Jethwani rjethwani@purestorage.com 2026-10-13T21:35:17+00:00 f89a228125238f8d4c7e2b8161e2a85fe35307b6 tls_device_rx_resync_new_rec() can run in process context with the socket lock held, but without an RCU read lock: from the strparser work item (tls_strp_work()) and from the receive paths (tls_rx_rec_wait(), tls_rx_rec_done()). The resync_async pointer belongs to the driver RX context, which tls_device_down() tears down from the netdev notifier without taking the socket lock; only the softirq entry to the parser is implicitly inside an RCU section. If the parser passes the TLS_RX_DEV_DEGRADED check before device-down sets it, tls_device_down() can complete synchronize_net() and delete the driver context before the parser accesses resync_async->req or its record log. In the asynchronous stage the parser also writes the record log, so this is a write to freed memory, not only a stale read. The RCU section in tls_device_resync_rx() starts after those accesses and therefore does not prevent the use-after-free. Found by code inspection; not reproduced. Hitting the window requires the parser to be preempted between the DEGRADED check and the resync_async access across the device-down grace period and the driver's teardown. Fixes: ed9b7646b06a ("net/tls: Add asynchronous resync") Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com> Link: https://patch.msgid.link/20261013213517.2219663-1-rjethwani@purestorage.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
tls_device_rx_resync_new_rec() can run in process context with the
socket lock held, but without an RCU read lock: from the strparser work
item (tls_strp_work()) and from the receive paths (tls_rx_rec_wait(),
tls_rx_rec_done()). The resync_async pointer belongs to the driver RX
context, which tls_device_down() tears down from the netdev notifier
without taking the socket lock; only the softirq entry to the parser is
implicitly inside an RCU section.

If the parser passes the TLS_RX_DEV_DEGRADED check before device-down
sets it, tls_device_down() can complete synchronize_net() and delete the
driver context before the parser accesses resync_async->req or its
record log. In the asynchronous stage the parser also writes the record
log, so this is a write to freed memory, not only a stale read. The RCU
section in tls_device_resync_rx() starts after those accesses and
therefore does not prevent the use-after-free.

Found by code inspection; not reproduced. Hitting the window requires
the parser to be preempted between the DEGRADED check and the
resync_async access across the device-down grace period and the
driver's teardown.

Fixes: ed9b7646b06a ("net/tls: Add asynchronous resync")
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
Link: https://patch.msgid.link/20261013213517.2219663-1-rjethwani@purestorage.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: skbuff: replace __skb_frag_ref() with symmetric skb_netmem_ref() 2026-10-20T09:52:46+00:00 Mina Almasry almasrymina@google.com 2026-10-14T17:37:18+00:00 1f6f88105e1da95954bca63475796ee09afd8ba1 Previously, __skb_frag_ref() and skb_frag_ref() unconditionally incremented the non-pp backing refcount via get_netmem(), while skb_frag_unref() decremented pp_ref_count whenever skb->pp_recycle was set. Ref-ing a page_pool fragment into a pp_recycle=1 SKB (or clearing pp_recycle=0 on an uncloned SKB while clones still held pp_recycle=1) leaked the backing non-pp refcount and underflowed pp_ref_count across IP-TFS, skb_split(), skb_shift(), and cloned unclone paths. Replace __skb_frag_ref() with skb_netmem_ref(netmem, recycle) as the exact counterpart to skb_netmem_unref(netmem, recycle): - Keep skb->pp_recycle intact in skb_release_data() so uncloning paths (pskb_expand_head() and pskb_carve_inside_{header,nonlinear}()) keep trading pp_ref_count references symmetrically across clones. - Propagate pp_recycle and call skb_frag_ref() on the destination SKB in __pskb_copy_fclone(), skb_zerocopy(), skb_split(), skb_shift(), and skb_segment(). - Linearize an output segment's existing frags in skb_segment() before attaching frags from a frag_list SKB with a different pp_recycle bit, since each output segment carries a single pp_recycle bit. - Use skb_frag_ref() in xfrm_iptfs, chcr_ktls, and cassini, and call get_netmem() directly in veth and tls_device_fallback where callers explicitly take a raw non-pp reference. Found by code inspection while reviewing the IP-TFS pp_ref_count fix [1] and confirmed with the KUnit tests added later in this series; not observed in production. The xfrm_iptfs, chcr_ktls, cassini, veth, and tls_device_fallback changes are compile-tested only. Link: https://lore.kernel.org/netdev/xfrm-iptfs-pp_ref_count-underflow-v4-1-912fa72106f0@secunet.com/ [1] Cc: Antony Antony <antony.antony@secunet.com> Cc: Stanislav Fomichev <sdf@fomichev.me> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Jesper Dangaard Brouer <hawk@kernel.org> Cc: bpf@vger.kernel.org Assisted-by: LLM Signed-off-by: Mina Almasry <almasrymina@google.com> Tested-by: Antony Antony <antony.antony@secunet.com> Link: https://patch.msgid.link/20261014173945.373295-5-almasrymina@google.com Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
Previously, __skb_frag_ref() and skb_frag_ref() unconditionally
incremented the non-pp backing refcount via get_netmem(), while
skb_frag_unref() decremented pp_ref_count whenever skb->pp_recycle was
set. Ref-ing a page_pool fragment into a pp_recycle=1 SKB (or clearing
pp_recycle=0 on an uncloned SKB while clones still held pp_recycle=1)
leaked the backing non-pp refcount and underflowed pp_ref_count across
IP-TFS, skb_split(), skb_shift(), and cloned unclone paths.

Replace __skb_frag_ref() with skb_netmem_ref(netmem, recycle) as the
exact counterpart to skb_netmem_unref(netmem, recycle):

- Keep skb->pp_recycle intact in skb_release_data() so uncloning paths
  (pskb_expand_head() and pskb_carve_inside_{header,nonlinear}()) keep
  trading pp_ref_count references symmetrically across clones.
- Propagate pp_recycle and call skb_frag_ref() on the destination SKB in
  __pskb_copy_fclone(), skb_zerocopy(), skb_split(), skb_shift(), and
  skb_segment().
- Linearize an output segment's existing frags in skb_segment() before
  attaching frags from a frag_list SKB with a different pp_recycle bit,
  since each output segment carries a single pp_recycle bit.
- Use skb_frag_ref() in xfrm_iptfs, chcr_ktls, and cassini, and call
  get_netmem() directly in veth and tls_device_fallback where callers
  explicitly take a raw non-pp reference.

Found by code inspection while reviewing the IP-TFS pp_ref_count fix [1]
and confirmed with the KUnit tests added later in this series; not
observed in production. The xfrm_iptfs, chcr_ktls, cassini, veth, and
tls_device_fallback changes are compile-tested only.

Link: https://lore.kernel.org/netdev/xfrm-iptfs-pp_ref_count-underflow-v4-1-912fa72106f0@secunet.com/ [1]
Cc: Antony Antony <antony.antony@secunet.com>
Cc: Stanislav Fomichev <sdf@fomichev.me>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: bpf@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Mina Almasry <almasrymina@google.com>
Tested-by: Antony Antony <antony.antony@secunet.com>
Link: https://patch.msgid.link/20261014173945.373295-5-almasrymina@google.com
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: skbuff: replace skb_page_unref() and __skb_frag_unref() with skb_netmem_unref() 2026-10-20T09:52:46+00:00 Mina Almasry almasrymina@google.com 2026-10-14T17:37:17+00:00 4d688084070e72d66090f3bb739218278d3e889b Unreferencing a page_pool fragment with recycle=false decrements the non-pp backing refcount instead of pp_ref_count, underflowing the page refcount when the fragment was owned via page_pool (as on mlx4's RX error path). Having both skb_page_unref() and __skb_frag_unref(frag, recycle) made it easy for callers to pass hardcoded recycle=false on SKB-owned fragments. Replace skb_page_unref() and __skb_frag_unref() with skb_netmem_unref(netmem, recycle), which dispatches to napi_pp_put_page() when recycle is true and put_netmem() otherwise: - Use skb_frag_unref(skb, ...) on SKB-owned fragments in mlx4, sky2, tls_strp, and skb_shift() so unrefs always match skb->pp_recycle. - Use put_netmem() directly in tls_device's destroy_record(), which releases raw non-pp page references outside an SKB. Found by code inspection and confirmed with the KUnit tests added later in this series; not observed in production. The mlx4, sky2, and TLS call-site changes are compile-tested only. Assisted-by: LLM Signed-off-by: Mina Almasry <almasrymina@google.com> Link: https://patch.msgid.link/20261014173945.373295-4-almasrymina@google.com Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
Unreferencing a page_pool fragment with recycle=false decrements the
non-pp backing refcount instead of pp_ref_count, underflowing the page
refcount when the fragment was owned via page_pool (as on mlx4's RX
error path). Having both skb_page_unref() and __skb_frag_unref(frag,
recycle) made it easy for callers to pass hardcoded recycle=false on
SKB-owned fragments.

Replace skb_page_unref() and __skb_frag_unref() with
skb_netmem_unref(netmem, recycle), which dispatches to
napi_pp_put_page() when recycle is true and put_netmem() otherwise:

- Use skb_frag_unref(skb, ...) on SKB-owned fragments in mlx4, sky2,
  tls_strp, and skb_shift() so unrefs always match skb->pp_recycle.
- Use put_netmem() directly in tls_device's destroy_record(), which
  releases raw non-pp page references outside an SKB.

Found by code inspection and confirmed with the KUnit tests added later
in this series; not observed in production. The mlx4, sky2, and TLS
call-site changes are compile-tested only.

Assisted-by: LLM
Signed-off-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/20261014173945.373295-4-almasrymina@google.com
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: add sk_set_nospace() and sk_clear_nospace() 2026-10-05T23:04:48+00:00 Eric Dumazet edumazet@kernel.org 2026-09-29T07:17:36+00:00 6ba48a271bdb9c3e106314936ee202f7f249a3db SOCK_NOSPACE lives in sk->sk_socket->flags and is manipulated from about thirty places in the tree, all of them open coding the sk->sk_socket dereference, some with a NULL check, some without, and some reaching the struct socket by yet another path. Add sk_set_nospace() and sk_clear_nospace() helpers and convert the core networking setters and clearers to them; the following patches convert the remaining subsystem callers so that "git grep _bit(SOCK_NOSPACE" only reports the two helpers and the remaining test_bit() sites. Callers that had no NULL check are all called from user context with a socket attached, so folding the check into the helpers only makes them more robust. No functional change intended. This is a preparation patch: a following one gives TCP a cheaper private copy of this bit, and needs a single choke point to keep it in sync. Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Eric Dumazet <edumazet@kernel.org> Link: https://patch.msgid.link/20260929071743.23624-3-edumazet@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
SOCK_NOSPACE lives in sk->sk_socket->flags and is manipulated from
about thirty places in the tree, all of them open coding the
sk->sk_socket dereference, some with a NULL check, some without,
and some reaching the struct socket by yet another path.

Add sk_set_nospace() and sk_clear_nospace() helpers and convert the
core networking setters and clearers to them; the following patches
convert the remaining subsystem callers so that
"git grep _bit(SOCK_NOSPACE" only reports the two helpers and the
remaining test_bit() sites.

Callers that had no NULL check are all called from user context with a
socket attached, so folding the check into the helpers only makes them
more robust.

No functional change intended.

This is a preparation patch: a following one gives TCP a cheaper
private copy of this bit, and needs a single choke point to keep it
in sync.

Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20260929071743.23624-3-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tls: drop duplicate check_app_limited in tls_push_sg 2026-09-21T23:21:20+00:00 Geliang Tang tanggeliang@kylinos.cn 2026-09-17T08:42:06+00:00 cd7e4b1e479622ffc117bc7215c0796d7acb8dd1 Before commit c5c37af6ecad9 ("tcp: Convert do_tcp_sendpages() to use MSG_SPLICE_PAGES"), do_tcp_sendpages() did not call tcp_rate_check_app_limited() internally, so callers needed an explicit tcp_rate_check_app_limited() to cover it. That commit replaced do_tcp_sendpages() with direct tcp_sendmsg_locked() calls, which perform the check on every path that queues data. The outer call became redundant but was left in place. The site changed here, tls_push_sg(), holds the socket lock and invokes tcp_sendmsg_locked() on every iteration. The early-return paths in tcp_sendmsg_locked() that skip tcp_rate_check_app_limited() -- the MSG_ZEROCOPY allocation failure and MSG_FASTOPEN branches -- return without queueing any MSG_SPLICE_PAGES data, so there is no functional consequence from omitting the outer check. A potential benefit of this change is that it facilitates future reuse of tls_push_sg() for KTLS support in protocols beyond TCP, such as MPTCP. Since tcp_rate_check_app_limited() is TCP-specific while sendmsg_locked() is a generic interface in struct proto_ops, this change allows us to switch to different protocols via sk->sk_socket->ops->sendmsg_locked() without carrying protocol-specific assumptions. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Link: https://patch.msgid.link/5bc803abb4e27054eaffc8b26db7812e6347b0dd.1789634247.git.tanggeliang@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Before commit c5c37af6ecad9 ("tcp: Convert do_tcp_sendpages() to use
MSG_SPLICE_PAGES"), do_tcp_sendpages() did not call
tcp_rate_check_app_limited() internally, so callers needed an explicit
tcp_rate_check_app_limited() to cover it. That commit replaced
do_tcp_sendpages() with direct tcp_sendmsg_locked() calls, which perform
the check on every path that queues data. The outer call became redundant
but was left in place.

The site changed here, tls_push_sg(), holds the socket lock and invokes
tcp_sendmsg_locked() on every iteration. The early-return paths in
tcp_sendmsg_locked() that skip tcp_rate_check_app_limited() -- the
MSG_ZEROCOPY allocation failure and MSG_FASTOPEN branches -- return
without queueing any MSG_SPLICE_PAGES data, so there is no functional
consequence from omitting the outer check.

A potential benefit of this change is that it facilitates future reuse of
tls_push_sg() for KTLS support in protocols beyond TCP, such as MPTCP.
Since tcp_rate_check_app_limited() is TCP-specific while sendmsg_locked()
is a generic interface in struct proto_ops, this change allows us to switch
to different protocols via sk->sk_socket->ops->sendmsg_locked() without
carrying protocol-specific assumptions.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Link: https://patch.msgid.link/5bc803abb4e27054eaffc8b26db7812e6347b0dd.1789634247.git.tanggeliang@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>