Re: [PATCH v2] staging: fbtft: make dirty_lock IRQ-safe

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

Pre-existing issues:
- [High] dirty_lock must be converted to raw_spinlock_t to prevent fatal kernel panics on PREEMPT_RT.
--

--- Patch [1]: [PATCH v2] staging: fbtft: make dirty_lock IRQ-safe ---
commit 2781cf2c7f0e0cfa744e4747b9f7004477fdff7b
Author: Hui Su <[email protected]>

staging: fbtft: make dirty_lock IRQ-safe

This commit updates the dirty_lock acquisitions in fbtft_mkdirty() and
fbtft_deferred_io() to use IRQ-safe variants. This prevents a possible
IRQ lock inversion between dirty_lock and console_owner.

Link: https://lore.kernel.org/lkml/[email protected]/

> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index ca0c38221c16b..7925d974de801 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -298,14 +298,15 @@ static void fbtft_mkdirty(struct fb_info *info, int y, int height)
>  {
>  	struct fbtft_par *par = info->par;
>  	struct fb_deferred_io *fbdefio = info->fbdefio;
> +	unsigned long flags;
>  
>  	/* Mark display lines/area as dirty */
> -	spin_lock(&par->dirty_lock);
> +	spin_lock_irqsave(&par->dirty_lock, flags);

[Severity: High]
This isn't a bug introduced by this patch, but will this cause a kernel
panic on PREEMPT_RT systems?

The commit message notes that fbtft_mkdirty() can be reached from the fbcon
rendering path while processing printk() in hardirq context. On PREEMPT_RT,
spinlock_t is mapped to a sleepable rt_mutex. Acquiring a sleepable lock in
true hardirq context will trigger a sleep-in-atomic bug.

Since dirty_lock is accessed in true hardirq context, should the
declaration of dirty_lock in struct fbtft_par be converted to a
raw_spinlock_t and acquired via raw_spin_lock_irqsave() to safely
synchronize under PREEMPT_RT?

>  	if (y < par->dirty_lines_start)
>  		par->dirty_lines_start = y;

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