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]
Message-ID: <20200109114603.GC5603@zn.tnic>
Date:   Thu, 9 Jan 2020 12:46:03 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Xie XiuQi <xiexiuqi@...wei.com>, James Morse <james.morse@....com>
Cc:     tony.luck@...el.com, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] trace: ras: print the raw data of arm processor error
 info

On Sat, Dec 14, 2019 at 08:11:09PM +0800, Xie XiuQi wrote:
> User space tools such as rasdaemon need the complete error
> information from trace event. So, we print the raw data of
> error information in arm_event.
> 
> In the past, I try to parse them in trace event, but it's
> hard to deal the dynamic error item. And in commit 301f55b1a917
> ("efi: Parse ARM error information value"), the error information
> already been parsed to syslog.
> 
> So, just print the raw data in trace event for simpler.
> 
> Cc: Borislav Petkov <bp@...e.de>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Tyler Baicar <tbaicar@...eaurora.org>
> Signed-off-by: Xie XiuQi <xiexiuqi@...wei.com>
> ---
>  include/ras/ras_event.h | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index 36c5c5e38c1d..2023ba9206b3 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -180,6 +180,9 @@ TRACE_EVENT(arm_event,
>  		__field(u32, running_state)
>  		__field(u32, psci_state)
>  		__field(u8, affinity)
> +		__field(u32, count)
> +		__field(u32, len)
> +		__dynamic_array(u8, err_info, proc->err_info_num * sizeof(struct cper_arm_err_info))
>  	),
>  
>  	TP_fast_assign(
> @@ -199,12 +202,18 @@ TRACE_EVENT(arm_event,
>  			__entry->running_state = ~0;
>  			__entry->psci_state = ~0;
>  		}
> +
> +		__entry->count = proc->err_info_num;
> +		__entry->len = __entry->count * sizeof(struct cper_arm_err_info);
> +		memcpy(__get_dynamic_array(err_info), proc + 1, __entry->len);
>  	),
>  
>  	TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
> -		  "running state: %d; PSCI state: %d",
> +		  "running state: %d; PSCI state: %d; error count: %d; "
> +		  "raw data: %s",
>  		  __entry->affinity, __entry->mpidr, __entry->midr,
> -		  __entry->running_state, __entry->psci_state)
> +		  __entry->running_state, __entry->psci_state, __entry->count,
> +		  __print_hex(__get_dynamic_array(err_info), __entry->len))
>  );
>  
>  /*
> -- 

That's for ARM folks to decide whether they wanna shuffle raw error
records into userspace like that. CCed.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