linux-kernel - Re: [RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions

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]

Date:   Mon, 30 Mar 2020 06:51:05 +0000
From:   George Spelvin <lkml@....ORG>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     James Bottomley <James.Bottomley@...senPartnership.com>,
        linux-kernel@...r.kernel.org, Hannes Reinecke <hare@...e.de>,
        linux-scsi@...r.kernel.org,
        Marek Lindner <mareklindner@...mailbox.ch>,
        Simon Wunderlich <sw@...onwunderlich.de>,
        Antonio Quartulli <a@...table.cc>,
        Sven Eckelmann <sven@...fation.org>,
        b.a.t.m.a.n@...tynna.open-mesh.org,
        Johannes Berg <johannes@...solutions.net>,
        linux-wireless@...r.kernel.org, Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        lkml@....org
Subject: Re: [RFC PATCH v1 13/50] Avoid some useless msecs/jiffies conversions

On Mon, Mar 30, 2020 at 08:27:01AM +0200, Takashi Iwai wrote:
> On Sun, 29 Mar 2020 20:16:47 +0200, James Bottomley wrote:
>> We all assume that msecs_to_jiffies is properly optimized so there
>> should be no need to open code it like you're proposing.
> 
> Yes, it'd be best if the compiler can handle it properly.

I've tried, and can't figure out how to get the compiler to detect this 
special case and not invoke the general code.  In particular, for a 
variable x, __builtin_constant_p(x * 1000 % 1000) is false.  Even if x is 
signed and ANSI lets the compiler assume that overflow doesn't happen.

If you can do it, I'm most curious how!

> But also I meant to keep using the macro for consistency reason.
> IIRC, we wanted to eliminate the explicit use of HZ in the past, and
> it's how many lines have been converted with *_to_jiffies() calls.
> I don't know whether the eliminate of HZ is still wished, but
> reverting to the open code is a step backward for that.

Well, you could always add a secs_to_jiffies(x) wrapper.  But given
that it expands to basically x * HZ, some people might wonder why
you're bothering.

I assumed that open-coding x * HZ was the preferred style, so that's
what I did.