On Wed, Jan 22, 2025 at 12:47:20PM -0800, Josh Poimboeuf wrote: > On Wed, Jan 22, 2025 at 01:28:21PM +0100, Peter Zijlstra wrote: > > On Tue, Jan 21, 2025 at 06:30:53PM -0800, Josh Poimboeuf wrote: > > > It's possible for irq_work_queue() to fail if the work has already been > > > claimed. That can happen if a TWA_NMI_CURRENT task work is requested > > > before a previous TWA_NMI_CURRENT IRQ work on the same CPU has gotten a > > > chance to run. > > > > I'm confused, if it fails then it's already pending, and we'll get the > > notification already. You can still add the work. > > Yeah, I suppose that makes sense. If the pending irq_work is already > going to set TIF_NOTIFY_RESUME anyway, there's no need to do that again. > > > > The error has to be checked before the write to task->task_works. Also > > > the try_cmpxchg() loop isn't needed in NMI context. The TWA_NMI_CURRENT > > > case really is special, keep things simple by keeping its code all > > > together in one place. > > > > NMIs can nest, > > Just for my understanding: for nested NMIs, the entry code basically > queues up the next NMI, so the C handler (exc_nmi) can't nest. Right? > > > consider #DB (which is NMI like) > > What exactly do you mean by "NMI like"? Is it because a #DB might be > basically running in NMI context, if the NMI hit a breakpoint?
No, #DB, #BP and such are considered NMI (and will have in_nmi() true) because they can trigger anywhere, including sections where IRQs are disabled. > > doing task_work_add() and getting interrupted with NMI doing the same. > > How exactly would that work? At least with my patch the #DB wouldn't be > able to use TWA_NMI_CURRENT unless in_nmi() were true It is, see exc_debug_kernel() doing irqentry_nmi_enter().
