linux-kernel - Re: [PATCH v1] ACPI: OSL: Use usleep_range() in acpi_os

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] [day] [month] [year] [list]

Message-ID: <CAJvTdKmXHpXOBBAb7vU-8x4AN0V_q8w+JUVJJxtDtMw7yavUvQ@mail.gmail.com>
Date: Tue, 10 Dec 2024 23:14:10 -0500
From: Len Brown <lenb@...nel.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux ACPI <linux-acpi@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Linux PM <linux-pm@...r.kernel.org>, Len Brown <len.brown@...el.com>, 
	Arjan van de Ven <arjan@...ux.intel.com>, Pierre Gondois <pierre.gondois@....com>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Hans de Goede <hdegoede@...hat.com>, 
	Mario Limonciello <mario.limonciello@....com>, "Gautham R. Shenoy" <gautham.shenoy@....com>
Subject: Re: [PATCH v1] ACPI: OSL: Use usleep_range() in acpi_os_sleep()

On Thu, Dec 5, 2024 at 7:24 AM Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>
> Add at least 50 us on top of the requested sleep time in case the
> timer can be subject to coalescing, which is consistent with what's
> done in user space in this context [2], but for sleeps longer than 5 ms
> use 1% of the requested sleep time for this purpose.
>
> The rationale here is that longer sleeps don't need that much of a timer
> precision as a rule and making the timer a more likely candidate for
> coalescing in these cases is generally desirable.  It starts at 5 ms so
> that the delta between the requested sleep time and the effective
> deadline is a contiuous function of the former.

timerslack_ns defaults to 50,000 ns.

So when a user invokes nanosleep(50ms), they get slacked out to 50.050 ms

With this patch, if the AML BIOS programmer invokes Sleep(50ms),
it gets slacked out to 50.500 ms -- a 10x longer slack period.

I have not seen an explanation for why these cases should be treated
differently.

Len Brown, Intel Open Source Technology Center