Re: [PATCH v4 04/13] ACPI: extlog: Defer CXL protocol error handling to avoid lock inversion

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Inconsistent IRQ protection on `cxl_cper_prot_err_work_lock` and `cxl_cper_work_lock` creates a hardirq lock inversion deadlock.
--

--- Patch [4]: [PATCH v4 04/13] ACPI: extlog: Defer CXL protocol error handling to avoid lock inversion ---
commit 720f77fd10f559d90d89b27d71e19c5f7b332287
Author: Dave Jiang <[email protected]>
ACPI: extlog: Defer CXL protocol error handling to avoid lock inversion

This commit defers CXL protocol error handling to a workqueue to avoid an
AB-BA deadlock during probe and MCE handling. It exports
cxl_cper_post_prot_err() from ghes.c and calls it instead of processing
synchronously in extlog_print().

Closes: https://lore.kernel.org/linux-cxl/[email protected]/

> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 3236a3ce79d6b..a382aabf9835e 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -752,8 +752,8 @@ static DEFINE_KFIFO(cxl_cper_prot_err_fifo, struct cxl_cper_prot_err_work_data,
>  static DEFINE_SPINLOCK(cxl_cper_prot_err_work_lock);
>  struct work_struct *cxl_cper_prot_err_work;
>  
> -static void cxl_cper_post_prot_err(struct cxl_cper_sec_prot_err *prot_err,
> -				   int severity)
> +void cxl_cper_post_prot_err(struct cxl_cper_sec_prot_err *prot_err,
> +			    int severity)
>  {

[Severity: High]
This is a pre-existing issue, but is it possible for a deadlock to occur if
cxl_cper_post_prot_err() interrupts process context?

Looking at drivers/acpi/apei/ghes.c, cxl_cper_register_prot_err_work()
acquires the lock without disabling interrupts:

    guard(spinlock)(&cxl_cper_prot_err_work_lock);

If a CXL protocol error occurs concurrently on the same CPU, the interrupt
or MCE handler will call cxl_cper_post_prot_err(), which tries to acquire
the same lock using:

    guard(spinlock_irqsave)(&cxl_cper_prot_err_work_lock);

Since the lock is already held by the interrupted process, will the interrupt
handler spin forever causing a hard lockup?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4