linux-kernel - Re: [RFC][PATCH] printk: Fixup the nmi printk mess

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]

Date:	Fri, 12 Jun 2015 16:28:05 +0200
From:	Petr Mladek <pmladek@...e.cz>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	jkosina@...e.cz, paulmck@...ux.vnet.ibm.com,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH] printk: Fixup the nmi printk mess

On Fri 2015-06-12 14:00:37, Peter Zijlstra wrote:
> On Thu, Jun 11, 2015 at 04:55:47PM +0200, Petr Mladek wrote:
> > > +	 * 'Consume' this chunk, avoids concurrent callers printing the same
> > > +	 * stuff.
> > > +	 */
> > > +	if (atomic_cmpxchg(&s->read, i, len) != i)
> > > +		goto again;
> > 
> > I think that this is racy:
> 
> Indeed. I'll think a bit on that.
> 
> > I think that ordering CPUs is not worth it. I would go back to the
> > first solution, add the @lock there, and double check races with
> > seq_buf().
> 
> You mean, provide printk_nmi_flush() but completely screw concurrency?
> And basically reserve it for a last ditch effort for getting crap out?

This looks much easier to me. We could call this only when the system
is going down.

Another possibility would be to ignore this race because it is rather
theoretical and it better to print some mess than nothing.

I wonder what Andrew thinks about it. I really admired the atomic
operations in the 2nd patch but I was also scared by them.

Note that I have already had two attempts to make printk() safe in
NMI. The first one was too precise, too complicated, and thus
rejected, see https://lkml.org/lkml/2014/6/10/388.

The second one was rather defensive and quite simple. It has not
been completely rejected but there is still some resistance to
accept non-trivial code for handling printk() in NMI, see
https://lkml.org/lkml/2015/5/29/699

I hope that your approach has a chance if we do not make it too
complicated. The big plus is that it generalizes the already used
solution for arch_trigger_all_cpu_backtrace() and the
1st variant was rather easy but quite functional.

Best Regards,
Petr
--
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/