From: Breno Leitao <leitao@debian.org>
To: John Ogness <john.ogness@linutronix.de>
Cc: Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ryan Roberts <ryan.roberts@arm.com>,
printk@lists.linux.dev, linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH printk 3/6] printk: Evaluate flush policy in nbcon_allow_unsafe_takeover()
Date: Mon, 9 Nov 2026 08:47:15 -0800 [thread overview]
Message-ID: <avH1ZVs2Hyx62jgQ@gmail.com> (raw)
In-Reply-To: <87qzgunkof.fsf@jogness.linutronix.de>
On Mon, Nov 09, 2026 at 03:34:32PM +0106, John Ogness wrote:
> On 2026-11-09, Breno Leitao <leitao@debian.org> wrote:
> > That is coming from:
> >
> > 550 static int nbcon_context_try_acquire_hostile(struct nbcon_context *ctxt,
> > 551 struct nbcon_state *cur)
> > 552 {
> > 553 unsigned int cpu = smp_processor_id();
> > 554 struct console *con = ctxt->console;
> > 555 struct nbcon_state new;
> > 556
> > 557 if (!ctxt->allow_unsafe_takeover)
> > 558 return -EPERM;
> > 559
> > 560 /* Ensure caller is allowed to perform unsafe hostile takeovers. */
> > 561 if (WARN_ON_ONCE(ctxt->prio != NBCON_PRIO_PANIC))
> > 562 return -EPERM;
>
> Wow, you managed to get a hostile takeover. Out of curiousity, do you
> know how dangerous this really is? Can this basically just result in
> garbage on the network? Or is there dangers of running into the forest
> with NULL or garbage pointers? And is the danger acceptable?
Sure, I was playing with different scenarios, and this was done with a
test module that forces the takeover:
1) Acquire netcon_ext with nbcon_device_try_acquire(), so the console
is owned at NORMAL priority and in an unsafe state
2) mdelay() for a few seconds without releasing it (simulating
a possible netpoll busy TX queue -- or some other networkdelay)
3) echo b > /proc/sysrq-trigger from another CPU
--breno
next prev parent reply other threads:[~2026-11-09 16:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 12:31 [PATCH printk 0/6] Introduce policies for unsafe flushing John Ogness
2026-11-09 12:31 ` [PATCH printk 1/6] printk: Introduce and specify flush reasons John Ogness
2026-11-09 16:37 ` kernel test robot
2026-11-09 12:31 ` [PATCH printk 2/6] console: Introduce unsafe flush policy flags John Ogness
2026-11-09 12:31 ` [PATCH printk 3/6] printk: Evaluate flush policy in nbcon_allow_unsafe_takeover() John Ogness
2026-11-09 14:08 ` Breno Leitao
2026-11-09 14:28 ` John Ogness
2026-11-09 16:47 ` Breno Leitao [this message]
2026-11-09 12:31 ` [PATCH printk 4/6] printk: Remove nbcon_atomic_flush_unsafe() John Ogness
2026-11-09 12:31 ` [PATCH printk 5/6] printk: Add panic+kexec flush point John Ogness
2026-11-09 12:31 ` [PATCH printk 6/6] netconsole: Always perform unsafe flushing on panic/kdb/restart John Ogness
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=avH1ZVs2Hyx62jgQ@gmail.com \
--to=leitao@debian.org \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=printk@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=ryan.roberts@arm.com \
--cc=senozhatsky@chromium.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®