Re: [PATCH net v6] usbnet: fix smp_processor_id() use in preemptible context

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

On 2026-10-09 13:31:17 [+0200], Greg Kroah-Hartman wrote:
> > As far as I am aware, there aren't really any guarantees on the 
> > context of a USB URB-completion callback.  The kerneldoc for struct urb 
> > in include/linux/usb.h says "The completion callback is made 
> > in_interrupt()", but that is most definitely out of date.
> 
> I don't think so, I think some platforms still have those callbacks in
> irq context, unless we changed to threaded irq handlers everywhere?  I
> could have missed that, but we should still write the callbacks to
> assume that and then we should be fine even if we aren't in irq context,
> right?

The HCD invokes the completion callback usually in IRQ context. I think
the VHCI is an exception here.
For the forced-threaded mode we disable BH before the IRQ handler is
invoked. I think even dummy_hcd invokes them from the timer if my memory
is right.

> > Drivers shouldn't rely on any particular context guarantees.  Not even 
> > whether local irqs are enabled/disabled.
> 
> Agreed.

I would suggest to make VHCI invoke the completion callback with BH
disabled. usbnet's tx_complete() does also defer_bh() which schedules a
BH worker via queue_work(). While this works without disabling BH it
leads to waking ksoftirqd and an additional context switch which we
could avoid by dealing with it directly.

> thanks,
> 
> greg k-h

Sebastian