CONFIG_TEST_BITMAP triggers BUILD_BUG_ON

[nickdesaulniers]

via: https://lore.kernel.org/llvm/202306151433.QKcn7ZNn-lkp@intel.com/

>> lib/test_bitmap.c:920:2: error: call to '__compiletime_assert_239' declared with 'error' attribute: BUILD_BUG_ON failed: !__builtin_constant_p(res)
           BUILD_BUG_ON(!__builtin_constant_p(res));
           ^
   include/linux/build_bug.h:50:2: note: expanded from macro 'BUILD_BUG_ON'
           BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
           ^
   include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
   #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                       ^
   include/linux/compiler_types.h:352:2: note: expanded from macro 'compiletime_assert'
           _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
           ^
   include/linux/compiler_types.h:340:2: note: expanded from macro '_compiletime_assert'
           __compiletime_assert(condition, msg, prefix, suffix)
           ^
   include/linux/compiler_types.h:333:4: note: expanded from macro '__compiletime_assert'
                           prefix ## suffix();                             \
                           ^
   <scratch space>:185:1: note: expanded from here
   __compiletime_assert_239
   ^

I cannot reproduce by enabling CONFIG_TEST_BITMAP on top of arch=arm64 defconfig does not reproduce, so the randconfig needs bisection.

[nickdesaulniers]

CONFIG_KASAN seems to be tickling this. That's...unexpected.

Difference between good (+) and bad (-)
-CC_HAS_KASAN_MEMINTRINSIC_PREFIX=y
-KASAN_OUTLINE=y
-KASAN_SW_TAGS=n
-KASAN_VMALLOC=y
-KASAN_STACK=n
-STACKDEPOT_ALWAYS_INIT=y
-KASAN_MODULE_TEST=n
-KASAN_GENERIC=y
-KASAN_INLINE=n
-KASAN_SHADOW_OFFSET=0xdfffc00000000000
 KASAN n -> y

but having these enabled on top of defconfig doesn't seem to work...did I mess up the bisection?

Maybe a different value of CONFIG_KASAN_SHADOW_OFFSET=0xdfff800000000000 (vs 0xdfffc00000000000). That doesn't seem like it either...

[nickdesaulniers]

And I've had 2 bisections converge on

Difference between good (+) and bad (-)
 GCOV_PROFILE_ALL n -> y

but that alone on top of defconfig didn't seem to tickle this either...

[nickdesaulniers]

it seems those two together on top of defconfig reproduce.

• CONFIG_TEST_BITMAP
• GCOV_PROFILE_ALL
• KASAN

KASAN is not fun to enable via the command line scripts/config

[alobakin]

Hi, the code author here.
What should we do? Do you fix the compiler or does it trigger this build bug for a good reason? Or should I work around this in the code? I thought of ifdeffing out the whole function when the three mentioned Kconfig options are enabled.

[nickdesaulniers]

still trying to isolate a test case, bitmap.h generates a lot of code! I've got lib/test_bitmap.c down to:

#include <linux/bitmap.h>

void test_bitmap_const_eval(void)
{
	DECLARE_BITMAP(bitmap, BITS_PER_LONG);
	unsigned long bitopvar = 0;

	bitmap_clear(bitmap, 0, BITS_PER_LONG);
	if (!test_bit(7, bitmap))
		bitmap_set(bitmap, 5, 2);

	bitmap_weight(bitmap, 20);

	int res = !test_bit(18, &bitopvar);
	BUILD_BUG_ON(!__builtin_constant_p(res));
}

but I'm still working on trying to figure out what's going wrong here.
EDIT: partial reduction:

_Bool generic_test_bit();
void __arch_hweight64();
void hweight_long(long w) { __builtin_constant_p(w) ?: __arch_hweight64(); }
void test_bitmap_const_eval() {
  long bitmap[0];
  long bitopvar = 0;
  int nbits = 20;
  if (nbits)
    hweight_long(*bitmap);
  int res = __builtin_constant_p(bitopvar) ?: generic_test_bit(&bitopvar);
  void __compiletime_assert_18() __attribute__((__error__("")));
  if (!res)
    __compiletime_assert_18();
}

[ramosian-glider]

I am seeing a similar error in a KMSAN build with the attached config (that's Linux v6.8-rc2)

In file included from fs/f2fs/segment.c:8:
In file included from ./include/linux/fs.h:13:
In file included from ./include/linux/list_lru.h:12:
In file included from ./include/linux/nodemask.h:98:
./include/linux/random.h:112:2: error: call to '__compiletime_assert_137' declared with 'error' attribute: get_random_u32_inclusive() must take floor <= ceil
  112 |         BUILD_BUG_ON_MSG(__builtin_constant_p(floor) && __builtin_constant_p(ceil) &&
      |         ^
./include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
      |                                     ^
././include/linux/compiler_types.h:435:2: note: expanded from macro 'compiletime_assert'
  435 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |         ^
././include/linux/compiler_types.h:423:2: note: expanded from macro '_compiletime_assert'
  423 |         __compiletime_assert(condition, msg, prefix, suffix)
      |         ^
././include/linux/compiler_types.h:416:4: note: expanded from macro '__compiletime_assert'
  416 |                         prefix ## suffix();                             \
      |                         ^
<scratch space>:81:1: note: expanded from here
   81 | __compiletime_assert_137
      | ^

config.txt

[nathanchance]

The only uses of get_random_u32_inclusive() in fs/f2fs/segment.c have a variable ceil, so how is that BUILD_BUG_ON_MSG() failing...?

[ramosian-glider]

The minimal repro for this bug looked as follows:

__attribute__((__noreturn__)) extern void __compiletime_assert_147(void)
  __attribute__((__error__(
    "get_random_u32_inclusive() must take floor <= ceil")));
static unsigned int get_random_u32_inclusive(unsigned int floor,
               unsigned int ceil)
{
  if (!(!(__builtin_constant_p(floor) && __builtin_constant_p(ceil) &&
    (floor > ceil || ceil - floor == ((unsigned int)~0U)))))
    __compiletime_assert_147();
};
struct f2fs_sb_info {
  int max_fragment_chunk;
};
int new_curseg(struct f2fs_sb_info *sbi)
{
  return get_random_u32_inclusive(1, sbi->max_fragment_chunk);
}

But as of today (LLVM trunk @ 110f630105aed0670d82427fea55afbabc4a94c4) the bug is not reproducible for me anymore.