linux-kernel - RE: [PATCH v3 1/5] math64: New DIV_U64_ROUND

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: <1e1b44b0a26746278c3ee4fec5c93d68@AcuMS.aculab.com>
Date:   Sat, 24 Jul 2021 11:38:11 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Pali Rohár' <pali@...nel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Lunn <andrew@...n.ch>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Vladimir Vid <vladimir.vid@...tura.hr>,
        Marek Behún <kabel@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>, Willy Tarreau <w@....eu>
Subject: RE: [PATCH v3 1/5] math64: New DIV_U64_ROUND_CLOSEST helper

From: Pali Rohár
> Sent: 22 July 2021 22:58
> 
> On Monday 19 July 2021 15:47:07 Andy Shevchenko wrote:
> > On Sat, Jul 17, 2021 at 3:39 PM Pali Rohár <pali@...nel.org> wrote:
> > >
> > > Provide DIV_U64_ROUND_CLOSEST helper which uses div_u64 to perform
> > > division rounded to the closest integer using unsigned 64bit
> > > dividend and unsigned 32bit divisor.
> >
> > ...
> >
> > > +/*
> > > + * DIV_U64_ROUND_CLOSEST - unsigned 64bit divide with 32bit divisor rounded to nearest integer
> >
> > > + * @dividend: unsigned 64bit dividend
> >
> > Here you insist users to provide a u64 (or compatible) type.
> >
> > > + * @divisor: unsigned 32bit divisor
> > > + *
> > > + * Divide unsigned 64bit dividend by unsigned 32bit divisor
> > > + * and round to closest integer.
> > > + *
> > > + * Return: dividend / divisor rounded to nearest integer
> > > + */
> > > +#define DIV_U64_ROUND_CLOSEST(dividend, divisor)       \
> >
> > > +       ({ u32 _tmp = (divisor); div_u64((u64)(dividend) + _tmp / 2, _tmp); })
> >
> > Here is the casting to u64. Why? (Yes, I have read v1 discussion and I
> > just want to continue it here).
> 
> See also Willy's response: https://lore.kernel.org/lkml/20210625155008.GB16901@1wt.eu/
> 
> Macro does not enforce type as opposite to function.
> 
> There is no compile time check for correct type and neither compile time
> warning if smaller typed value is passed.
> 
> And e.g. passing constant with explicit ULL suffix or casting external
> constant to 64bit type is impractical.

What is wrong with:
	({ u32 _tmp = (divisor); div_u64((dividend) + (u64)0 + _tmp / 2, _tmp); })
Or:
	({ u32 _tmp = (divisor); div_u64((dividend) + (u64)(_tmp / 2), _tmp); })
Both will ensure a 32bit 'dividend' is promoted to 64 bits before the '+'.
Both will fail if 'dividend' isn't an integer type.
On 32bit systems the compiler will also know when the high bits van be ignored.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)