linux-kernel - Re: [PATCH v1] iopoll: Tweak readx_poll

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Jun 2019 18:04:41 +0200
From:   Marc Gonzalez <marc.w.gonzalez@...e.fr>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Will Deacon <will.deacon@....com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Bjorn Helgaas <helgaas@...nel.org>,
        Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH v1] iopoll: Tweak readx_poll_timeout sleep range

On 13/06/2019 14:42, Arnd Bergmann wrote:

> On Thu, Jun 13, 2019 at 2:16 PM Marc Gonzalez wrote:
>
>> Chopping max delay in 4 seems excessive. Let's just cut it in half.
>>
>> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@...e.fr>
>> ---
>> When max_us=100, old_min was 26 us; new_min would be 50 us
>> Was there a good reason for the 1/4th?
>> Is new_min=0 a problem? (for max=1)
> 
> You normally want a large enough range between min and max. I don't
> see anything wrong with a factor of four.

Hmmm, I expect the typical use-case to be:
"HW manual states operation X completes in 100 µs.
Let's call usleep_range(100, foo); before hitting the reg."

And foo needs to be a "reasonable" value: big enough to be able
to merge several requests, low enough not to wait too long after
the HW is ready.

In this case, I'd say usleep_range(100, 200); makes sense.

Come to think of it, I'm not sure min=26 (or min=50) makes sense...
Why wait *less* than what the user specified?

>> @@ -47,7 +47,7 @@
>>                         break; \
>>                 } \
>>                 if (__sleep_us) \
>> -                       usleep_range((__sleep_us >> 2) + 1, __sleep_us); \
>> +                       usleep_range(__sleep_us / 2, __sleep_us); \
>>         } \
> 
> You are also missing the '+1' now, so this breaks with __sleep_us=1.

It was on purpose.

usleep_range(0, 1); is not well-defined?
(I tried looking at the source, got lost down the rabbit hole.)

Regards.