[PATCH v2] fbcon: Avoid cancel_delayed_work_sync() in atomic context

[PATCH v2] fbcon: Avoid cancel_delayed_work_sync() in atomic context

[Yao Yiqi]

From: Yao Yiqi <yaoyiqi3@huawei.com>

fbcon_cursor() can be reached from the console printing path, which runs
in atomic context. When the VT software cursor is enabled
(vc_cursor_type & CUR_SW), it calls fbcon_del_cursor_work(), which uses
cancel_delayed_work_sync() and therefore may sleep.

With CONFIG_DEBUG_ATOMIC_SLEEP enabled, the following is reported:

  BUG: sleeping function called from invalid context at kernel/workqueue.c:4722
  in_atomic(): 1, irqs_disabled(): 1, non_block: 0
  ...
  __cancel_work_sync
  fbcon_del_cursor_work
  fbcon_cursor
  hide_cursor
  vt_console_print
  console_unlock
  ...

Make the default helper safe: fbcon_del_cursor_work() only stops
blinking, using cancel_delayed_work(), which is allowed in any context.
Every "stop blinking" call site keeps using it, including fbcon_cursor().
Only fbcon_release(), which is about to free @par and must ensure that no
callback is still using it, calls the separate
fbcon_del_cursor_work_sync(). New call sites therefore get the safe
variant by default.

cancel_delayed_work() does not wait for a running callback, and
fb_flashcursor() re-arms itself, so also move the requeue into the
console_lock section. fbcon_del_cursor_work() callers hold
console_lock, which serializes them with the requeue and keeps the
non-synchronizing cancel effective.

Fixes: 3b0fb6ab25dd ("fbcon: Use delayed work for cursor")
Cc: stable@vger.kernel.org
Assisted-by: Opencode:deepseek-v4.1-flash
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
---
 drivers/video/fbdev/core/fbcon.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 94abbb5ac766..917ce9d641a1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -422,10 +422,14 @@ static void fb_flashcursor(struct work_struct *work)
 	par->bitops->cursor(vc, info, enable,
 			    get_fg_color(vc, info, c),
 			    get_bg_color(vc, info, c));
-	console_unlock();
 
+	/*
+	 * Re-arm under console_lock so that a concurrent
+	 * fbcon_del_cursor_work() cannot race with this requeue.
+	 */
 	queue_delayed_work(system_power_efficient_wq, &par->cursor_work,
 			   par->cur_blink_jiffies);
+	console_unlock();
 }
 
 static void fbcon_add_cursor_work(struct fb_info *info)
@@ -437,10 +441,30 @@ static void fbcon_add_cursor_work(struct fb_info *info)
 				   par->cur_blink_jiffies);
 }
 
+/*
+ * Stop the cursor blink.
+ *
+ * Does not wait for a callback that is already running, so it is safe to
+ * call from any context.
+ *
+ * console_lock serializes this with the requeue in fb_flashcursor();
+ * otherwise a running callback could re-arm the work.
+ */
 static void fbcon_del_cursor_work(struct fb_info *info)
 {
 	struct fbcon_par *par = info->fbcon_par;
 
+	cancel_delayed_work(&par->cursor_work);
+}
+
+/*
+ * Stop the cursor blink and wait for a running callback to finish before
+ * @par is freed.  May sleep, only for teardown paths.
+ */
+static void fbcon_del_cursor_work_sync(struct fb_info *info)
+{
+	struct fbcon_par *par = info->fbcon_par;
+
 	cancel_delayed_work_sync(&par->cursor_work);
 }
 
@@ -765,7 +789,7 @@ static void fbcon_release(struct fb_info *info)
 	if (info->fbcon_par) {
 		struct fbcon_par *par = info->fbcon_par;
 
-		fbcon_del_cursor_work(info);
+		fbcon_del_cursor_work_sync(info);
 		kfree(par->cursor_state.mask);
 		kfree(par->cursor_data);
 		kfree(par->cursor_src);
-- 
2.56.0

Re: [PATCH v2] fbcon: Avoid cancel_delayed_work_sync() in atomic context

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] fbcon: race in fbcon_del_cursor_work() lets fb_flashcursor() re-arm work
--

