linux-kernel - Re: [PATCH 3/4] tracing: Allow mmio tracer to display trace

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:	Thu, 13 May 2010 11:54:14 +0300
From:	Pekka Paalanen <pq@....fi>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Larry Finger <Larry.Finger@...inger.net>
Subject: Re: [PATCH 3/4] tracing: Allow mmio tracer to display
 trace_printk() and other events

On Wed, 12 May 2010 21:21:13 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> From: Steven Rostedt <srostedt@...hat.com>
> 
> The mmio tracer has its own function to handle reading of events.
> But if it encounters an event that it does not understand it
> ignores it instead of telling the calling function that it is not
> processing it.
> 
> If someone adds trace_printk() or enables events along with the
> mmio tracer, then these events will not be displayed in the trace
> output.
> 
> Simple solution is to just have the mmio print return UNHANDLED to
> let the caller know that it did not processes the event and the
> caller can process the event further.

Does this not mean that the mmiotrace output may contain
foreign lines? If it does, it will break the user space.
The dump format is specified in
Documentation/trace/mmiotrace.txt.

If you want to handle arbitrary messages, format them as
MARK events, please.

If I understood correctly, then NAK for this patch. Otherwise,
could you explain how this does not break the mmiotrace dump
format?

Is the tracing infrastructure now supporting several
active tracers at the same time? If yes, and if mmiotrace
should be able to co-operate, we need a new revision of the
dump format, or a tool that extracts the mmiotrace
events in the current format.

Thanks.

> Reported-by: Larry Finger <Larry.Finger@...inger.net>
> Cc: Pekka Paalanen <pq@....fi>
> Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
> ---
>  kernel/trace/trace_mmiotrace.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/trace/trace_mmiotrace.c
> b/kernel/trace/trace_mmiotrace.c index 017fa37..592c00f 100644
> --- a/kernel/trace/trace_mmiotrace.c
> +++ b/kernel/trace/trace_mmiotrace.c
> @@ -282,7 +282,8 @@ static enum print_line_t
> mmio_print_line(struct trace_iterator *iter) case TRACE_PRINT:
>  		return mmio_print_mark(iter);
>  	default:
> -		return TRACE_TYPE_HANDLED; /* ignore unknown
> entries */
> +		/* Not our event */
> +		return TRACE_TYPE_UNHANDLED;
>  	}
>  }
>  
> -- 
> 1.7.0

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