[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aTmN9fUiJt5gm6Vq@pathway>
Date: Wed, 10 Dec 2025 16:12:53 +0100
From: Petr Mladek <pmladek@...e.com>
To: Chris Down <chris@...isdown.name>
Cc: linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>,
John Ogness <john.ogness@...utronix.de>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Tony Lindgren <tony.lindgren@...ux.intel.com>, kernel-team@...com
Subject: Re: [PATCH v8 06/21] printk: nbcon: Synchronise console
unregistration against atomic flushers
On Fri 2025-11-28 03:43:32, Chris Down wrote:
> The nbcon atomic flush path in __nbcon_atomic_flush_pending_con() calls
> nbcon_emit_next_record(), which uses console_srcu_read_flags() to read
> the console flags. console_srcu_read_flags() expects to be called under
> console_srcu_read_lock(), but the atomic flush path does not hold this
> lock.
__nbcon_atomic_flush_pending_con() seems to be called in the following
code paths:
+ __nbcon_atomic_flush_pending()
+ nbcon_atomic_flush_pending_con()
+ __nbcon_atomic_flush_pending_con()
+ nbcon_device_release()
+ __nbcon_atomic_flush_pending_con()
+ kdb_msg_write() # new in 6.19-rc1
+ nbcon_kdb_release()
+ __nbcon_atomic_flush_pending_con()
And all three callers take console_srcu_read_lock() because
they need it for other reasons. So, we should be on the safe
side and do not need this change.
Or do I miss some code path, please?
Best Regards,
Petr
Powered by blists - more mailing lists