linux-kernel - Re: [PATCH 0/3][RFC] trace_printk() using percpu buffers

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:	Mon, 10 Oct 2011 09:06:03 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 0/3][RFC] trace_printk() using percpu buffers

On Mon, 2011-10-10 at 15:03 +0200, Peter Zijlstra wrote:
> On Mon, 2011-10-10 at 08:31 -0400, Steven Rostedt wrote:
> 
> > > > By default, it still uses the single buffer protected by a spinlock
> > > > and an atomic (for NMIs). The NMI case can cause dropped prints if
> > > > the NMI happens while a trace_printk() is processing.
> > > 
> > > Why bother keeping that?
> > 
> > Because very few developers debug nmi's. printk is known not to work
> > there.
> > 
> > I still find it useful to have without having to switch on a config
> > option or kernel command line.
> 
> But its also a massive scalability fail. There's simply no sane reason
> to keep the shared buffer trace_printk() implementation.

It was created as a "fast printk". Printk has the same scalability
issues, and other issues as well. It matters what you are debugging and
in most cases the single buffer has worked fine.

Nobody has yet to complain about it. Except for you when I told you how
it worked. ;)



> > That way, you could set this option and forget about it.
> 
> Well, if all we have is the per-cpu option I'm fine either way.

Good! This patch set improves trace_printk() from what it currently is
to something that will work for you and not break the way it use to work
for others.

I'll keep this patchset as is.

Thanks!

-- Steve


--
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/