commit e9056993ba6eca270987e2b77d6a3977beffec71
Author: Yao Yiqi <yaoyiqi3@huawei.com>

fbcon: Avoid cancel_delayed_work_sync() in atomic context

This commit replaces cancel_delayed_work_sync() with cancel_delayed_work() in
fbcon_del_cursor_work() to avoid sleeping in atomic console printing contexts,
while adding fbcon_del_cursor_work_sync() for teardown in fbcon_release() and
moving the delayed work requeue in fb_flashcursor() inside console_lock.

> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 7720dfc80c165..066cd974ea3bb 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -422,10 +422,14 @@ static void fb_flashcursor(struct work_struct *work)
>  	par->bitops->cursor(vc, info, enable,
>  			    get_fg_color(vc, info, c),
>  			    get_bg_color(vc, info, c));
> -	console_unlock();
>  
> +	/*
> +	 * Re-arm under console_lock so that a concurrent
> +	 * fbcon_del_cursor_work() cannot race with this requeue.
> +	 */
>  	queue_delayed_work(system_power_efficient_wq, &par->cursor_work,
>  			   par->cur_blink_jiffies);
> +	console_unlock();
>  }
>  
>  static void fbcon_add_cursor_work(struct fb_info *info)
> @@ -437,10 +441,30 @@ static void fbcon_add_cursor_work(struct fb_info *info)
>  				   par->cur_blink_jiffies);
>  }
>  
> +/*
> + * Stop the cursor blink.
> + *
> + * Does not wait for a callback that is already running, so it is safe to
> + * call from any context.
> + *
> + * console_lock serializes this with the requeue in fb_flashcursor();
> + * otherwise a running callback could re-arm the work.
> + */
>  static void fbcon_del_cursor_work(struct fb_info *info)
>  {
>  	struct fbcon_par *par = info->fbcon_par;
>  
> +	cancel_delayed_work(&par->cursor_work);
> +}

[Severity: Medium]
Can fb_flashcursor() still race with fbcon_del_cursor_work() and re-arm
par->cursor_work after blinking has been stopped?

When par->cursor_work expires, process_one_work() clears
WORK_STRUCT_PENDING_BIT before invoking fb_flashcursor(). If a caller holding
console_lock (such as cursor_blink_store(), fbcon_blank(), fbcon_switch(),
fbcon_deinit(), or fbcon_cursor() with CUR_SW) runs fbcon_del_cursor_work()
after WORK_STRUCT_PENDING_BIT is cleared, but before the worker executes
console_trylock() in fb_flashcursor():

CPU0 (holding console_lock)          CPU1 (worker thread)
                                     process_one_work()
                                       /* clears WORK_STRUCT_PENDING_BIT */
                                       fb_flashcursor()
fbcon_del_cursor_work()
  cancel_delayed_work(&par->cursor_work)
  /* returns false without waiting */
console_unlock()
                                         ret = console_trylock();
                                         /* succeeds */

Because fb_flashcursor() only checks:

	if (!vc || !con_is_visible(vc) ||
	    fbcon_info_from_console(vc->vc_num) != info ||
	    vc->vc_deccm != 1) {
		console_unlock();
		return;
	}

and does not verify whether blinking is still supposed to be active (for
example fbcon_cursor_blink, vc->vc_cursor_type & CUR_SW,par->graphics /
KD_GRAPHICS, par->blank_state, or par->initialized), won't it draw the cursor
and call queue_delayed_work() to perpetually re-arm par->cursor_work?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027033422.585328-1-yyaqia@gmail.com?part=1

[PATCH v2] fbcon: Avoid cancel_delayed_work_sync() in atomic context

[Yao Yiqi]

From: Yao Yiqi <yaoyiqi3@huawei.com>

fbcon_cursor() can be reached from the console printing path, which runs
in atomic context. When the VT software cursor is enabled
(vc_cursor_type & CUR_SW), it calls fbcon_del_cursor_work(), which uses
cancel_delayed_work_sync() and therefore may sleep.

