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

[sashiko-bot@kernel.org]

> irq_work_queue() raises the irq_work self-interrupt only when adding
> work to an empty raised_list.  Once raised_list is non-empty, further
> queueing assumes the interrupt is already pending and will eventually
> process the list.
> 
> That assumption can fail across system suspend.  irq_work queued after
> arch_suspend_disable_irqs() and before the interrupt controller is
> suspended, for example from NMI context, may leave its self-interrupt
> pending in hardware.  If that pending interrupt state is lost during
> suspend, hibernation restore, or kexec jump, raised_list remains
> non-empty after resume but nothing will process it.
> 
> Subsequent irq_work added to raised_list will not raise another
> interrupt because the list is already non-empty.  Architectures that use
> an irq_work interrupt and do not process raised_list from the tick can
> [ ... ]
>  task:kworker/u8:1    state:D stack:0     pid:35    tgid:35    ppid:2      task_flags:0x4208060 flags:0x00080000
>  Workqueue: events_unbound fsnotify_mark_destroy_workfn
> 
> Fixes: 76a33061b932 ("irq_work: Force raised irq work to run on irq work interrupt")
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102074039.26983-1-adrian.hunter@intel.com?part=1