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 *.
