Re: [PATCH] printk: Add atomic context check inside console_unlock()

[John Ogness <john.ogness@linutronix.de>]

On 2024-02-22, Mukesh Ojha <quic_mojha@quicinc.com> wrote:
> Situation of schedule while atomic context can happen in a
> scenario if CPU-Y executing a async probe of ufs and while
> printing a line it is started spinning for console lock
> after preemption disable on CPU-Y and later it got the handover
> of console lock from CPU-X and in console_unlock() it get
> schedule with preempt disable as console_may_schedule was one
> and due to which do_cond_resched was one.

Nice catch. But I think the below patch is the appropriate fix:

John Ogness

-------8<--------
Subject: [PATCH] printk: Update @console_may_schedule in
 console_trylock_spinning()

console_trylock_spinning() may takeover the console lock from a
scheduable context. Update @console_may_schedule to make sure it
reflects a trylock acquire.

Reported-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/lkml/20240222090538.23017-1-quic_mojha@quicinc.com
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
 kernel/printk/printk.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1685a71f3f71..1612b50b2374 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2020,6 +2020,12 @@ static int console_trylock_spinning(void)
 	 */
 	mutex_acquire(&console_lock_dep_map, 0, 1, _THIS_IP_);
 
+	/*
+	 * Update @console_may_schedule for trylock because the previous
+	 * owner may have been scheduable.
+	 */
+	console_may_schedule = 0;
+
 	return 1;
 }
 

base-commit: e7081d5a9d976b84f61f497316d7c940a4a2e67a
-- 
2.30.2