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

[Alan Stern]

On Wed, Oct 14, 2026 at 09:11:41PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-10-12 22:09:25 [-0400], Alan Stern wrote:
> > > > Today you fix VHCI, tomorrow some other virtual HCD will cause problems.
> > > 
> > > We don't have other virtual HCDs, do we?
> > 
> > Well, we've got dummy-hcd.  And just recently there was an RFC post with 
> > a virtio USB HCD implementation.  It wouldn't be surprising to encounter 
> > other ones.
> 
> dummy-hcd is timer driven (so BH). Without looking at virtio I would
> expect it to be interrupt driven.
> 
> > Also, don't forget, URBs can complete in several different ways.  
> > There's normal completion, explicit unlinking, unlinking because the 
> > device was unplugged, unlinking because the device or HC is going into 
> > suspend, and so on.  And there's a difference between URBs sent to 
> > root hubs as opposed to devices actually on the bus.  Not to mention 
> > that in some cases completions may occur synchronously with submission 
> > or unlinking, even though they usually are asynchronous.
> 
> True.
> 
> > > Do you want to document it yourself and have me do the VHCI bits?
> > 
> > At the moment, the only thing I think we can actually guarantee is that 
> > completion handlers will be called with local interrupts disabled.  No 
> > commitments about process context vs. interrupt context vs. BH context 
> > or anything else.
> 
> "local interrupts disabled" as is local_irq_disable()? If so, that is
> not the case. If it completes in BH context (due to HCD_BH) then
> interrupts remain enabled.

Yes, but we can call local_irq_disable() before invoking the completion 
handler -- if we decide that would be a good thing to do.

Otherwise I would say that we don't guarantee anything.

> > Of course, in special cases you might know more about how a particular 
> > HCD works.  But except for platform-specific settings, it's hard to be 
> > certain that your driver will always be used with that one particular 
> > HCD.
> > 
> > If this is okay with you, I can write a documentation patch.
> 
> Sure. The kernel doc for usb_hcd_giveback_urb() says BH or caller's
> context. I think you need to clarify that part and once we have tha, we
> can proceed with the drivers.

What do you think?  Should local interrupts always be disabled, or 
should we offer no guarantee?

Completion handler routines will have to be conservative, so if we don't 
guarantee anything then they will need to disable interrupts themselves 
whenever they require it (for example, by using spin_lock_irqsave() 
instead of spin_lock()).  The core could save them this extra effort, at 
the cost of unnecessarily disabling interrupts sometimes.

USB isn't a tremendously fast bus, so the overhead probably doesn't 
matter much.  Which tradeoff do you prefer?

Alan Stern