linux-kernel - 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

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: <qbmazoiryyqygjk2x6bc7puqvmik7gyitzo3xnryzsodnrrjek@tahia33lvpli>
Date: Sat, 1 Feb 2025 14:27:10 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: kernel test robot <lkp@...el.com>, oe-kbuild-all@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, 
	Linux Memory Management List <linux-mm@...ck.org>, Kees Cook <keescook@...omium.org>
Subject: 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

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@...gle.com> wrote:
> >
> > On Thu, Jan 30, 2025 at 4:06 PM kernel test robot <lkp@...el.com> 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@intel.com/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@intel.com/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@google.com
> 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 *.