[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84y0ykyqf6.fsf@jogness.linutronix.de>
Date: Wed, 05 Feb 2025 23:37:25 +0106
From: John Ogness <john.ogness@...utronix.de>
To: paulmck@...nel.org, Petr Mladek <pmladek@...e.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, rcu@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-team@...a.com, rostedt@...dmis.org,
Frederic Weisbecker <frederic@...nel.org>, Thomas Gleixner
<tglx@...utronix.de>, Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko
<andrii@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Masami Hiramatsu <mhiramat@...nel.org>, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH rcu v2] 4/5] rcu-tasks: Move RCU Tasks self-tests to
core_initcall()
On 2025-02-05, John Ogness <john.ogness@...utronix.de> wrote:
>> OK, so I don't need to add "if (IS_ENABLED(CONFIG_PREEMPT_RT))" to guard
>> it, then?
>
> For !CONFIG_PREEMPT_RT, if there are legacy consoles registered,
> pr_flush() will additionally perform a blocking lock on the
> console_lock.
Sorry, I was just thinking about the flushing component of
pr_flush(). Later in the function it takes the console_lock even for
CONFIG_PREEMPT_RT. So please do _not_ have a guard.
pr_flush() should never hang on the console_lock during shutdown, but if
does, that is something that will need to be debugged and fixed.
@pmladek: Looking forward to reading your input on this.
John
Powered by blists - more mailing lists