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.0812191810110.26234@gandalf.stny.rr.com>
Date:	Fri, 19 Dec 2008 18:27:23 -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>,
	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 Fri, 19 Dec 2008, Ingo Molnar wrote:

> 
> * Pekka Paalanen <pq@....fi> wrote:
> 
> > > I'm actually against the idea of reseting a trace everytime we enable it.
> > > That is:
> > > 
> > > echo 1 > /debug/tracing/tracing_enabled
> > > 
> > > This should not reset the tracer. I actually do tracing where I disable 
> > > and enable it around areas I am interested in. I want all tracing, not 
> > > just the last one.
> > 
> > But doesn't this go against the fact, that you need to write 0 there to 
> > be able to change the ring buffer size?
> 
> hm, that ftrace behavior is silly. Steve, i think i mentioned this a long 
> time ago and i thought it got fixed? Changing the ring buffer size is a 
> slow op, it should include an implicit reset and should be plug-and-play 
> with no dependencies of having to stop the trace or something.

I think you are referencing a different issue, where we passed in a NULL 
buffer pointer and expected it to be resized. I still think that should 
not return a success, but that's a different issue altogether.

Before the ring buffer, the only safe way to resize the buffer was to 
switch the tracer to none (aka nop).  Now, the only thing you need to do 
is disable tracing. This is probably a good thing since it forces the user 
to stop tracing, otherwise the tracing will stop during the resize anyway, 
and the user will wonder why they lost data.

Resizing is a dangerous operation to do while tracing. Right now ftrace 
enforces the the protection of writes to the ring buffer during resize 
(the ftrace infrastructure does, the plugins do not need to worry about 
it).

Now that we have other ways to disable writing to the ring buffer, we can 
move that down to the ring buffer layer. When the ring buffer was 
originaly written, there was no such method to stop writing. What would 
need to be done now, is the ring buffers would disable writing to all CPU 
buffers, do a synchronize sched, since writing requires preemption 
disabled. Then we would need to grab all the reader spin locks for each 
cpu buffer (that will be ugly :-( ), and then we could safely change the 
size of the buffers.

I could easily write this up. I'll see if I can get to it after I release 
the -rt trees. But like I said, there will be time when tracing will be 
stopped, and it would be a good idea to make the user stop it so they do 
not get confused about why they are missing trace output after they did a 
resize.

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