kernel/printk/printk.c | 6 ++++++ 1 file changed, 6 insertions(+)
console_trylock_spinning() may takeover the console lock from a
schedulable 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
Fixes: dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes")
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 schedulable.
+ */
+ console_may_schedule = 0;
+
return 1;
}
base-commit: e7081d5a9d976b84f61f497316d7c940a4a2e67a
--
2.30.2
On Mon 2024-02-26 13:07:24, John Ogness wrote:
> console_trylock_spinning() may takeover the console lock from a
> schedulable 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
> Fixes: dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes")
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
Makes perfect sense:
Reviewed-by: Petr Mladek <pmladek@suse.com>
JFYI, the patch has been committed into printk/linux.git, for-6.9
branch.
I am going to give it a spin in for-next and get it into 6.9
either in the 2nd half of the merge window or in rc1.
Best Regards,
Petr
On 2/26/2024 5:31 PM, John Ogness wrote:
> console_trylock_spinning() may takeover the console lock from a
> schedulable 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
> Fixes: dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes")
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
Thanks for prompt response..
Yes, this looks fine..
As spinning code runs with preemption disabled context
and should reset the console_may_schedule to 0 .
what if console_trylock_spinning() gets the lock which makes
console_may_schedule =1 and it is still schedulable ?
-Mukesh
> ---
> 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 schedulable.
> + */
> + console_may_schedule = 0;
> +
> return 1;
> }
>
>
> base-commit: e7081d5a9d976b84f61f497316d7c940a4a2e67a
On 2024-02-26, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > what if console_trylock_spinning() gets the lock which makes > console_may_schedule =1 and it is still schedulable ? I am afraid I do not understand the question. console_trylock_spinning() is only called from the printk caller context. In this context, console_may_schedule is always set to 0. Only if another context acquires the console lock per sleeping wait, console_lock(), can console_may_schedule be set to 1. Note that the value of console_may_schedule is only relevant for the console lock owner when console_unlock() is called. That is why its value is set when locking the console (or, with this patch, when transferring console lock ownerhip). John
On 2/26/2024 6:32 PM, John Ogness wrote: > On 2024-02-26, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >> what if console_trylock_spinning() gets the lock which makes >> console_may_schedule =1 and it is still schedulable ? > > I am afraid I do not understand the question. > > console_trylock_spinning() is only called from the printk caller > context. In this context, console_may_schedule is always set to 0. > > Only if another context acquires the console lock per sleeping wait, > console_lock(), can console_may_schedule be set to 1. > > Note that the value of console_may_schedule is only relevant for the > console lock owner when console_unlock() is called. That is why its > value is set when locking the console (or, with this patch, when > transferring console lock ownerhip). I overlooked it, thanks. Patch LGTM. Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> -Mukesh > > John
© 2016 - 2026 Red Hat, Inc.