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
| ||
|
Message-ID: <20231025142245.GHZTkktbRl1wjfNc15@fat_crate.local> Date: Wed, 25 Oct 2023 16:22:45 +0200 From: Borislav Petkov <bp@...en8.de> To: Jeshua Smith <jeshuas@...dia.com> Cc: "Rafael J. Wysocki" <rafael@...nel.org>, "Luck, Tony" <tony.luck@...el.com>, "james.morse@....com" <james.morse@....com>, "keescook@...omium.org" <keescook@...omium.org>, "gpiccoli@...lia.com" <gpiccoli@...lia.com>, "lenb@...nel.org" <lenb@...nel.org>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>, "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>, Thierry Reding <treding@...dia.com>, Jonathan Hunter <jonathanh@...dia.com> Subject: Re: [PATCH V2] ACPI: APEI: Use ERST timeout for slow devices Hi, 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. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists