Re: [PATCH net v2] net: Drop the lock in skb_may_tx_timestamp()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-02-20 14:02:41 [-0800], Jakub Kicinski wrote:
> > > 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.

We kind of have NAPI and the rule that we inject packets into the stack
only from within sofirq. As far as I remember we got NAPI within the 2.5
cycle and then this got as an written rule (or written). Simply because
injecting packets from an IRQ could soft lock the system if you receive
a lot.
Using softirq has the benefit of moving the load to ksoftirqd which can
then be preempted by the scheduler.
This was easy to enforce as an argument of its own and the fact that
almost all required locking is BH-only.

Since around v2.3.4 the locking was moved into struct sk_buff_head,
before that there was global skb_queue_lock. Till this day the lock is
acquired with IRQ-off. This kind of makes it possible to queue the skb
from within the IRQ. This, and the fact that the "cloned" skb has no
extra baggage (such as an destructor) and the kfree_skb() works here,
too.

This can be a lot what you have to know especially if you want to extend
things later on and you don't want to think if this can be done here or
if we violate an exception to a rule.

Based on that I would say it is absolutely sane to enforce delivery of
skb here from !hardirq context. After looking into it last week, the BH
worker shouldn't be worst choice here.

How do we move forward? Merge this, backport stable and then convert
in-tree user away from IRQ delivery _or_ fix the driver one by one and
backport them stable? Or…

Sebastian