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: <20081220043210.40758f36@daedalus.pq.iki.fi>
Date:	Sat, 20 Dec 2008 04:32:10 +0200
From:	Pekka Paalanen <pq@....fi>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	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>, pq@....fi
Subject: Re: ftrace behaviour (was: [PATCH] ftrace: introduce
 tracing_reset_online_cpus() helper)

On Fri, 19 Dec 2008 20:46:38 -0500 (EST)
Steven Rostedt <rostedt@...dmis.org> wrote:

> 
> On Sat, 20 Dec 2008, Pekka Paalanen wrote:
> 
> > On Fri, 19 Dec 2008 19:29:30 -0500 (EST)
> > Steven Rostedt <rostedt@...dmis.org> wrote:
> > 
> > I thought this was just about not having to do
> > 
> > $ echo 0 > tracing_enabled
> > $ echo 28764243 > buffer_size
> > $ echo 1 > tracing_enabled
> > 
> > and instead just do
> > 
> > $ echo 28764243 > buffer_size
> > 
> > which would do exactly the same, except being easier for the user.
> > Personally I've never dreamed of any kind of resize-in-flight.
> > 
> 
> To implement this at the ftrace level should be a trivial change. I'm just 
> saying that doing this at the "ring buffer" level might be a bit more 
> complex. The ring buffer has no idea of ftrace. It should not. It is at 
> a lower lever than ftrace. Although, I do think some of the protecting 
> that is done at the tracing level during resize should be moved down into 
> the ring buffer layer.

Aah, so you are saying that the buffer_size file (or whatever it was called)
is part of the ring buffer user API, and not tracing user API?

But the ring buffer is just a buffer, is it meaningful to adjust a ring
buffer size? I cannot tell tracing to go use a different buffer. And if
there will be other users of ring buffers, they would probably want to
have their own control over the buffer size.

As a user, I want to adjust *the* tracing ring buffer size, not some ring
buffer size.

Am I making any sense? I'm trying to say that in my opinion, the
buffer_size file does not belong to the "ring buffer" level. The upper
levels should decide whether and how it offers buffer resizing.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/