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
