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:	Sat, 20 Dec 2008 03:38:22 +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>
Subject: Re: ftrace behaviour (was: [PATCH] ftrace: introduce
 tracing_reset_online_cpus() helper)

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

> On Sat, 20 Dec 2008, Ingo Molnar wrote:
> > 
> > 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.

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.

> 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

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

Powered by blists - more mailing lists