On Wed, 2025-09-03 at 10:10 +0200, Lukas Wunner wrote:
> On Tue, Sep 02, 2025 at 05:44:41PM -0500, Crystal Wood wrote:
> > On PREEMPT_RT, currently both aer_irq and aer_isr run in separate threads,
>
> My understanding is that if request_threaded_irq() is passed both a
> non-NULL handler and a non-NULL thread_fn, the former runs in hardirq
> context and the latter in kthread context. Even on PREEMPT_RT.
>
> So how can aer_irq() and aer_isr() ever both run in kthread context?
> Am I missing something?
They are both threaded. See commit 2a1d3ab8986d1b2 ("genirq: Handle
force threading of irqs with primary and thread handler")
>
> > at the same FIFO priority. This can lead to the aer_isr thread starving
> > the aer_irq thread, particularly if multi_error_valid causes a scan of
> > all devices, and multiple errors are raised during the scan.
>
> I'm not seeing aer_isr() waiting on a spinlock, so how can it be starved?
It's not about locks... Maybe starvation is too strong of a word since
aer_irq does eventually get to run, just too late to avert yet another
multi error that starts the whole thing over again.
-Crystal