With CONFIG_DEBUG_ATOMIC_SLEEP enabled, the following is reported:

  BUG: sleeping function called from invalid context at kernel/workqueue.c:4722
  in_atomic(): 1, irqs_disabled(): 1, non_block: 0
  ...
  __cancel_work_sync
  fbcon_del_cursor_work
  fbcon_cursor
  hide_cursor
  vt_console_print
  console_unlock
  ...

Make the default helper safe: fbcon_del_cursor_work() only stops
blinking, using cancel_delayed_work(), which is allowed in any context.
Every "stop blinking" call site keeps using it, including fbcon_cursor().
Only fbcon_release(), which is about to free @par and must ensure that no
callback is still using it, calls the separate
fbcon_del_cursor_work_sync(). New call sites therefore get the safe
variant by default.

cancel_delayed_work() does not wait for a running callback, and
fb_flashcursor() re-arms itself, so also move the requeue into the
console_lock section. fbcon_del_cursor_work() callers hold
console_lock, which serializes them with the requeue and keeps the
non-synchronizing cancel effective.

Fixes: 3b0fb6ab25dd ("fbcon: Use delayed work for cursor")
Cc: stable@vger.kernel.org
Assisted-by: Opencode:deepseek-v4.1-flash
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
---
Sorry for the last email, I forgot to write changelog. This email has no
code modification, it just adds the changelog.

Changes in v2:
- Reworked per review (sashiko-AI): do not guess the context with
  in_interrupt()/irqs_disabled().  fbcon_del_cursor_work() is now
  non-synchronizing by default and therefore safe from any context;
  fbcon_del_cursor_work_sync() is added for fbcon_release(), the only
  path that frees @par and needs to drain the work.
- Move the requeue in fb_flashcursor() under console_lock so a running
  callback cannot re-arm the work after the non-synchronizing cancel.

 drivers/video/fbdev/core/fbcon.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 94abbb5ac766..917ce9d641a1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -422,10 +422,14 @@ static void fb_flashcursor(struct work_struct *work)
 	par->bitops->cursor(vc, info, enable,
 			    get_fg_color(vc, info, c),
 			    get_bg_color(vc, info, c));
-	console_unlock();
 
+	/*
+	 * Re-arm under console_lock so that a concurrent
+	 * fbcon_del_cursor_work() cannot race with this requeue.
+	 */
 	queue_delayed_work(system_power_efficient_wq, &par->cursor_work,
 			   par->cur_blink_jiffies);
+	console_unlock();
 }
 
 static void fbcon_add_cursor_work(struct fb_info *info)
@@ -437,10 +441,30 @@ static void fbcon_add_cursor_work(struct fb_info *info)
 				   par->cur_blink_jiffies);
 }
 
+/*
+ * Stop the cursor blink.
+ *
+ * Does not wait for a callback that is already running, so it is safe to
+ * call from any context.
+ *
+ * console_lock serializes this with the requeue in fb_flashcursor();
+ * otherwise a running callback could re-arm the work.
+ */
 static void fbcon_del_cursor_work(struct fb_info *info)
 {
 	struct fbcon_par *par = info->fbcon_par;
 
+	cancel_delayed_work(&par->cursor_work);
+}
+
+/*
+ * Stop the cursor blink and wait for a running callback to finish before
+ * @par is freed.  May sleep, only for teardown paths.
+ */
+static void fbcon_del_cursor_work_sync(struct fb_info *info)
+{
+	struct fbcon_par *par = info->fbcon_par;
+
 	cancel_delayed_work_sync(&par->cursor_work);
 }
 
@@ -765,7 +789,7 @@ static void fbcon_release(struct fb_info *info)
 	if (info->fbcon_par) {
 		struct fbcon_par *par = info->fbcon_par;
 
-		fbcon_del_cursor_work(info);
+		fbcon_del_cursor_work_sync(info);
 		kfree(par->cursor_state.mask);
 		kfree(par->cursor_data);
 		kfree(par->cursor_src);
-- 
2.56.0

Re: [PATCH v2] fbcon: Avoid cancel_delayed_work_sync() in atomic context

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] fbcon: race between fbcon_del_cursor_work() and dequeued fb_flashcursor()
--

