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

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:

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

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