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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 17 Oct 2021 12:06:52 +0800 From: Shuai Xue <xueshuai@...ux.alibaba.com> To: "Luck, Tony" <tony.luck@...el.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, "bp@...en8.de" <bp@...en8.de>, "james.morse@....com" <james.morse@....com>, "lenb@...nel.org" <lenb@...nel.org>, "rjw@...ysocki.net" <rjw@...ysocki.net> Cc: "zhangliguang@...ux.alibaba.com" <zhangliguang@...ux.alibaba.com>, "zhuo.song@...ux.alibaba.com" <zhuo.song@...ux.alibaba.com> Subject: Re: [PATCH] ACPI, APEI, EINJ: Relax platform response timeout to 1 second. Hi, Tony, Thank you for your reply. > Spinning for 1ms was maybe ok. Spinning for up to 1s seems like a bad idea. > > This code is executed inside a mutex ... so maybe it is safe to sleep instead of spin? May the email Subject misled you. This code do NOT spin for 1 sec. The period of the spinning depends on the SPIN_UNIT. > -#define SPIN_UNIT 100 /* 100ns */ > -/* Firmware should respond within 1 milliseconds */ > -#define FIRMWARE_TIMEOUT (1 * NSEC_PER_MSEC) > +#define SPIN_UNIT 100 /* 100us */ > +/* Firmware should respond within 1 seconds */ > +#define FIRMWARE_TIMEOUT (1 * USEC_PER_SEC) The period was 100 ns and changed to 100 us now. In my opinion, spinning for 100 ns or 100 us is OK :) The timeout_default is set with FIRMWARE_TIMEOUT (1 sec) by default. If the platform do not respond within timeout_default after multiple spins, the OSPM will print a warning message to dmesg. Regards, Shuai On 2021/10/15 PM11:37, Luck, Tony wrote: >> We observe that the waiting time for DDR error injection is about 10 ms >> and that for PCIe error injection is about 500 ms in Arm platfrom. >> >> In this patch, we relax the response timeout to 1 second and allow user to >> pass the time out value as a argument. > > Spinning for 1ms was maybe ok. Spinning for up to 1s seems like a bad idea. > > This code is executed inside a mutex ... so maybe it is safe to sleep instead of spin? > > -Tony >
Powered by blists - more mailing lists