linux-kernel - Re: [PATCH 0/3] ring-buffer: less locking and only disable preemption

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: <20081004084002.GE27624@elte.hu>
Date:	Sat, 4 Oct 2008 10:40:02 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>
Subject: Re: [PATCH 0/3] ring-buffer: less locking and only disable
	preemption

* Steven Rostedt <rostedt@...dmis.org> wrote:

> Ingo,
> 
> These patches need to be put through the ringer. Could you add them to 
> your ring-buffer branch, so we can test them out before putting them 
> into your master branch.

hey, in fact your latest iteration already tested out so well on a wide 
range of boxes that i've merged it all into tip/tracing/core already.

I'll reuse tip/tracing/ring-buffer for these latest 3 patches (merge it 
up to tip/tracing/core and add these three patches) but it's a delta, 
i.e. the whole ring-buffer approach is ready for prime time i think.

Hm, do we do deallocation of the buffers already when we switch tracers?

> The following patches bring the ring buffer closer to a lockless 
> solution. They move the locking only to the actual moving the 
> tail/write pointer from one page to the next. Interrupts are now 
> enabled during most of the writes.

very nice direction!

> A lot of the locking protection is still within the ftrace 
> infrastructure. The last patch takes some of that away.
> 
> The function tracer cannot be reentrant just due to the nature that it 
> traces everything, and can cause recursion issues.

Correct, and that's by far the yuckiest aspect of it. And there's 
another aspect: NMIs. We've still got the tip/tracing/nmisafe angle with 
these commits:

 d979781: ftrace: mark lapic_wd_event() notrace
 c2c27ba: ftrace: ignore functions that cannot be kprobe-ed
 431e946: ftrace: do not trace NMI contexts
 1eda930: x86, tracing, nmisafe: fix threadinfo_ -> TI_ rename fallout
 84c2ca9: sched: sched_clock() improvement: use in_nmi()
 0d84b78: x86 NMI-safe INT3 and Page Fault
 a04464b: x86_64 page fault NMI-safe
 b335389: Change avr32 active count bit
 a581cbd: Change Alpha active count bit
 eca0999: Stringify support commas

but i'm not yet fully convinced about the NMI angle, the practical cross 
section to random lowlevel x86 code is wider than any sched_clock() 
impact for example. We might be best off avoiding it: force-disable the 
NMI watchdog when we trace?

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