commit 7fd3c01c297e05df19b561b8622916f2e7e0e858
Author: Yao Yiqi <yaoyiqi3@huawei.com>

fbcon: Avoid cancel_delayed_work_sync() in atomic context

This commit switches fbcon_del_cursor_work() to use cancel_delayed_work() so
it can be called safely from atomic console printing contexts, while adding
fbcon_del_cursor_work_sync() for teardown in fbcon_release(). It also moves
the queue_delayed_work() call in fb_flashcursor() inside the console_lock
critical section.

> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 7720dfc80c165..066cd974ea3bb 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -422,10 +422,14 @@ static void fb_flashcursor(struct work_struct *work)
>  	par->bitops->cursor(vc, info, enable,
>  			    get_fg_color(vc, info, c),
>  			    get_bg_color(vc, info, c));
> -	console_unlock();
>  
> +	/*
> +	 * Re-arm under console_lock so that a concurrent
> +	 * fbcon_del_cursor_work() cannot race with this requeue.
> +	 */
>  	queue_delayed_work(system_power_efficient_wq, &par->cursor_work,
>  			   par->cur_blink_jiffies);
> +	console_unlock();
>  }
>  
>  static void fbcon_add_cursor_work(struct fb_info *info)
> @@ -437,10 +441,30 @@ static void fbcon_add_cursor_work(struct fb_info *info)
>  				   par->cur_blink_jiffies);
>  }
>  
> +/*
> + * Stop the cursor blink.
> + *
> + * Does not wait for a callback that is already running, so it is safe to
> + * call from any context.
> + *
> + * console_lock serializes this with the requeue in fb_flashcursor();
> + * otherwise a running callback could re-arm the work.
> + */
>  static void fbcon_del_cursor_work(struct fb_info *info)
>  {
>  	struct fbcon_par *par = info->fbcon_par;
>  
> +	cancel_delayed_work(&par->cursor_work);
> +}

[Severity: Medium]
Can fb_flashcursor() still race with fbcon_del_cursor_work() and re-arm
par->cursor_work after blinking has been stopped?

In kernel/workqueue.c, process_one_work() clears WORK_STRUCT_PENDING_BIT via
set_work_pool_and_clear_pending() before invoking the work callback, and
fb_flashcursor() does not acquire console_lock until it calls
console_trylock():

CPU 0 (workqueue)                     CPU 1 (holding console_lock)
-----------------                     ----------------------------
process_one_work()
  set_work_pool_and_clear_pending()
  fb_flashcursor()
                                      fbcon_del_cursor_work(info)
                                        cancel_delayed_work(&par->cursor_work)
                                          /* returns false, not pending */
                                      console_unlock()
    console_trylock() /* succeeds */
    ...
    par->bitops->cursor(...)
    queue_delayed_work(..., &par->cursor_work, ...)
    console_unlock()

Once fb_flashcursor() acquires console_lock in drivers/video/fbdev/core/fbcon.c,
it only checks:

	if (!vc || !con_is_visible(vc) ||
	    fbcon_info_from_console(vc->vc_num) != info ||
	    vc->vc_deccm != 1) {
		console_unlock();
		return;
	}

It does not check whether cursor blinking was stopped by:

- cursor_blink_store() setting fbcon_cursor_blink = false before calling
  fbcon_del_cursor_work(info)
- fbcon_cursor() seeing (vc->vc_cursor_type & CUR_SW) and calling
  fbcon_del_cursor_work(info)
- fbcon_blank() or fbcon_switch() stopping the cursor when blanking or
  switching to KD_GRAPHICS mode

Because cancel_delayed_work() does not wait for or disable an already-dequeued
work item and fbcon_del_cursor_work() records no state under console_lock,
wouldn't fb_flashcursor() draw the cursor and re-arm par->cursor_work
indefinitely?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027034716.588174-1-yyaqia@gmail.com?part=1