From: Petr Mladek <pmladek@suse.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
sched-ext@lists.linux.dev, netdev@vger.kernel.org,
"David S . Miller" <davem@davemloft.net>,
Andrea Righi <arighi@nvidia.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Ben Segall <bsegall@google.com>,
Breno Leitao <leitao@debian.org>,
Changwoo Min <changwoo@igalia.com>,
David Vernet <void@manifault.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Eric Dumazet <edumazet@google.com>,
Ingo Molnar <mingo@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
John Ogness <john.ogness@linutronix.de>,
Juri Lelli <juri.lelli@redhat.com>,
Paolo Abeni <pabeni@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Simon Horman <horms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>, Tejun Heo <tj@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Vlad Poenaru <vlad.wing@gmail.com>
Subject: Re: [PATCH 1/2] bug: Provide WARN_ON.*DEFERRED() macros for console deferred output
Date: Tue, 30 Jun 2026 11:21:53 +0200 [thread overview]
Message-ID: <akOKsdOhfBBqVUhI@pathway.suse.cz> (raw)
In-Reply-To: <20260624152431.Ufq0jT8r@linutronix.de>
On Wed 2026-06-24 17:24:31, Sebastian Andrzej Siewior wrote:
> On 2026-06-24 11:17:31 [+0200], Petr Mladek wrote:
> > For Linus, it was a no-go, definitely.
> …
> > I would vote for adding the WARN_*DEFERRED() into the scheduler code
> > at least until majority of console drivers are converted to nbcon API.
>
> I see four nbcon serial console drivers (+netconsole, + drm_log). We
> have at least four times that many console drivers. What is the
> majority from your point of view? The 8250 should cover all of x86.
Good question. IMHO, there are about 100 console drivers:
$> git grep "struct console.*= {" | wc -l
107
But I guess that many of them are some old rarely used ones.
I tried to google amount of market share from various architectures
and it seems that most spread are: arm, x86_64, and risc-v.
Arm might already be mostly covered by pl011.
x86_64 will be covered by 8250.
I am not sure about risc-v. It seems that it might use 8250 as well
at least in virtual machines. Also there is drivers/tty/hvc/hvc_riscv_sbi.c.
Hmm, 8250 might the breakpoint. Maybe, we could leave the rest as a
motivation to convert the console driver instead of adding workarounds
using the printk_deferred() mechanism.
That said, AFAIK, the netconsole is often used when the device does
not have a serial console. And it is pity that it does not have
the .write_atomic callbacks implemented.
Best Regards,
Petr
next prev parent reply other threads:[~2026-06-30 9:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 14:26 [PATCH 0/2] sched: Introduce and use deferred WARNs in sched Sebastian Andrzej Siewior
2026-06-23 14:26 ` [PATCH 1/2] bug: Provide WARN_ON.*DEFERRED() macros for console deferred output Sebastian Andrzej Siewior
2026-06-23 14:54 ` K Prateek Nayak
2026-06-24 6:26 ` Sebastian Andrzej Siewior
2026-06-24 9:17 ` Petr Mladek
2026-06-24 15:24 ` Sebastian Andrzej Siewior
2026-06-30 9:21 ` Petr Mladek [this message]
2026-06-23 15:12 ` Andrew Morton
2026-06-23 15:49 ` Petr Mladek
2026-06-24 8:37 ` Breno Leitao
2026-06-24 11:03 ` Sebastian Andrzej Siewior
2026-06-24 9:31 ` Peter Zijlstra
2026-06-24 10:08 ` Sebastian Andrzej Siewior
2026-06-24 14:27 ` sashiko-bot
2026-06-23 14:26 ` [PATCH 2/2] sched: Use WARN_ON.*_DEFERRED() Sebastian Andrzej Siewior
2026-06-24 14:27 ` sashiko-bot
2026-06-24 9:33 ` [PATCH 0/2] sched: Introduce and use deferred WARNs in sched Peter Zijlstra
2026-07-01 15:31 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akOKsdOhfBBqVUhI@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=arighi@nvidia.com \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=bsegall@google.com \
--cc=changwoo@igalia.com \
--cc=davem@davemloft.net \
--cc=dietmar.eggemann@arm.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sched-ext@lists.linux.dev \
--cc=senozhatsky@chromium.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vlad.wing@gmail.com \
--cc=void@manifault.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.