linux-kernel - Re: [PATCH] tracing: add trace event for memory-failure

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, 19 Mar 2015 11:39:39 +0100
From:	Borislav Petkov <bp@...e.de>
To:	Xie XiuQi <xiexiuqi@...wei.com>
Cc:	n-horiguchi@...jp.nec.com, gong.chen@...ux.intel.com,
	bhelgaas@...gle.com, tony.luck@...el.com, rostedt@...dmis.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	jingle.chen@...wei.com
Subject: Re: [PATCH] tracing: add trace event for memory-failure

On Thu, Mar 19, 2015 at 11:04:30AM +0800, Xie XiuQi wrote:
> Memory-failure as the high level machine check handler, it's necessary
> to report memory page recovery action result to user space by ftrace.
> 
> This patch add a event at ras group for memory-failure.
> 
> The output like below:
> #  tracer: nop
> # 
> #  entries-in-buffer/entries-written: 2/2   #P:24
> # 
> #                               _-----=> irqs-off
> #                              / _----=> need-resched
> #                             | / _---=> hardirq/softirq
> #                             || / _--=> preempt-depth
> #                             ||| /     delay
> #            TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> #               | |       |   ||||       |         |
>        mce-inject-13150 [001] ....   277.019359: memory_failure_event: pfn 0x19869: free buddy page recovery: Delayed
> 
> ---
> v1->v2:
>  - Comment update
>  - Just passing 'result' instead of 'action_name[result]',
>    suggested by Steve. And hard coded there because trace-cmd
>    and perf do not have a way to process enums.
> 
> Cc: Tony Luck <tony.luck@...el.com>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Signed-off-by: Xie XiuQi <xiexiuqi@...wei.com>
> ---
>  include/ras/ras_event.h | 38 ++++++++++++++++++++++++++++++++++++++
>  mm/memory-failure.c     |  3 +++
>  2 files changed, 41 insertions(+)
> 
> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index 79abb9c..ebb05f3 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -232,6 +232,44 @@ TRACE_EVENT(aer_event,
>  		__print_flags(__entry->status, "|", aer_uncorrectable_errors))
>  );
>  
> +/*
> + * memory-failure recovery action result event
> + *
> + * unsigned long pfn -	Page Number of the corrupted page
> + * char * action -	Recovery action for various type of pages
> + * int result	 -	Action result
> + *
> + * NOTE: 'action' and 'result' are defined at mm/memory-failure.c
> + */
> +TRACE_EVENT(memory_failure_event,

What is the real reason for adding this TP? Real-life use cases please.
Add those to the commit message too.

"Just because" is not a proper justification.

> +	TP_PROTO(const unsigned long pfn,
> +		 const char *action,
> +		 const int result),
> +
> +	TP_ARGS(pfn, action, result),
> +
> +	TP_STRUCT__entry(
> +		__field(unsigned long, pfn)
> +		__string(action, action)
> +		__field(int, result)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->pfn	= pfn;
> +		__assign_str(action, action);
> +		__entry->result	= result;
> +	),
> +
> +	TP_printk("pfn %#lx: %s page recovery: %s",
> +		__entry->pfn,
> +		__get_str(action),
> +		__print_symbolic(__entry->result,
> +				{0, "Ignored"},
> +				{1, "Failed"},
> +				{2, "Delayed"},
> +				{3, "Recovered"})

If you're going to do this, please add a comment above it like this:

/*
 * Keep those in sync with static const char *action_name[] in
 * mm/memory-failure.c
 */

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/