[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ilnrn06u.fsf@jogness.linutronix.de>
Date: Wed, 20 Jul 2022 19:56:01 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] printk: Skip console drivers on PREEMPT_RT.
On 2022-07-20, Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
>> > --- 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)) {
>> > + up_console_sem();
>>
>> This should be:
>>
>> __console_unlock();
>
> Why?
Because that is the official function that performs the console
unlocking. With upcoming patches, that function does more. But even
without those patches, by directly calling up_console_sem() you are
leaving @console_locked set. The @console_locked variable is used by the
vt code to validate correct console locking.
I realize you are just copy/pasting from the condition above (checking
@console_suspended), but that condition is special. When consoles are
suspended, we still allow @console_sem to be locked/unlocked, but
without changing the locked status of the console. See suspend_console()
and resume_console() if you really want to see the gory details.
John
Powered by blists - more mailing lists