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

[David Laight <David.Laight@ACULAB.COM>]

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@kernel.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@linuxfoundation.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@linux-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)