linux-kernel - Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal.

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: <20180425171557.GC2597@pd.tnic>
Date:   Wed, 25 Apr 2018 19:15:57 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Alex G." <mr.nuke.me@...il.com>
Cc:     linux-acpi@...r.kernel.org, linux-edac@...r.kernel.org,
        rjw@...ysocki.net, lenb@...nel.org, tony.luck@...el.com,
        tbaicar@...eaurora.org, will.deacon@....com, james.morse@....com,
        shiju.jose@...wei.com, zjzhang@...eaurora.org,
        gengdongjiu@...wei.com, linux-kernel@...r.kernel.org,
        alex_gagniuc@...lteam.com, austin_bolen@...l.com,
        shyam_iyer@...l.com, devel@...ica.org, mchehab@...nel.org,
        robert.moore@...el.com, erik.schmauss@...el.com,
        Yazen Ghannam <yazen.ghannam@....com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable
 errors are marked as fatal.

On Wed, Apr 25, 2018 at 10:00:53AM -0500, Alex G. wrote:
> Firmware-first.

Ok, my guess was right.

> We could probably use more of the native AER print functions, but that's
> beyond the scope of this patch.

No no, this does not belong in this patchset.

> Like the exact thing that this patch series implements? :)

Exact thing? I don't think so.

No, your patchset is grafting some funky and questionable side-handler
which gets to see the PCIe errors first, out-of-line and then it
practically downgrades their severity outside of the error processing
flow.

What I've been telling you to do is to extend ghes_severity() to
give the lower than PANIC severity for CPER_SEC_PCIE errors first
so that the machine doesn't panic from them anymore and those PCIe
errors get processed in the normal error processing path down
through ghes_do_proc() and then land in ghes_handle_aer(). No adhoc
->handle_irqsafe thing - just the normal straightforward error
processing path.

There, in ghes_handle_aer(), you do the check whether the device is
still there - i.e., you try to apply some heuristics to detect the error
type and why the system is complaining - you maybe even check whether
the NVMe device is still there - and *then* you do the proper recovery
action.

And you document for the future people looking at this code *why* you're
doing this.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.