linux-kernel - Re: [RFC PATCH 00/11] printk: safe printing in NMI context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1406181649190.2303@pobox.suse.cz>
Date:	Wed, 18 Jun 2014 16:53:14 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Petr Mladek <pmladek@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Dave Anderson <anderson@...hat.com>,
	Kay Sievers <kay@...y.org>, Michal Hocko <mhocko@...e.cz>,
	Jan Kara <jack@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 00/11] printk: safe printing in NMI context

On Wed, 18 Jun 2014, Paul E. McKenney wrote:

> > > > - both RCU stall detector and 'echo l > sysrq-trigger' can (and we've 
> > > >   seen it happening for real) cause a complete, undebuggable, silent hang 
> > > >   of machine (deadlock in NMI context)
> > > 
> > > I could easily add an option to RCU to allow people to tell it not to
> > > use NMIs to dump the stack.  Would that help?
> > 
> > Well, that would make unfortunately the information provided by RCU stall 
> > detector rather useless ... workqueue-based stack dumping is very unlikely 
> > to point its finger to the real offender, as it'd be coming way too late.
> 
> I would not use workqueues, but rather have the CPU detecting the
> stall grovel through the other CPUs' stacks, which is what I do now for
> architectures that don't support NMI-based stack dumps.  Would that be
> a reasonable approach?

That would indeed solve lockups induced by RCU stall detector (and we 
should convert sysrq stack dumping code to use the same mechanism 
afterwards).

But then, the kernel is still polluted by quite a few instances of

	WARN_ON(in_nmi())

	BUG_IN(in_nmi())

	if (in_nmi())
		printk(....)

which need to be fixed separately afterwards anyway.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/