Re: drivers/auxdisplay/panel.c:1454:2: error: call to __compiletime_assert_309 declared with 'error' attribute: BUILD_BUG_ON failed: !__builtin_constant_p(_dest_len) || _dest_len == (size_t)-1

From: Kent Overstreet
Date: Sat Feb 01 2025 - 14:27:30 EST


On Fri, Jan 31, 2025 at 02:51:26PM -0800, Suren Baghdasaryan wrote:
> On Fri, Jan 31, 2025 at 8:55 AM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> >
> > On Thu, Jan 30, 2025 at 4:06 PM kernel test robot <lkp@xxxxxxxxx> wrote:
> > >
> > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head: b4b0881156fb8209bf5ef6cb63211bb0ad6e1a6b
> > > commit: 07438779313caafe52ac1a1a6958d735a5938988 alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled
> > > date: 5 days ago
> > > config: hexagon-randconfig-r133-20250131 (https://download.01.org/0day-ci/archive/20250131/202501310832.kiAeOt2z-lkp@xxxxxxxxx/config)
> > > compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
> > > reproduce: (https://download.01.org/0day-ci/archive/20250131/202501310832.kiAeOt2z-lkp@xxxxxxxxx/reproduce)
> >
> > Just saw this report (was on vacation). Will try to figure out what's going on.
>
> I confirmed that my change at
> https://lore.kernel.org/all/20241226211639.1357704-1-surenb@xxxxxxxxxx
> indeed causes this.
> Looks like due to the additional mem_alloc_profiling_enabled() check,
> the compiler considers allocation size as unknown at compile time
> (__builtin_object_size(obj) returns -1) even though both branches of
> that condition make the same exact allocation.
> I tried changing it to:
>
> #define alloc_hooks_tag(_tag, _do_alloc) \
> ({ \
> typeof(_do_alloc) _res; \
> struct alloc_tag * __maybe_unused _old; \
> if (mem_alloc_profiling_enabled()) \
> _old = alloc_tag_save(_tag); \
> _res = _do_alloc; \
> if (mem_alloc_profiling_enabled()) \
> alloc_tag_restore(_tag, _old); \
> _res; \
> })
>
> and that fixes the problem, however this would require two static key
> checks... I wonder if there is a way to tell the compiler that both
> branches cause the same result. Let me dig around.

strtomem_pad() looks pretty suspect to me.

I'm not seeing any reason for it to be using __builtin_object_size(),
(and __builtin_object_size() failing looks like perhaps a bizarre
compiler bug?).

It looks to me like ARRAY_SIZE() would be better here, and also there
really should be some actual typechecking on the source and dest
arguments - like strcpy(), they should be char *.