linux-kernel - Re: [PATCH] drm/amd/display: replace use of msleep(<20) with usleep

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: <8b73708c-4613-42a0-9d48-5bf6f0e01ced@app.fastmail.com>
Date: Fri, 28 Mar 2025 23:54:34 -0700
From: James <bold.zone2373@...tmail.com>
To: "Shuah Khan" <skhan@...uxfoundation.org>, harry.wentland@....com,
 sunpeng.li@....com, siqueira@...lia.com, alexander.deucher@....com,
 christian.koenig@....com, airlied@...il.com, simona@...ll.ch,
 aurabindo.pillai@....com, alex.hung@....com
Cc: amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
 linux-kernel-mentees@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/amd/display: replace use of msleep(<20) with usleep_range for
 better accuracy

On Fri, Mar 28, 2025, at 3:46 PM, Shuah Khan wrote:
> On 3/26/25 01:00, James Flowers wrote:
>> msleep < 20ms will often sleep for ~20ms (according to Documentation/timers/timers-howto.rst).
>
> Can you elaborate and explain why this change is necessary?

scripts/checkpatch.pl highlighted it as a possible issue since msleep can cause the delay to be unexpectedly closer to 20ms. However, perhaps it would be better to submit a V2 with the change as usleep_range(10000, 20000) to match the actual delay range that msleep(10) has, which would help avoid a regression like this: https://gitlab.freedesktop.org/drm/amd/-/issues/3559#note_2532546. 

Is there any appetite for drm/amd to change instances of msleep(x) (x being < 20) to usleep_range(x*1000, 20000), so that the range of delay is clear to readers unfamiliar with the msleep quirk? Please let me know and I can submit a V2.

There is at least one instance (fixed by commit 57995aa8ffb3e47a74763cf9106d34e9e8be9d8d) in drm/amdgpu where msleep(1) seemed to be causing an unexpectedly long delay, and so was replaced with usleep_range. An issue possibly related to that fix is https://gitlab.freedesktop.org/drm/amd/-/issues/462.

Currently there are 37 msleep(1) calls that I can find in drm/amd. I'm just thinking that optimization opportunities like above could be found more easily if the delay range is made clear?

Best regards,
James Flowers