Messages in this thread | | | Date | Mon, 26 Feb 2024 17:47:18 +0530 | Subject | Re: [PATCH] printk: Update @console_may_schedule in console_trylock_spinning() | From | Mukesh Ojha <> |
| |
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
| |