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

[Sebastian Andrzej Siewior]

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.

> 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.

Thank you.

> Alan Stern

Sebastian