Re: [PATCH 1/6] irq_work: Re-raise pending irq_work after system resume

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-11-03 17:46:32 [+0200], Adrian Hunter wrote:
> On 02/11/2026 18:39, Sebastian Andrzej Siewior wrote:
> > On 2026-11-02 12:54:22 [+0200], Adrian Hunter wrote:
> >>
> >> Yes CPUs remain online for suspend2idle, but currently the choice between
> >> suspend2idle and "deep" (S3) suspend is a user space choice,
> >> refer /sys/power/mem_sleep.  Many modern systems do not support S3
> >> anymore, but it has not gone away.
> >>
> >>>
> >>> Anyway, I'm torn; I would much rather make this trigger a WARN and have
> >>
> >> AI now also identifies ftrace, BPF, GHES NMI, and #MC as possible causes,
> >> not just perf.  I haven't tried to confirm any of those.
> >>
> >> And, belatedly, AI is now saying an irq_work raised before lapic_resume()
> >> might result in #GP if the APIC is left in xAPIC mode at resume.  Also
> >> not confirmed.
> > 
> > Could we flush this before similarly to what happens during CPU-hotplug.
> > The question is if this event can stay enqueued during suspend (and
> > handled on resume) or should be taken care before entering suspend.
> 
> WRT "might result in #GP if the APIC is left in xAPIC mode at resume",
> the systems I have checked restore the APIC in x2APIC mode, so the
> issue is theoretical at this point, although I can get "unchecked MSR
> access error: WRMSR to 0x83f" if I deliberately add code to change
> x2APIC to xAPIC early in S3 wake (in x86_acpi_suspend_lowlevel()),
> and then do:
> 
>   perf record -e power:suspend_resume --filter 'action == "machine_suspend" && start == 0' --no-buffering -C 0 -o /tmp/x.data &
>   rtcwake -m mem -s 10
> 
> The error can be avoided with:

I meant flush it via irq_work_run_cpu() like in smpcfd_dead_cpu() (the
CPU-hotplug path) and not go via APIC. You should do it late once the
interrupts are disabled so no new irq-work can be enqueued.

Sebastian