From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Ömer Mete Kaya" <omermetekaya0@gmail.com>,
oneukum@suse.com, netdev@vger.kernel.org, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
david.laight.linux@gmail.com,
syzbot+04cd90bb99c6ef81a65d@syzkaller.appspotmail.com
Subject: Re: [PATCH net v6] usbnet: fix smp_processor_id() use in preemptible context
Date: Thu, 15 Oct 2026 00:04:03 +0200 [thread overview]
Message-ID: <20261014220403.R38Gf0pW@linutronix.de> (raw)
In-Reply-To: <89da3b1f-60e5-4f18-9592-3d6d7175c437@rowland.harvard.edu>
On 2026-10-14 15:22:51 [-0400], Alan Stern wrote:
> > "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.
Oh please don't. This will break PREEMPT_RT badly.
> Otherwise I would say that we don't guarantee anything.
Okay.
> > > 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?
No guarantees in this regard, please. Disabling interrupts will break
PREEMPT_RT here.
> 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.
The problem is spin_lock_irqsave() will not disable interrupts on
PREEMPT_RT while local_irq_save() will. For this reason I would prefer
to skip it.
> USB isn't a tremendously fast bus, so the overhead probably doesn't
> matter much. Which tradeoff do you prefer?
So if we don't guarantee that BH is disabled then I would say nothing is
guaranteed, anything is possible.
A little note: cdns and dwc3 do disable BH in their voluntary threaded
interrupt handler. The reason is that the networking driver expect this.
I know this is the gadget and not HCD side but sort of the same issue.
While BH is disabled for interrupt handler (and forced threaded handler)
it is not if requested explicitly.
This would mean that the completion handler of the networking driver
would have to do local_bh_disable() themself. I could live with this ;)
> Alan Stern
Sebastian
next prev parent reply other threads:[~2026-10-14 22:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 21:59 [PATCH net v6] usbnet: fix smp_processor_id() use in preemptible context Ömer Mete Kaya
2026-10-08 3:00 ` Jakub Kicinski
2026-10-08 14:16 ` Alan Stern
2026-10-08 16:43 ` Jakub Kicinski
2026-10-08 18:03 ` Alan Stern
2026-10-09 11:31 ` Greg Kroah-Hartman
2026-10-12 19:49 ` Sebastian Andrzej Siewior
2026-10-12 20:26 ` Alan Stern
2026-10-12 21:25 ` Sebastian Andrzej Siewior
2026-10-13 2:09 ` Alan Stern
2026-10-13 9:11 ` Paolo Abeni
2026-10-13 9:22 ` Sebastian Andrzej Siewior
2026-10-14 19:11 ` Sebastian Andrzej Siewior
2026-10-14 19:22 ` Alan Stern
2026-10-14 22:04 ` Sebastian Andrzej Siewior [this message]
2026-10-13 8:54 ` Oliver Neukum
2026-10-13 9:20 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261014220403.R38Gf0pW@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=david.laight.linux@gmail.com \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=omermetekaya0@gmail.com \
--cc=oneukum@suse.com \
--cc=pabeni@redhat.com \
--cc=stern@rowland.harvard.edu \
--cc=syzbot+04cd90bb99c6ef81a65d@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox