linux-kernel - Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output format

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131015091835.GA21097@gchen.bj.intel.com>
Date:	Tue, 15 Oct 2013 05:18:35 -0400
From:	Chen Gong <gong.chen@...ux.intel.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Tony Luck <tony.luck@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	Lance Ortiz <lance.ortiz@...com>,
	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Subject: Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output
 format

On Mon, Oct 14, 2013 at 11:50:47PM +0200, Borislav Petkov wrote:
> Date: Mon, 14 Oct 2013 23:50:47 +0200
> From: Borislav Petkov <bp@...en8.de>
> To: Tony Luck <tony.luck@...il.com>
> Cc: Chen Gong <gong.chen@...ux.intel.com>, Linux Kernel Mailing List
>  <linux-kernel@...r.kernel.org>, linux-acpi <linux-acpi@...r.kernel.org>,
>  Lance Ortiz <lance.ortiz@...com>, "Naveen N. Rao"
>  <naveen.n.rao@...ux.vnet.ibm.com>
> Subject: Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output
>  format
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> On Mon, Oct 14, 2013 at 02:03:16PM -0700, Tony Luck wrote:
> > Do you have a suggested mechanism for this disabling of dmesg?
> 
> Hmm, how about a 64-bit flag variable (we can use the remaining bits
> for other stuff later) called x86_ras_flags which is private to
> arch/x86/ras/core.c (a new file)...
> 
>  [ btw, I'm thinking of something similar to efi's x86_efi_facility which we
>  nicely query with test_bit and set with set_bit and clear_bit, etc, etc ]
> 
> Also, look at arch/x86/platform/efi/efi.c::efi_enabled() how it hides
> the actual variable and we can do something similar so that eMCA and
> other users like cper.c can do
> 
> apei_estatus_print_section:
> 
> 	if (!ras_tracepoint_enabled())
> 		cper_print_mem(...)
> 
> We set the bit in x86_ras_flags from, say, debugfs, i.e., a userspace
> tool sets it and from that moment on all RAS output is rerouted to the
> trace event. I.e., the output for which there is a trace event...
> 
> How does that look like?
> 

Looks fine to me. But a little bit out of current patch series. How
about adding such interfaces after this patch series is merged?
And from your words, it looks like you prefer to reserve all current
fields to avoid breaking user space things. IOW, drop patch [7/8]
and use another patch with above idea to get the same purpose. This
is what you want, Boris?


Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)