All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hui Su" <sh_def@163.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] staging: fbtft: make dirty_lock IRQ-safe
Date: Fri, 07 Aug 2026 15:27:03 +0000	[thread overview]
Message-ID: <20260807152703.57E851F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260807150953.2811933-3-sh_def@163.com>

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 <sh_def@163.com>

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/20260804173712.176017-1-sh_def@163.com/

> 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/20260807150953.2811933-3-sh_def@163.com?part=1

  reply	other threads:[~2026-08-07 15:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 15:09 [PATCH v2] staging: fbtft: make dirty_lock IRQ-safe Hui Su
2026-08-07 15:27 ` sashiko-bot [this message]
2026-08-08  2:59 ` Nam Cao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260807152703.57E851F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sh_def@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.