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: 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/
Powered by blists - more mailing lists