From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Kurt Kanzenbach <kurt@linutronix.de>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net v2] net: Drop the lock in skb_may_tx_timestamp()
Date: Fri, 20 Feb 2026 14:02:41 -0800 [thread overview]
Message-ID: <20260220140241.51be1e30@kernel.org> (raw)
In-Reply-To: <willemdebruijn.kernel.85c1623c5d65@gmail.com>
On Fri, 20 Feb 2026 16:49:24 -0500 Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > On Fri, 20 Feb 2026 19:38:58 +0100 Sebastian Andrzej Siewior wrote:
> > > skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must
> > > not be taken in IRQ context, only softirq is okay. A few drivers receive
> > > the timestamp via a dedicated interrupt and complete the TX timestamp
> > > from that handler. This will lead to a deadlock if the lock is already
> > > write-locked on the same CPU.
> >
> > Fine by me, the fix is fairly simple. But FWIW I can't stop myself from
> > restating that networking core is not supposed to be called by drivers
> > in hard IRQ context in general. Especially when it comes to anything
> > that may involve user sockets. So my intuition is that fixing the driver
> > to use a tasklet^w work_bh would make the expectations clearer.
> >
> > Willem, you don't find that argument convincing?
>
> This narrow case seems fine to me too.
>
> But I can understand if that would be a global rule. As it simplifies
> reasoning about correctness of core code quite a bit. In which case
> that would trump this. No preference from me. Clearly other drivers
> are quite capable of making this work without requiring updates from
> hard IRQ.
Well put. I guess we're in the same boat then. No strong preference
here either, but I like the clearly drawn expectations to simplify
reasoning.
> > BTW IIUC the driver in question was igc, and it did not exist for
> > another 3 years after the commit under Fixes, which is another bad
> > smell here.
>
> I was wondering about that too. But Sebastian shared quite a few more
> drivers: https://lore.kernel.org/netdev/20260217132838.kgRAQ87W@linutronix.de/
> I did not bother to check whether all were newer than the introduction
> of the blamed commit.
IIRC CAN did not have timestamping until relatively recently so none
of those count. hclge is even newer than igc.
next prev parent reply other threads:[~2026-02-20 22:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 18:38 [PATCH net v2] net: Drop the lock in skb_may_tx_timestamp() Sebastian Andrzej Siewior
2026-02-20 21:20 ` Willem de Bruijn
2026-02-20 21:29 ` Jakub Kicinski
2026-02-20 21:49 ` Willem de Bruijn
2026-02-20 22:02 ` Jakub Kicinski [this message]
2026-02-23 17:07 ` Sebastian Andrzej Siewior
2026-02-23 23:27 ` Jakub Kicinski
2026-02-24 9:02 ` Eric Dumazet
2026-02-24 10:26 ` Paolo Abeni
2026-02-21 0:45 ` Jason Xing
2026-02-23 8:42 ` Eric Dumazet
2026-02-24 10:50 ` patchwork-bot+netdevbpf
2026-02-26 8:11 ` Kurt Kanzenbach
2026-02-26 8:50 ` Sebastian Andrzej Siewior
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=20260220140241.51be1e30@kernel.org \
--to=kuba@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kurt@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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.