From: Mike Galbraith <efault@gmx.de>
To: Breno Leitao <leitao@debian.org>
Cc: Pavel Begunkov <asml.silence@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
paulmck@kernel.org, LKML <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org, boqun.feng@gmail.com
Subject: Re: netconsole: HARDIRQ-safe -> HARDIRQ-unsafe lock order warning
Date: Fri, 22 Aug 2025 05:54:28 +0200 [thread overview]
Message-ID: <5b509b1370d42fd0cc109fc8914272be6dcfcd54.camel@gmx.de> (raw)
In-Reply-To: <tx2ry3uwlgqenvz4fsy2hugdiq36jrtshwyo4a2jpxufeypesi@uceeo7ykvd6w>
On Thu, 2025-08-21 at 10:35 -0700, Breno Leitao wrote:
> > On Thu, Aug 21, 2025 at 05:51:59AM +0200, Mike Galbraith wrote:
> > > > --- a/drivers/net/netconsole.c
> > > > +++ b/drivers/net/netconsole.c
> > > > @@ -1952,12 +1952,12 @@ static void netcon_write_thread(struct c
> > > > static void netconsole_device_lock(struct console *con, unsigned long *flags)
> > > > {
> > > > /* protects all the targets at the same time */
> > > > - spin_lock_irqsave(&target_list_lock, *flags);
> > > > + spin_lock(&target_list_lock);
> >
> > I personally think this target_list_lock can be moved to an RCU lock.
> >
> > If that is doable, then we probably make netconsole_device_lock()
> > to a simple `rcu_read_lock()`, which would solve this problem as well.
The bigger issue for the nbcon patch would seem to be the seemingly
required .write_atomic leading to landing here with disabled IRQs.
WRT my patch, seeing a hard RT crash on wired box cleanly logged with
your nbcon patch applied (plus my twiddle mentioned earlier) tells me
my patch has lost its original reason to exist. It's relevant to this
thread only in that those once thought to be RT specific IRQ disable
spots turned out to actually be RT agnostic wireless sore spots.
> > > > --- a/net/core/netpoll.c
> > > > +++ b/net/core/netpoll.c
> > > > @@ -58,6 +58,29 @@ static void zap_completion_queue(void);
> > > > static unsigned int carrier_timeout = 4;
> > > > module_param(carrier_timeout, uint, 0644);
> > > >
> > > > +DEFINE_PER_CPU(int, _netpoll_tx_running);
> > > > +EXPORT_PER_CPU_SYMBOL(_netpoll_tx_running);
> > > > +
> > > > +#define
> > > > netpoll_tx_begin(flags) \
> > > > + do
> > > > { \
> > > > + if (IS_ENABLED(CONFIG_PREEMPT_RT)
> > > > || \
> > > > +
> > > > IS_ENABLED(CONFIG_NETCONSOLE_NBCON)) \
> > > > + local_bh_disable();
> > > > \
> > > > + else
> > > > \
> > > > + local_irq_save(flags);
> > > > \
> > > > + this_cpu_write(_netpoll_tx_running,
> > > > 1); \
> > > > + } while (0)
> >
> > Why can't we just use local_bh_disable() in both cases?
Yeah, believe so.
> > >
> > > > @@ -246,7 +269,7 @@ static void refill_skbs(struct netpoll *
> > > > static void zap_completion_queue(void)
> > > > {
> > > > unsigned long flags;
> > > > - struct softnet_data *sd = &get_cpu_var(softnet_data);
> > > > + struct softnet_data *sd = this_cpu_ptr(&softnet_data);
> >
> > How do I check if this is safe to do ?
Too much water under the bridge, I don't recall my path to conclusion
reached, and it seems to no longer matter.
-Mike
next prev parent reply other threads:[~2025-08-22 3:54 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 4:14 Mike Galbraith
2025-08-14 10:16 ` Breno Leitao
2025-08-14 15:45 ` Pavel Begunkov
2025-08-15 0:23 ` Jakub Kicinski
2025-08-15 10:44 ` Pavel Begunkov
2025-08-15 16:42 ` Jakub Kicinski
2025-08-15 17:29 ` Breno Leitao
2025-08-15 17:33 ` Jakub Kicinski
2025-08-18 12:23 ` Breno Leitao
2025-08-15 19:10 ` Calvin Owens
2025-08-16 9:19 ` Mike Galbraith
2025-08-15 20:02 ` Pavel Begunkov
2025-08-18 12:10 ` Breno Leitao
2025-08-19 17:27 ` Breno Leitao
2025-08-20 12:31 ` Mike Galbraith
2025-08-20 17:36 ` Breno Leitao
2025-08-21 3:37 ` Mike Galbraith
2025-08-21 3:51 ` Mike Galbraith
2025-08-21 17:35 ` Breno Leitao
2025-08-22 3:54 ` Mike Galbraith [this message]
2025-08-26 12:43 ` Breno Leitao
2025-08-26 13:56 ` Mike Galbraith
2025-09-05 12:48 ` John Ogness
2025-09-06 2:32 ` Mike Galbraith
2025-09-08 13:30 ` John Ogness
2025-09-08 15:18 ` Mike Galbraith
2025-09-08 20:27 ` Calvin Owens
2025-09-09 15:49 ` Mike Galbraith
2025-09-10 15:51 ` Petr Mladek
2025-09-09 12:50 ` Breno Leitao
2025-09-10 12:22 ` John Ogness
2025-09-10 15:12 ` Petr Mladek
2025-09-10 18:26 ` Breno Leitao
2025-09-30 13:57 ` Calvin Owens
2025-09-30 14:23 ` John Ogness
2025-09-30 14:30 ` Sebastian Siewior
2025-09-30 17:35 ` Mike Galbraith
2025-10-01 6:00 ` Mike Galbraith
2025-09-11 13:03 ` John Ogness
2025-09-10 18:23 ` Breno Leitao
2025-09-11 13:13 ` John Ogness
2025-08-21 10:06 ` Mike Galbraith
2025-08-21 13:12 ` Mike Galbraith
2025-08-15 17:37 ` Calvin Owens
2025-08-26 14:10 ` Johannes Berg
2025-08-15 12:45 ` Mike Galbraith
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=5b509b1370d42fd0cc109fc8914272be6dcfcd54.camel@gmx.de \
--to=efault@gmx.de \
--cc=asml.silence@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®