linux-kernel - Re: [PATCH 1/3] efi/cper, cxl: Decode CXL Component Events General Media Event Record

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:   Tue, 17 Oct 2023 13:45:02 -0700
From:   Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
To:     Dan Williams <dan.j.williams@...el.com>, linux-efi@...r.kernel.org,
        linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Alison Schofield <alison.schofield@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Yazen Ghannam <yazen.ghannam@....com>
Subject: Re: [PATCH 1/3] efi/cper, cxl: Decode CXL Component Events General
 Media Event Record

Hi Dan,

On 10/12/2023 4:26 PM, Dan Williams wrote:
> Smita Koralahalli wrote:
>> Add support for decoding CXL Component Events General Media Event Record
>> as defined in CXL rev 3.0 section 8.2.9.2.1.1.
>>
>> All the event records as defined in Event Record Identifier field of the
>> Common Event Record Format in CXL rev 3.0 section 8.2.9.2.1 follow the
>> CPER format for representing the hardware errors if reported by a
>> platform.
>>
>> According to the CPER format, each event record including the General
>> Media is logged as a CXL Component Event as defined in UEFI 2.10
>> Section N.2.14 and is identified by a UUID as defined by Event Record
>> Identifier field in Common Event Record Format of CXL rev 3.0 section
>> 8.2.9.2.1. CXL Component Event Log field in Component Events Section
>> corresponds to the component/event specified by the section type UUID.
>>
>> Add support for decoding CXL Component Events as defined in UEFI 2.10
>> Section N.2.14 and decoding Common Event Record as defined in CXL rev 3.0
>> section 8.2.9.2.1.
> 
> So I think this is missing the rationale for the code duplication.
> 
> Specifically, who is the consumer of this parsing relative to who is the
> consumer of the event records emitted by the CXL subsystem. Given the
> CXL subsystem event parsing already exists, and unlike this
> implementation can support DPA-to-HPA translation, why should Linux
> carry 2 emitters for what is effectively the same data?
> 
> What I would like to see is the CPER code post these record payloads on
> a notifier chain for the CXL subsystem to parse, annotate with extra CXL
> subsystem information, and emit from one control point.
> 
> Otherwise if folks would like to see this printk() version of the error
> records then they also need to answer why the CXL subsystem should not
> also emit decoder error logs to printk?

I'm fine with your suggestion. I don't have any strong argument which 
proves the other way round. This was just a starting point in adding 
support for Component error logging in FW-First. I will take a look at 
Ira's patches which adds notifier chain support.

Thanks,
Smita