Re: [PATCH v2] printk: Skip console drivers on PREEMPT_RT.

[Petr Mladek]

On Thu 2022-07-21 08:50:38, Sebastian Andrzej Siewior wrote:
> printk might be invoked in a context with disabled interrupts and or
> preemption and additionally disables interrupts before it invokes the
> console drivers. This is behaviour is not compatible with PREEMPT_RT.

Maybe I do not understand it correctly. It sounds like we could not
disable interrupts when interrupts or preemption is already disabled.
Like nested disablement of interrupts is bad.

Is this a generic rule? Is is about the nesting?

Or is is somehow specific to the console drivers called from printk()
directly? Do you always want to disable here because it might
be an atomic context and they might take too long?

I guess that the sentence "additionally disables interrupts before
it invokes the console drivers" is not really important" and it confused me.


> Disable console printing until the return of atomic consoles and the
> printing thread. This allows to retrieve the log buffer from user space
> which is not possible by disable printk.

I guess that this is for RT tree because the kthreads and the atomic
consoles are still not in the mainline.

> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2843,6 +2843,16 @@ void console_unlock(void)
>  	}
>  
>  	/*
> +	 * On PREEMPT_RT it is not possible to invoke console drivers with
> +	 * disabled interrupts and or preemption. Therefore all drivers are
> +	 * skipped and the output can be retrieved from the buffer.
> +	 */
> +	if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
> +		__console_unlock();
> +		return;
> +	}

Do you want this even in panic() or early boot?

AFAIK, only the serial console has atomic write() callback in the RT
tree. Is this the only console used by RT kernel users in practice?


> +	/*
>  	 * Console drivers are called with interrupts disabled, so
>  	 * @console_may_schedule should be cleared before; however, we may
>  	 * end up dumping a lot of lines, for example, if called from

Best Regards,
Petr