__compiletime_assert in arch/x86/platform/efi/efi_64.c

[nathanchance]

CONFIG_NO_AUTO_INLINE is a new config option in -next (commit) that prevents compilers from inlining any functions not marked as inline. It gets enabled in an allyesconfig build for x86_64.

The fail I noticed after this is

ld: arch/x86/platform/efi/efi_64.o: in function `efi_sync_low_kernel_mappings':
(.text+0x8e5): undefined reference to `__compiletime_assert_277'

I think it is one of the MAYBE_BUILD_BUG_ON because they involve __builtin_constant_p, relating it to #7. We might not have to worry about this on 4.20/5.0 but we'll see. Will try to look into this over the next few days unless someone else beats me to it.

As a workaround:

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2a4274b756dc..12a9ade3aecb 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -213,6 +213,7 @@ config GDB_SCRIPTS
 
 config NO_AUTO_INLINE
        bool "Disable compiler auto-inline optimizations"
+       depends on !CC_IS_CLANG
        help
          This will prevent the compiler from optimizing the kernel by
          auto-inlining functions not marked with the inline keyword.

[nickdesaulniers]

If you comment out the BUILD_BUG_ON and MAYBE_BUILD_BUG_ON, you can bisect which one specifically is failing.

[nathanchance]

I finally got around to sitting down commenting out the BUILD_BUG_ONs to figure out which one causes the error and it is BUILD_BUG_ON(p4d_index(EFI_VA_END) != p4d_index(MODULES_END));.

p4d_index is marked as inline in arch/x86/include/asm/pgtable.h:

static inline unsigned long p4d_index(unsigned long address)
{
        return (address >> P4D_SHIFT) & (PTRS_PER_P4D - 1);
}

I assume that the reason the BUILD_BUG_ON fails is because without inlining, p4d_index isn't evaluated as a constant expression? According to the help text, functions marked inline are supposed to be inlined still but that doesn't appear to be the case with Clang.

From lib/Frontend/CompilerInvocation.cpp:

  // At O0 we want to fully disable inlining outside of cases marked with
  // 'alwaysinline' that are required for correctness.
  Opts.setInlining((Opts.OptimizationLevel == 0)
                       ? CodeGenOptions::OnlyAlwaysInlining
                       : CodeGenOptions::NormalInlining);
  // Explicit inlining flags can disable some or all inlining even at
  // optimization levels above zero.
  if (Arg *InlineArg = Args.getLastArg(
          options::OPT_finline_functions, options::OPT_finline_hint_functions,
          options::OPT_fno_inline_functions, options::OPT_fno_inline)) {
    if (Opts.OptimizationLevel > 0) {
      const Option &InlineOpt = InlineArg->getOption();
      if (InlineOpt.matches(options::OPT_finline_functions))
        Opts.setInlining(CodeGenOptions::NormalInlining);
      else if (InlineOpt.matches(options::OPT_finline_hint_functions))
        Opts.setInlining(CodeGenOptions::OnlyHintInlining);
      else
        Opts.setInlining(CodeGenOptions::OnlyAlwaysInlining);
    }
  }

If I'm reading this correctly, when -fno-inline-functions is supplied, only functions that are marked __always_inline will be inlined. This fixes this particular fail, wonder if this would be accepted upstream (or would people claim Clang is broken and needs to be compatible with GCC lol):

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 40616e805292..f78e53382498 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -918,7 +918,7 @@ static inline int p4d_bad(p4d_t p4d)
 }
 #endif  /* CONFIG_PGTABLE_LEVELS > 3 */
 
-static inline unsigned long p4d_index(unsigned long address)
+static __always_inline unsigned long p4d_index(unsigned long address)
 {
        return (address >> P4D_SHIFT) & (PTRS_PER_P4D - 1);
 }

[nickdesaulniers]

when -fno-inline-functions is supplied

Is the kernel using that for CONFIG_NO_AUTO_INLINE? I get the feeling that they may be hitting quite a few of these kind of errors.

I think some commit message explaining that -fno-inline-functions from CONFIG_NO_AUTO_INLINE causes this specific bug to longer be ICE with Clang is fine.

[nickdesaulniers]

I'm curious too what the point of CONFIG_NO_AUTO_INLINE is. Maybe the commit message says why it's useful.

[nathanchance]

when -fno-inline-functions is supplied

Is the kernel using that for CONFIG_NO_AUTO_INLINE? I get the feeling that they may be hitting quite a few of these kind of errors.

Yes:

ifdef CONFIG_NO_AUTO_INLINE
KBUILD_CFLAGS   += $(call cc-option, -fno-inline-functions) \
		   $(call cc-option, -fno-inline-small-functions) \
		   $(call cc-option, -fno-inline-functions-called-once)
endif

I think some commit message explaining that -fno-inline-functions from CONFIG_NO_AUTO_INLINE causes this specific bug to longer be ICE with Clang is fine.

Sounds reasonable, thanks!

I'm curious too what the point of CONFIG_NO_AUTO_INLINE is. Maybe the commit message says why it's useful.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=9b76795cc32426e68ca1c647b6d31c7148940719

I personally think this is something that should not be selectable by the user (so allyesconfig can't explicitly turn it on), rather being selected by options that require it and that was suggested by Stephen Rothwell.

As an aside, there's another issue exacerbated by this config in a staging module:

ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!

The root cause is extern functions in a header that is never actually included in any of the files that the function is used in...

extern __inline int is_multicast_mac_addr(const u8 *addr)
{       
        return ((addr[0] != 0xff) && (0x01 & addr[0]));
}              

extern __inline int is_broadcast_mac_addr(const u8 *addr)
{       
        return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) &&   \
                (addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff));
}              

extern __inline int is_zero_mac_addr(const u8 *addr)
{       
        return ((addr[0] == 0x00) && (addr[1] == 0x00) && (addr[2] == 0x00) &&   \
                (addr[3] == 0x00) && (addr[4] == 0x00) && (addr[5] == 0x00));
}

Going to need to mull over how to properly fix that one at some time other than 3am lol.

[nathanchance]

Patch submitted: https://lore.kernel.org/lkml/20181210234538.5405-1-natechancellor@gmail.com/