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