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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, Oct 08, 2026 at 02:03:34PM -0400, Alan Stern wrote:
> On Thu, Oct 08, 2026 at 09:43:38AM -0700, Jakub Kicinski wrote:
> > On Thu, 8 Oct 2026 10:16:02 -0400 Alan Stern wrote:
> > > > This looks odd, how did we miss this for 8 years.
> > > > 
> > > > Greg is probably busy, but would be good to get a confirmation
> > > > from either him or some other USB expert that the callbacks
> > > > can indeed be called in process context.  
> > > 
> > > They can be called in BH context with interrupts enabled.  Is that close 
> > > enough?
> > 
> > BH should be fine on !RT. The patch, AFAIU, is because vhci calls
> > the completion callbacks in pure, unadulterated process context.
> > I'm trying to figure out how urgent the fix is, basically.
> > If it's a vhci bug then the usbnet fix is at most an RT problem.
> > Also if vhci is doing something wrong we don't want a truckload
> > of slop patches sent our way to fix 300 drivers :S
> 
> 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?

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

Agreed.

thanks,

greg k-h