[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <oc46gdpmmlly5o44obvmoatfqo5bhpgv7pabpvb6sjuqioymcg@gjsma3ghoz35>
Date: Wed, 10 Sep 2025 11:26:45 -0700
From: Breno Leitao <leitao@...ian.org>
To: Petr Mladek <pmladek@...e.com>
Cc: John Ogness <john.ogness@...utronix.de>,
Mike Galbraith <efault@....de>, Simon Horman <horms@...nel.org>, kuba@...nel.org,
calvin@...nvd.org, Pavel Begunkov <asml.silence@...il.com>,
Johannes Berg <johannes@...solutions.net>, paulmck@...nel.org, LKML <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org, boqun.feng@...il.com,
Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: netconsole: HARDIRQ-safe -> HARDIRQ-unsafe lock order warning
On Wed, Sep 10, 2025 at 05:12:43PM +0200, Petr Mladek wrote:
> On Wed 2025-09-10 14:28:40, John Ogness wrote:
> > @pmladek: We could introduce a new console flag (NBCON_ATOMIC_UNSAFE) so
> > that the callback is only used by nbcon_atomic_flush_unsafe().
>
> This might be an acceptable compromise. It would try to emit messages
> only at the very end of panic() as the last desperate attempt.
>
> Just to be sure, what do you mean with unsafe?
>
> + taking IRQ unsafe locks?
Taking IRQ unsafe locks is the major issue we have in netconsole today.
Basically the drivers can implement IRQ unsafe locks in their
.ndo_start_xmit() callback, and in some cases those are IRQ unsafe,
which doesn't match with .write_atomic(), which expect all the inner
locks to be IRQ safe.
Powered by blists - more mailing lists