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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2009 19:33:40 +0200 From: Frederic Weisbecker <fweisbec@...il.com> To: Jiri Olsa <jolsa@...hat.com> Cc: mingo@...e.hu, rostedt@...dmis.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] tracing - fix function graph trace to properly skip records On Tue, Oct 20, 2009 at 07:11:54PM +0200, Frederic Weisbecker wrote: > > NOTE: > > > > AFAIK patch does not affect "trace_pipe" handling, since the change is > > on the ring_buffer_iter level. However the "trace_pipe" suffers from > > the same issue -> when the read buffer is filled up, the current trace > > entry is not copied to it. Following read will continue with next entry. > > It might be harder to fix this, since "trace_pipe" in order to see next > > record has to eat the current one... > > > > I'll look at possible solution, but any ideas are welcome.. :) > > Yeah, dealing with the ring buffer consuming mode is more tricky. Actually I would feel more comfortable with a generic solution that solves consuming and iter modes. We have a private field in struct trace_iterator so I guess we can store useful things inside. Say we have that in the ring buffer: f1 entry f1 return f2 entry If we know we are a leaf call, we need to store a copy of the f1 entry/f1 return couple in struct trace_iterator::private So that we can check that on the next processing and call print_graph_entry_leaf() directly. What remains is the need to check the status of the last processing. Was it TRACE_TYPE_HANLED,TRACE_TYPE_PARTIAL_LINE..? We probably need this info in trace_iterator... -- 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