All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Rishikesh Jethwani <rjethwani@purestorage.com>, netdev@vger.kernel.org
Cc: "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>
Subject: Re: [PATCH net v2 0/2] kcm: don't sleep in softirq when the lower socket uses kTLS
Date: Fri, 16 Oct 2026 18:13:19 +0800	[thread overview]
Message-ID: <3108e934-ec00-458b-8720-450554b35b55@linux.dev> (raw)
In-Reply-To: <20261016025059.289202-1-rjethwani@purestorage.com>


On 10/16/26 10:44 AM, Rishikesh Jethwani wrote:
> When a TCP socket with software kTLS RX is attached to a KCM mux,


Can we just reject such combo ?


> psock_data_ready() calls strp_data_ready() from softirq, which calls the
> socket's read_sock(). For kTLS that is tls_sw_read_sock(), which can
> sleep, and CONFIG_DEBUG_ATOMIC_SLEEP reports it on every run of a
> loopback reproducer.
>
> Patch 1 is the fix: KCM parses inline only when read_sock is
> tcp_read_sock() and otherwise defers to the strparser work, which runs
> under lock_sock(). It applies and builds on its own, including on
> stable kernels.
>
> Patch 2 addresses review feedback on v1 and is needed by patch 1.
> kstrp, the workqueue that deferred work runs on, is an ordered
> workqueue shared by every strparser user (KCM, sockmap, espintcp,
> ovpn). With patch 1 alone, a KCM psock decrypting kTLS records in
> software on kstrp would delay parsing and message timeouts for every
> other strparser socket on the system. Patch 2 makes kstrp per-CPU. It
> has no Fixes tag: the ordered workqueue is as old as strparser, and it
> only becomes a real problem for KCM over kTLS with patch 1.
>
> Other strparser users are not affected by the bug fixed in patch 1:
> espintcp is itself a TCP ULP and cannot be combined with kTLS, ovpn
> installs its own ops built from inet_stream_ops, and sockmap reads
> through tcp_bpf_strp_read_sock() and is mutually exclusive with kTLS
> RX (do_tls_setsockopt_conf() rejects sockets with a psock).
>
> Testing: with patch 1, 5/5 runs of the reproducer produce no splat and
> full datagram delivery; without it every run hits "BUG: sleeping
> function called from invalid context" in strp_data_ready ->
> tls_sw_read_sock. Multi-record messages (>16 KiB each) also deliver
> completely with kTLS RX installed before the KCM attach and the whole
> stream queued before the reader starts. With patch 2, test_sockmap and the ovpn TCP selftests
> pass, strparser work runs concurrently across sockets, and dmesg shows
> no warnings.
>
> v2:
>   - add patch 2 (kstrp per-CPU), per review
>   - read sock->ops with READ_ONCE(), pairing with update_sk_prot()
>
> v1: https://lore.kernel.org/netdev/20261013033920.2069285-1-rjethwani@purestorage.com/
>
> Rishikesh Jethwani (2):
>    kcm: defer receive parsing when the lower socket's read_sock may sleep
>    strparser: don't serialize all parser work on one ordered workqueue
>
>   net/kcm/kcmsock.c         | 33 +++++++++++++++++++++++++++++++--
>   net/strparser/strparser.c |  2 +-
>   2 files changed, 32 insertions(+), 3 deletions(-)
>

      parent reply	other threads:[~2026-10-16 10:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  2:44 [PATCH net v2 0/2] kcm: don't sleep in softirq when the lower socket uses kTLS Rishikesh Jethwani
2026-10-16  2:44 ` [PATCH net v2 1/2] kcm: defer receive parsing when the lower socket's read_sock may sleep Rishikesh Jethwani
2026-10-16  2:44 ` [PATCH net v2 2/2] strparser: don't serialize all parser work on one ordered workqueue Rishikesh Jethwani
2026-10-16  2:54 ` [PATCH net v2 0/2] kcm: don't sleep in softirq when the lower socket uses kTLS netdev-bot+sinfo
2026-10-16  4:29   ` Rishikesh Jethwani
2026-10-16 10:13 ` Jiayuan Chen [this message]

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=3108e934-ec00-458b-8720-450554b35b55@linux.dev \
    --to=jiayuan.chen@linux.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rjethwani@purestorage.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.