Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 8 Feb 2022 11:15:15 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v3 4/4] printk: Drop console_sem during panic |
| |
On (22/02/04 10:53), Stephen Brennan wrote: > Sergey Senozhatsky <senozhatsky@chromium.org> writes: > > 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? > > We need to drop console_sem before returning, since the whole benefit > here is to increase the chance that console_sem is unlocked when the > panic_cpu halts this CPU.
Yes, that makes sense.
> in the handover case, there's another cpu waiting, and we're essentially > transferring the console_sem ownership to that cpu, so we explicitly > return and skip the unlocking portion. > > Does this need some comments to clarify it?
No. Everything looks good. Thanks.
| ![\](/images/icornerr.gif) |