Messages in this thread | | | Date | Wed, 17 Jun 2009 07:12:36 +0200 | From | Frederic Weisbecker <> | Subject | Re: [Patch 2/2] ksym_tracer:Handle machine stall when cat trace_pipe for ksym tracer |
| |
On Wed, Jun 17, 2009 at 04:35:27AM +0530, K.Prasad wrote: > 'trace_pipe' does not handle a TRACE_TYPE_PARTIAL_LINE well and causes the > machine to stall.
No, if it stalls here, it means it handles it well :)
> While a TRACE_TYPE_UNHANDLED return causes the tracer to > output unrelated data, a TRACE_TYPE_HANDLED return presents a clean output > (minus all partial traces). > > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com> > --- > kernel/trace/trace_ksym.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > Index: linux-2.6-tip.hbkpt/kernel/trace/trace_ksym.c > =================================================================== > --- linux-2.6-tip.hbkpt.orig/kernel/trace/trace_ksym.c > +++ linux-2.6-tip.hbkpt/kernel/trace/trace_ksym.c > @@ -389,6 +389,12 @@ static enum print_line_t ksym_trace_outp > > trace_assign_type(field, entry); > > + /* > + * Return early without any output if we don't have sufficient > + * information > + */ > + if ((!field->ksym_hbp->info.type) || (!field->ip)) > + return TRACE_TYPE_HANDLED;
Yeah that seems a good fix. But such silent ignored traces may hide bugs (current or futures). Is it a common situation to have a zero ip or an undefined breakpoint type? How can that happen?
Thanks.
> ret = trace_seq_printf(s, "%-15s %-5d %-3d %-20s ", field->p_name, > entry->pid, iter->cpu, field->ksym_name); > if (!ret) { >
| |