Messages in this thread | | | Date | Fri, 4 Feb 2022 13:04:41 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v3 4/4] printk: Drop console_sem during panic |
| |
On (22/02/01 10:58), Stephen Brennan wrote: > +/* > + * Return true when this CPU should unlock console_sem without pushing all > + * messages to the console. This reduces the chance that the console is > + * locked when the panic CPU tries to use it. > + */ > +static bool abandon_console_lock_in_panic(void) > +{ > + if (!panic_in_progress()) > + return false; > + > + /* > + * We can use raw_smp_processor_id() here because it is impossible for > + * the task to be migrated to the panic_cpu, or away from it. If > + * panic_cpu has already been set, and we're not currently executing on > + * that CPU, then we never will be. > + */ > + return atomic_read(&panic_cpu) != raw_smp_processor_id(); > +} > + > /* > * Can we actually use the console at this time on this cpu? > * > @@ -2746,6 +2765,10 @@ void console_unlock(void) > if (handover) > return; > > + /* Allow panic_cpu to take over the consoles safely */ > + if (abandon_console_lock_in_panic()) > + break;
Sorry, why not just `return` like in handover case?
> + > if (do_cond_resched) > cond_resched(); > } > @@ -2763,7 +2786,7 @@ void console_unlock(void) > * flush, no worries. > */ > retry = prb_read_valid(prb, next_seq, NULL); > - if (retry && console_trylock()) > + if (retry && !abandon_console_lock_in_panic() && console_trylock()) > goto again; > } > EXPORT_SYMBOL(console_unlock);
| |