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] [day] [month] [year] [list]
Date:   Wed, 25 Oct 2023 16:22:45 +0200
From:   Borislav Petkov <>
To:     Jeshua Smith <>
Cc:     "Rafael J. Wysocki" <>,
        "Luck, Tony" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        Thierry Reding <>,
        Jonathan Hunter <>
Subject: Re: [PATCH V2] ACPI: APEI: Use ERST timeout for slow devices


On Wed, Oct 25, 2023 at 02:09:37PM +0000, Jeshua Smith wrote:
<... snip a very detailed and good explanation... >

> Writing 128 nor-flash pages would then take 120us * 128 = 15ms
> typical, or 1800us * 128 = 230.4ms max.

This is perfectly suitable to be in the commit message - it explains in
exact detail why the change is needed.

> Actual use case:
> Kernel panic -> Pstore calls APEI's ERST code to write the ~32KB error
> log to persistent store -> ERST code writes the error log to
> nor-flash, which takes more than 1ms to complete. This is expected, as
> communicated by the platform to the OS via the maximum time field in
> the ERST table.

This is actually very important and it justifies the need for that
change even more - you want to flush out the complete panic message to
pstore and not only the first couple of lines.

> ... and therefore the extended (ERST-defined) timeout is only applied
> for implementations that indicate that they are "slow". I assume that
> platforms which bother to set the "slow" bit will also specify actual
> timings, and platforms which don't are OK with the current 1ms
> timeout.

Yap, makes perfect sense to me.

> Does that answer your questions?

Yes, thanks for taking the time to explain this in such a detail and
precisely. I think you should use the main bits of what you wrote here
and add them to the commit message - after this there are no more
questions why this patch is needed, IMO.



Powered by blists - more mailing lists