linux-kernel - Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online

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.DEB.1.10.0812191912280.26234@gandalf.stny.rr.com>
Date:	Fri, 19 Dec 2008 19:29:30 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Pekka Paalanen <pq@....fi>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>,
	Markus Metzger <markus.t.metzger@...il.com>
Subject: Re: ftrace behaviour (was: [PATCH] ftrace: introduce
 tracing_reset_online_cpus() helper)

On Sat, 20 Dec 2008, Ingo Molnar wrote:
> 
> uhm, the user just resized the buffer - he will not be wondering about any 
> impact.

I can imagine some users that would ;-)

> 
> And that's why we should do a full reset: that makes it abundantly clear 
> what happened. We shouldnt pretend to be able to do something (seemless, 
> lightweight buffer size change with no visible impact) which we obviously 
> cannot reliably offer.

Some tracers, namely the latency ones (irqsoff and friends, as well as the 
sched wakeup) need to resize two buffers, and if this is done while 
tracing is enabled, the special "switch" operation can cause problems.
Keeping tracing on while resizing can be done, but it needs to done 
carefully.

> 
> Buffer resize is a slow op, and everyone realizes that. Most people will 
> in fact say: "hey, I didnt even need to reboot to change the trace buffer 
> size, cool!".

Exactly! Currently they will be happy that they do not need to reboot.

> 
> The current "only allow resizing while tracing is disabled" is an 
> unintuitive and counterproductive restriction - a borderline bug in fact.

Having to disable tracing to resize is much better than having to reboot.

I'm not defending that this is the way to go. I never planned on keeping 
this the defacto standard. I've been setting up infrastructure to allow 
for a seamless resize. If you think we should reset the buffers on resize, 
then that would be a great way for the user to know why they are missing 
**all** their data.

What I'm trying to say is that the more we allow during resize, the more 
likely there will be a critical bug that might lock up the system. The 
whole point about writing the ring buffer was to do it incrementally. 
Start out with being straight forward and simple, then we could add 
features as we understand things better.

IOW, I totally agree that we should make it as intuitive as possible. But 
this needs to be done step by step. I wrote 10 different versions of the 
ring buffer in a week. Most of them were complete rewrites. I want this to 
be as robust and powerful as you do, but I also want to be cautious about 
doing things that might crash the system.

Ftrace already had the infrastructure in place to protect against resize. 
I just used it to give me time to do other things with the ring buffer. 
I always planned on having the resize protection back inside the ring 
buffer code when I got around to it.

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