linux-kernel - RE: [PATCH v4 1/3] math.h: add DIV_ROUND_UP_NO

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: <055dd714f98f4e45b2add561b7663378@AcuMS.aculab.com>
Date:   Thu, 26 Oct 2023 08:57:11 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Vasily Gorbik <gor@...ux.ibm.com>
CC:     Sebastian Reichel <sebastian.reichel@...labora.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Niklas Schnelle" <schnelle@...ux.ibm.com>,
        "kernel@...labora.com" <kernel@...labora.com>
Subject: RE: [PATCH v4 1/3] math.h: add DIV_ROUND_UP_NO_OVERFLOW

From: Linus Torvalds
> Sent: 25 October 2023 18:44
> 
> On Wed, 25 Oct 2023 at 05:05, Vasily Gorbik <gor@...ux.ibm.com> wrote:
> >
> > You probably want
> >
> >  #define __div_round_up(n,d) _Generic((n)+(d),          \
> >         unsigned long long: __div_round_up_ull,         \
> >         long long: __div_round_up_ll,                   \
> >         unsigned long: __div_round_up_ul,               \
> >         long: __div_round_up_l,                         \
> >         unsigned int: __div_round_up_u,                 \
> >         int: __div_round_up_i)(n,d)
> >
> > to avoid early type-checking for expressions that will be discarded
> > and prevent errors like:
> 
> Ack. I noticed that later when I tried to do a bigger config build -
> the compiler would warn about the implicit truncation of the integer
> arguments (for the cases where they weren't used).
> 
> > Plus typos fixes below passes allyesconfig for s390, 32-bit x86 and arm.
> 
> Lovely.
> 
> It would have been even better if somebody told me that I was stupid
> and there was some nice trick to it, but at least the _Generic()
> approach doesn't seem broken - just a few tweaks needed.

Doesn't that version end up calling inline functions?
So won't be usable in static initialisers - the same as statement functions.

Will this trick work:
#define ZERO_UNLESS_TYPE(x, type) _Generic(x, type: x, default 0)
#define div_ru(type, fn, n, d) \
	type: fn(ZERO_UNLESS_TYPE(type, (n) + (d), n), ZERO_UNLESS_TYPE(type, (n) + (d), d)
then:
#define __div_round_up(n, d) _Generic((n)+(d),          \
	div_ru(unsigned long long, __div_round_up_ull, n, d),
	...

Which would allow the 'functions' be #defines.

But it still has the issues of doing 'big' divisions.
Although the compiler will use 32bit (and 64 by 32 bit) divisions
for 64 bit types if it knows the values are small.

clang seems to add conditionals to avoid 64x64 divides.
Probably worth it for intel x86 cpu, but not for amd ones.

	David

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