linux-kernel - RE: [PATCH v2 1/8] minmax: Put all the clamp() definitions together

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] [day] [month] [year] [list]

Message-ID: <79870bf11a0147a1a21d9e9fd7332c56@AcuMS.aculab.com>
Date: Wed, 4 Dec 2024 17:16:22 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Geert Uytterhoeven' <geert@...ux-m68k.org>, Arnd Bergmann
	<arnd@...nel.org>
CC: Linus Torvalds <torvalds@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Jens Axboe
	<axboe@...nel.dk>, Matthew Wilcox <willy@...radead.org>, Christoph Hellwig
	<hch@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, "Andy
 Shevchenko" <andriy.shevchenko@...ux.intel.com>, Dan Carpenter
	<dan.carpenter@...aro.org>, "Jason A . Donenfeld" <Jason@...c4.com>,
	"pedro.falcato@...il.com" <pedro.falcato@...il.com>, Mateusz Guzik
	<mjguzik@...il.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "Lorenzo
 Stoakes" <lorenzo.stoakes@...cle.com>, Biju Das <biju.das.jz@...renesas.com>
Subject: RE: [PATCH v2 1/8] minmax: Put all the clamp() definitions together

From: Geert Uytterhoeven
> Sent: 04 December 2024 13:15
> Hi Arnd et al,
> 
> People started seeing this in today's linux-next...
> 
> On Tue, Jul 30, 2024 at 4:15 PM Arnd Bergmann <arnd@...nel.org> wrote:
> > On Tue, Jul 30, 2024, at 12:10, Arnd Bergmann wrote:
> > > On Tue, Jul 30, 2024, at 05:59, Linus Torvalds wrote:
> > >> On Mon, 29 Jul 2024 at 16:21, Linus Torvalds <torvalds@...uxfoundation.org> wrote:
> > >
> > > I'm giving this a spin on the randconfig test setup now to see
> > > if there are some other cases like the bcachefs one. So far I've
> > > seen one failure, but I can't make sense of it yet:
> > >
> > > drivers/gpu/drm/i915/display/intel_backlight.c: In function 'scale':
> > > include/linux/compiler_types.h:510:45: error: call to
> > > '__compiletime_assert_905' declared with attribute error: clamp() low
> > > limit source_min greater than high limit source_max
> > > include/linux/minmax.h:107:9: note: in expansion of macro
> > > 'BUILD_BUG_ON_MSG'
> > >   107 |         BUILD_BUG_ON_MSG(statically_true(ulo > uhi),
> > >                 \
> > > drivers/gpu/drm/i915/display/intel_backlight.c:47:22: note: in
> > > expansion of macro 'clamp'
> > >    47 |         source_val = clamp(source_val, source_min, source_max);
> > >
> > > See https://pastebin.com/raw/yLJ5ZqVw for the x86-64 .config
> > > that triggered this.
> >
> > The above seems to happen only with gcc-13 and gcc-14, but not gcc-12
> > and earlier, and it's the only one I've seen with a bit of randconfig
> > testing on that version.

I'd guess it happens because scale() gets inlined and then the compiler
knows the values of both lo and hi.
But I can't see one that is obviously wrong.
I suspect the calls need commenting out one by one to determine
which one it is bleating about

> >
> > There is another one that I see with gcc-8 randconfigs (arm64):
> >
> > net/netfilter/ipvs/ip_vs_conn.c: In function 'ip_vs_conn_init':
> > include/linux/compiler_types.h:510:38: error: call to '__compiletime_assert_1040' declared with
> attribute error: clamp() low limit min greater than high limit max_avail
> >   510 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >       |                                      ^
> > include/linux/minmax.h:182:28: note: in expansion of macro '__careful_clamp'
> >   182 | #define clamp(val, lo, hi) __careful_clamp(val, lo, hi)
> >       |                            ^~~~~~~~~~~~~~~
> > net/netfilter/ipvs/ip_vs_conn.c:1498:8: note: in expansion of macro 'clamp'
> >  1498 |  max = clamp(max, min, max_avail);
> >
> > I can reproduce this one with gcc-8/9/10, but not gcc-11
> > or higher.
> >
> > This may be another case of __builtin_constant_p() being
> > slightly unreliable when a local variable is constant-folded
> > based on a condition, or with partial inlining.

What has probably happened is the compiler is generating two (or more) copies
of the code and ends up with one where max_avail ends up being a small value.
OTOH it is 'n + PAGE_SHIFT - 2 - 1 - k' when 'n' is definitely unknown
and 'k' should be constant.

Found it.
sizeof (struct ip_vs_conn) is 0x120 - so 'k' is 9.
PAGE_SHIFT is (probably) 12.
So max_avail is just 'n'.
But order_base_2(n) is 'n > 1 ? ilog2(n - 1) + 1 : 0'.
And the compiler is generating two copies of the code.
And the one for totalram_pages() being zero hits the check in clamp().

> 
> Or perhaps the argument order is wrong, and it should be
> 
>     max = clamp(max_avail, min, max);

Seems equivalent and definitely safer.

	David

> 
> instead?
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

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