linux-kernel - Re: [PATCH v2 10/15] checkpatch: Remove broken sleep/delay related checks

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: <875xr2eix6.fsf@somnus>
Date: Wed, 11 Sep 2024 09:41:41 +0200
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Joe Perches <joe@...ches.com>, Frederic Weisbecker
 <frederic@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Jonathan
 Corbet <corbet@....net>
Cc: linux-kernel@...r.kernel.org, Len Brown <len.brown@...el.com>, "Rafael
 J. Wysocki" <rafael@...nel.org>, Andy Whitcroft <apw@...onical.com>,
 Dwaipayan Ray <dwaipayanray1@...il.com>
Subject: Re: [PATCH v2 10/15] checkpatch: Remove broken sleep/delay related
 checks

Joe Perches <joe@...ches.com> writes:

> On Wed, 2024-09-11 at 07:13 +0200, Anna-Maria Behnsen wrote:
>> checkpatch.pl checks for several things related to sleep and delay
>> functions. In all warnings the outdated documentation is referenced. All
>> broken parts are listed one by one in the following with an explanation why
>> this check is broken. For a basic background of those functions please also
>> refere to the updated function descriptions of udelay(), nsleep_range() and
>> msleep().
>> 
>> Be aware: The change is done with a perl knowledge of the level "I'm able
>> to spell perl".
>> 
>> The following checks are broken:
>> 
>> - Check: (! ($delay < 10) )
>>   Message: "usleep_range is preferred over udelay;
>>             see Documentation/timers/timers-howto.rst\n"
>>   Why is the check broken: When it is an atomic context, udelay() is
>>                            mandatory.
>> 
>> - Check: ($min eq $max)
>>   Message:  "usleep_range should not use min == max args;
>>              see Documentation/timers/timers-howto.rst\n"
>>   Why is the check broken: When the requested accuracy for the sleep
>>                            duration requires it, it is also valid to use
>>                            min == max.
>
> There is a runtime setup cost to use usleep_range.

Sure, it's because of hrtimers. This is also documented in the new
documentation.

> I believe udelay should generally be used when there
> is a specific microsecond time delay required.

The aim of the whole series is to cleanup the outdated documentation of
the usage of delay/sleep related functions. Please read the new
documentation which is provided by the last patch of the queue, when to
use which function. Also updated function descriptions itself contain
important information about usage. If you have any concerns about
correctness of the new documentation or if there is something missing,
please let me know.

As several comments in the kernel and also checkpatch contain several
links to the outdated documentation file (which will be also moved to a
more self explaining file name by the last patch), I need to update
those places to be able to move the file. Also checkpatch.

>> 
>> - Check: ($delay > 2000)
>>   Message: "long udelay - prefer mdelay;
>>             see arch/arm/include/asm/delay.h\n"
>>   Why is the check broken: The threshold when to start using mdelay() to
>>                            prevent an overflow depends on
>>                            MAX_UDELAY_MS. This value is architecture
>>                            dependent. The used value for the check and
>>                            reference is arm specific. Generic would be 5ms,
>>                            but this would "break" arm, loongarch and mips
>>                            and also the arm value might "break" mips and
>>                            loongarch in some configurations.
>
> It likely won't "break", just perhaps be inefficient.

If running on loongarch with HZ>=1000 MAX_UDELAY_MS is 1. When keeping
the above check, then there is the risk of an overflow. I'm not sure if
an overflow is the same than beeing inefficient. Same for mips with HZ>=1000.

When using the generic value of 5, also arm would have the risk of an
overflow as MAX_UDELAY_MS for arm is 2.

So my general questions here are:

- What do you think about the change of this patch in general or do you
  want to have things changed?
- Should I only make changes to the commit message so that it's more clear?

This would really much help me to make progress with this queue.

Thanks a lot for your support!

	Anna-Maria