linux-kernel - Re: [PATCH 2/4] tracing/ftrace: Change the type of the init() callback

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] [day] [month] [year] [list]

Date:	Mon, 17 Nov 2008 00:40:41 +0200
From:	Pekka Paalanen <pq@....fi>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Steven Noonan <steven@...inklabs.net>
Subject: Re: [PATCH 2/4] tracing/ftrace: Change the type of the init()
 callback

On Sun, 16 Nov 2008 05:57:26 +0100
Frederic Weisbecker <fweisbec@...il.com> wrote:

> Impact: Handle errors during initialization of a tracer
> 
> This bring a way to know if the initialization of a tracer successed.
> A tracer must return 0 on success and a traditional error (ie: -ENOMEM)
> if it fails.
> If a tracer fails to init, it is free to print a detailed warn. The tracing
> api will not and switch to a new tracer will just return the error from the init
> callback.
> 
> Note: this will be used for the return tracer.
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Pekka Paalanen <pq@....fi>
> Cc: Steven Noonan <steven@...inklabs.net>
> ---
>  kernel/trace/trace.c                  |    7 ++-
>  kernel/trace/trace.h                  |    3 +-
>  kernel/trace/trace_boot.c             |    3 +-
>  kernel/trace/trace_branch.c           |    3 +-
>  kernel/trace/trace_functions.c        |    3 +-
>  kernel/trace/trace_functions_return.c |    3 +-
>  kernel/trace/trace_irqsoff.c          |    9 +++-
>  kernel/trace/trace_mmiotrace.c        |    3 +-
>  kernel/trace/trace_nop.c              |    3 +-
>  kernel/trace/trace_sched_switch.c     |    3 +-
>  kernel/trace/trace_sched_wakeup.c     |    3 +-
>  kernel/trace/trace_selftest.c         |   66 ++++++++++++++++++++++++++++----
>  kernel/trace/trace_sysprof.c          |    3 +-
>  13 files changed, 88 insertions(+), 24 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 2d5672d..938ee31 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -2638,8 +2638,11 @@ static int tracing_set_tracer(char *buf)
>  		current_trace->reset(tr);
>  
>  	current_trace = t;
> -	if (t->init)
> -		t->init(tr);
> +	if (t->init) {
> +		ret = t->init(tr);
> +		if (ret)
> +			goto out;
> +	}
>  
>  	trace_branch_enable(tr);
>   out:
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 790ea8c..cdbd5cc 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -264,7 +264,8 @@ enum print_line_t {
>   */
>  struct tracer {
>  	const char		*name;
> -	void			(*init)(struct trace_array *tr);
> +	/* Your tracer should raise a warning if init fails */
> +	int			(*init)(struct trace_array *tr);
>  	void			(*reset)(struct trace_array *tr);
>  	void			(*start)(struct trace_array *tr);
>  	void			(*stop)(struct trace_array *tr);

...

> diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
> index 51bcf37..433d650 100644
> --- a/kernel/trace/trace_mmiotrace.c
> +++ b/kernel/trace/trace_mmiotrace.c
> @@ -30,13 +30,14 @@ static void mmio_reset_data(struct trace_array *tr)
>  		tracing_reset(tr, cpu);
>  }
>  
> -static void mmio_trace_init(struct trace_array *tr)
> +static int mmio_trace_init(struct trace_array *tr)
>  {
>  	pr_debug("in %s\n", __func__);
>  	mmio_trace_array = tr;
>  
>  	mmio_reset_data(tr);
>  	enable_mmiotrace();
> +	return 0;
>  }
>  
>  static void mmio_trace_reset(struct trace_array *tr)

On a quick glance, I didn't see anything wrong in these parts.
I leave it for later to check if enable_mmiotrace() could fail
and if it should be propagated.

Thanks.

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