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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx > > 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)
