__compiletime_assert in drivers/net/wireless/intel/iwlwifi/fw/dbg.c #580

nathanchance · 2019-07-01T22:41:28Z

ld: drivers/net/wireless/intel/iwlwifi/fw/dbg.o: in function `_iwl_fw_dbg_apply_point':
dbg.c:(.text+0x827a): undefined reference to `__compiletime_assert_2387'
ld: dbg.c:(.text+0x8363): undefined reference to `__compiletime_assert_2393'

Bisect log:

git bisect start
# good: [9ae3b870a8ffa24b506d6683f61ddba9c51644a7] iwlwifi: iwl_mvm_tx_mpdu() must be called with BH disabled
git bisect good 9ae3b870a8ffa24b506d6683f61ddba9c51644a7
# bad: [6c7f70877872afa7574bdc147ea1c46c03ef9d71] iwlwifi: dbg: debug recording stop and restart command remove
git bisect bad 6c7f70877872afa7574bdc147ea1c46c03ef9d71
# bad: [b5e2fe356e09cd8576529dce832f2a6599fa88a4] iwlwifi: mvm: correctly fill the ac array in the iwl_mac_ctx_cmd
git bisect bad b5e2fe356e09cd8576529dce832f2a6599fa88a4
# bad: [57d88b116175cd6e9293bef5355094c7dab4b747] iwlwifi: dbg_ini: support debug info TLV
git bisect bad 57d88b116175cd6e9293bef5355094c7dab4b747
# good: [6669e924a755d699cadce7ff36a8da38f040f989] iwlwifi: update CSI API
git bisect good 6669e924a755d699cadce7ff36a8da38f040f989
# good: [c7ab138eb132e197c6f594b11ca8aa87755d2810] iwlwifi: dbg_ini: add consecutive trigger firing support
git bisect good c7ab138eb132e197c6f594b11ca8aa87755d2810
# good: [dc14b800cdd3a5e9bedcc66c61d6fe72602e50fc] iwlwifi: dbg_ini: use different barker for ini dump
git bisect good dc14b800cdd3a5e9bedcc66c61d6fe72602e50fc
# first bad commit: [57d88b116175cd6e9293bef5355094c7dab4b747] iwlwifi: dbg_ini: support debug info TLV

Bad commit: https://git.kernel.org/next/linux-next/c/57d88b116175cd6e9293bef5355094c7dab4b747

Nothing immediate sticks out but I'll try to look into it further later.

Quick reproducer:

make -j$(nproc) CC=clang allyesconfig drivers/net/wireless/intel/iwlwifi/ && nm drivers/net/wireless/intel/iwlwifi/fw/dbg.o | grep __compiletime_assert

The text was updated successfully, but these errors were encountered:

nickdesaulniers · 2019-07-02T18:48:29Z

Probably a failed BUILD_BUG_ON hidden behind a macro somewhere in drivers/net/wireless/intel/iwlwifi/fw/dbg.c

nathanchance · 2019-07-02T22:05:43Z

Ahhh, it's in the IWL_WARN macro...

drivers/net/wireless/intel/iwlwifi/iwl-debug.h:

/* not all compilers can evaluate strlen() at compile time, so use sizeof() */
#define CHECK_FOR_NEWLINE(f) BUILD_BUG_ON(f[sizeof(f) - 2] != '\n')

/* No matter what is m (priv, bus, trans), this will work */
#define IWL_ERR_DEV(d, f, a...)						\
	do {								\
		CHECK_FOR_NEWLINE(f);					\
		__iwl_err((d), false, false, f, ## a);			\
	} while (0)
#define IWL_ERR(m, f, a...)						\
	IWL_ERR_DEV((m)->dev, f, ## a)
#define IWL_WARN(m, f, a...)						\
	do {								\
		CHECK_FOR_NEWLINE(f);					\
		__iwl_warn((m)->dev, f, ## a);				\
	} while (0)
#define IWL_INFO(m, f, a...)						\
	do {								\
		CHECK_FOR_NEWLINE(f);					\
		__iwl_info((m)->dev, f, ## a);				\
	} while (0)
#define IWL_CRIT(m, f, a...)						\
	do {								\
		CHECK_FOR_NEWLINE(f);					\
		__iwl_crit((m)->dev, f, ## a);				\
	} while (0)

drivers/net/wireless/intel/iwlwifi/fw/dbg.c @ https://git.kernel.org/next/linux-next/c/57d88b116175cd6e9293bef5355094c7dab4b747:

static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
				  struct iwl_fw_ini_debug_info_tlv *dbg_info,
				  bool ext, enum iwl_fw_ini_apply_point pnt)
{
	u32 img_name_len = le32_to_cpu(dbg_info->img_name_len);
	u32 dbg_cfg_name_len = le32_to_cpu(dbg_info->dbg_cfg_name_len);
	const char err_str[] =
		"WRT: ext=%d. Invalid %s name length %d, expected %d\n";

	if (img_name_len != IWL_FW_INI_MAX_IMG_NAME_LEN) {
		IWL_WARN(fwrt, err_str, ext, "image", img_name_len,
			 IWL_FW_INI_MAX_IMG_NAME_LEN);
		return;
	}

	if (dbg_cfg_name_len != IWL_FW_INI_MAX_DBG_CFG_NAME_LEN) {
		IWL_WARN(fwrt, err_str, ext, "debug cfg", dbg_cfg_name_len,
			 IWL_FW_INI_MAX_DBG_CFG_NAME_LEN);
		return;
	}

	if (ext) {
		memcpy(fwrt->dump.external_dbg_cfg_name, dbg_info->dbg_cfg_name,
		       sizeof(fwrt->dump.external_dbg_cfg_name));
	} else {
		memcpy(fwrt->dump.img_name, dbg_info->img_name,
		       sizeof(fwrt->dump.img_name));
		memcpy(fwrt->dump.internal_dbg_cfg_name, dbg_info->dbg_cfg_name,
		       sizeof(fwrt->dump.internal_dbg_cfg_name));
	}
}

Preprocessed source:

static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
      struct iwl_fw_ini_debug_info_tlv *dbg_info,
      bool ext, enum iwl_fw_ini_apply_point pnt)
{
 u32 img_name_len = (( __u32)(__le32)(dbg_info->img_name_len));
 u32 dbg_cfg_name_len = (( __u32)(__le32)(dbg_info->dbg_cfg_name_len));
 const char err_str[] =
  "WRT: ext=%d. Invalid %s name length %d, expected %d\n";

 if (img_name_len != 32) {
  do { do { extern void __compiletime_assert_2446(void) ; if (!(!(err_str[sizeof(err_str) - 2] != '\n'))) __compiletime_assert_2446(); } while (0); __iwl_warn((fwrt)->dev, err_str, ext, "image", img_name_len, 32); } while (0);

  return;
 }

 if (dbg_cfg_name_len != 64) {
  do { do { extern void __compiletime_assert_2452(void) ; if (!(!(err_str[sizeof(err_str) - 2] != '\n'))) __compiletime_assert_2452(); } while (0); __iwl_warn((fwrt)->dev, err_str, ext, "debug cfg", dbg_cfg_name_len, 64); } while (0);

  return;
 }

 if (ext) {
  memcpy(fwrt->dump.external_dbg_cfg_name, dbg_info->dbg_cfg_name,
         sizeof(fwrt->dump.external_dbg_cfg_name));
 } else {
  memcpy(fwrt->dump.img_name, dbg_info->img_name,
         sizeof(fwrt->dump.img_name));
  memcpy(fwrt->dump.internal_dbg_cfg_name, dbg_info->dbg_cfg_name,
         sizeof(fwrt->dump.internal_dbg_cfg_name));
 }
}

compared to IWL_WARN use with a normal string:

 if (!fwrt->dump.d3_debug_data) {
  fwrt->dump.d3_debug_data = kmalloc(cfg->d3_debug_data_length,
         ((( gfp_t)(0x400u|0x800u)) | (( gfp_t)0x40u) | (( gfp_t)0x80u)));
  if (!fwrt->dump.d3_debug_data) {
   do { do { extern void __compiletime_assert_2423(void) ; if (!(!("failed to allocate memory for D3 debug data\n"[sizeof("failed to allocate memory for D3 debug data\n") - 2] != '\n'))) __compiletime_assert_2423(); } while (0); __iwl_err(((fwrt)->dev), false, false, "failed to allocate memory for D3 debug data\n"); } while (0);

   return;
  }
 }

There is another occurrence of this pattern in a later commit (invalid_ap_str in https://git.kernel.org/next/linux-next/c/427ab6385cf302b35ea1dc53ebca938e0a8328b9).

Is there a clean way to resolve this other than eliminating the use of the problematic const char variables (err_str/invalid_ap_str)? I crafted up this super gross patch just to test and it works but I can guarantee there is no way this will be accepted upstream.

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index e411ac98290d..b2b2e6d20bf9 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -2438,20 +2438,20 @@ static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
 {
 	u32 img_name_len = le32_to_cpu(dbg_info->img_name_len);
 	u32 dbg_cfg_name_len = le32_to_cpu(dbg_info->dbg_cfg_name_len);
-	const char err_str[] =
-		"WRT: ext=%d. Invalid %s name length %d, expected %d\n";
+#define ERR_STR "WRT: ext=%d. Invalid %s name length %d, expected %d\n"
 
 	if (img_name_len != IWL_FW_INI_MAX_IMG_NAME_LEN) {
-		IWL_WARN(fwrt, err_str, ext, "image", img_name_len,
+		IWL_WARN(fwrt, ERR_STR, ext, "image", img_name_len,
 			 IWL_FW_INI_MAX_IMG_NAME_LEN);
 		return;
 	}
 
 	if (dbg_cfg_name_len != IWL_FW_INI_MAX_DBG_CFG_NAME_LEN) {
-		IWL_WARN(fwrt, err_str, ext, "debug cfg", dbg_cfg_name_len,
+		IWL_WARN(fwrt, ERR_STR, ext, "debug cfg", dbg_cfg_name_len,
 			 IWL_FW_INI_MAX_DBG_CFG_NAME_LEN);
 		return;
 	}
+#undef ERR_STR
 
 	if (ext) {
 		memcpy(fwrt->dump.external_dbg_cfg_name, dbg_info->dbg_cfg_name,
@@ -2775,8 +2775,7 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
 		struct iwl_ucode_tlv *tlv = iter;
 		void *ini_tlv = (void *)tlv->data;
 		u32 type = le32_to_cpu(tlv->type);
-		const char invalid_ap_str[] =
-			"WRT: ext=%d. Invalid apply point %d for %s\n";
+#define INVALID_AP_STR "WRT: ext=%d. Invalid apply point %d for %s\n"
 
 		switch (type) {
 		case IWL_UCODE_TLV_TYPE_DEBUG_INFO:
@@ -2786,7 +2785,7 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
 			struct iwl_fw_ini_allocation_data *buf_alloc = ini_tlv;
 
 			if (pnt != IWL_FW_INI_APPLY_EARLY) {
-				IWL_ERR(fwrt, invalid_ap_str, ext, pnt,
+				IWL_ERR(fwrt, INVALID_AP_STR, ext, pnt,
 					"buffer allocation");
 				goto next;
 			}
@@ -2797,10 +2796,11 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
 		}
 		case IWL_UCODE_TLV_TYPE_HCMD:
 			if (pnt < IWL_FW_INI_APPLY_AFTER_ALIVE) {
-				IWL_ERR(fwrt, invalid_ap_str, ext, pnt,
+				IWL_ERR(fwrt, INVALID_AP_STR, ext, pnt,
 					"host command");
 				goto next;
 			}
+#undef INVALID_AP_STR
 			iwl_fw_dbg_send_hcmd(fwrt, tlv, ext);
 			break;
 		case IWL_UCODE_TLV_TYPE_REGIONS:

nathanchance · 2019-07-03T05:41:42Z

Something else might be up here as I cannot get this to trigger with x86_64_defconfig + all of the IWLWIFI configs:

CONFIG_EXPERT=y
CONFIG_PM=y
CONFIG_DEBUG_FS=y
CONFIG_MAC80211_DEBUGFS=y
CONFIG_IWLWIFI=y
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLDVM=y
CONFIG_IWLMVM=y
CONFIG_IWLWIFI_BCAST_FILTERING=y
CONFIG_IWLWIFI_PCIE_RTPM=y
CONFIG_IWLWIFI_DEBUG=y
CONFIG_IWLWIFI_DEBUGFS=y
CONFIG_IWLWIFI_DEVICE_TRACING=y

I diffed the build flags but nothing immediately stands out:

defconfig: -Wframe-larger-than=2048 -fomit-frame-pointer

allyesconfig: -DCONFIG_X86_X32_ABI -pg -mfentry -DCC_USING_FENTRY -fsanitize=kernel-address -mllvm -asan-mapping-offset=0xdffffc0000000000 -mllvm -asan-globals=1 -mllvm -asan-instrumentation-with-call-threshold=0 -mllvm -asan-stack=1 --param asan-instrument-allocas=1 -fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp

nickdesaulniers · 2019-07-03T05:45:18Z

For those unreadable macro expansions: dump them in a file then run clang-format -i on them.

I'm guessing that the __compiletime_assert_2387 and __compiletime_assert_2393 are not supposed to be generated at all? What difference is there in the preprocessed source look like between gcc and clang?

nathanchance · 2019-07-03T05:54:08Z

For those unreadable macro expansions: dump them in a file then run clang-format -i on them.

Thank you for the tip :)

I'm guessing that the __compiletime_assert_2387 and __compiletime_assert_2393 are not supposed to be generated at all?

Well, I think they are supposed to be generated because they are BUILD_BUG_ON calls:

https://github.com/torvalds/linux/blob/master/include/linux/build_bug.h#L50

https://github.com/torvalds/linux/blob/master/include/linux/compiler.h#L345

I guess on the surface what is happening is clang is not able to resolve f[sizeof(f) - 2] != '\n' in the CHECK_FOR_NEWLINE macro to a constant expression with err_str/invalid_ap_str.

What difference is there in the preprocessed source look like between gcc and clang?

I will take a look at this first thing tomorrow morning.

nathanchance · 2019-07-03T19:16:42Z

Preprocessed source + clang-format.

Clang:

static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
				  struct iwl_fw_ini_debug_info_tlv *dbg_info,
				  bool ext, enum iwl_fw_ini_apply_point pnt)
{
	u32 img_name_len = ((__u32)(__le32)(dbg_info->img_name_len));
	u32 dbg_cfg_name_len = ((__u32)(__le32)(dbg_info->dbg_cfg_name_len));
	const char err_str[] =
		"WRT: ext=%d. Invalid %s name length %d, expected %d\n";

	if (img_name_len != 32) {
		do {
			do {
				extern void __compiletime_assert_2446(void);
				if (!(!(err_str[sizeof(err_str) - 2] != '\n')))
					__compiletime_assert_2446();
			} while (0);
			__iwl_warn((fwrt)->dev, err_str, ext, "image",
				   img_name_len, 32);
		} while (0);

		return;
	}

	if (dbg_cfg_name_len != 64) {
		do {
			do {
				extern void __compiletime_assert_2452(void);
				if (!(!(err_str[sizeof(err_str) - 2] != '\n')))
					__compiletime_assert_2452();
			} while (0);
			__iwl_warn((fwrt)->dev, err_str, ext, "debug cfg",
				   dbg_cfg_name_len, 64);
		} while (0);

		return;
	}

	if (ext) {
		memcpy(fwrt->dump.external_dbg_cfg_name, dbg_info->dbg_cfg_name,
		       sizeof(fwrt->dump.external_dbg_cfg_name));
	} else {
		memcpy(fwrt->dump.img_name, dbg_info->img_name,
		       sizeof(fwrt->dump.img_name));
		memcpy(fwrt->dump.internal_dbg_cfg_name, dbg_info->dbg_cfg_name,
		       sizeof(fwrt->dump.internal_dbg_cfg_name));
	}
}

GCC:

static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
				  struct iwl_fw_ini_debug_info_tlv *dbg_info,
				  bool ext, enum iwl_fw_ini_apply_point pnt)
{
	u32 img_name_len = ((__u32)(__le32)(dbg_info->img_name_len));
	u32 dbg_cfg_name_len = ((__u32)(__le32)(dbg_info->dbg_cfg_name_len));
	const char err_str[] =
		"WRT: ext=%d. Invalid %s name length %d, expected %d\n";

	if (img_name_len != 32) {
		do {
			do {
				extern void
				__compiletime_assert_2445(void) __attribute__((__error__(
					"BUILD_BUG_ON failed: "
					"err_str[sizeof(err_str) - 2] != '\\n'")));
				if (!(!(err_str[sizeof(err_str) - 2] != '\n')))
					__compiletime_assert_2445();
			} while (0);
			__iwl_warn((fwrt)->dev, err_str, ext, "image",
				   img_name_len, 32);
		} while (0);
		return;
	}

	if (dbg_cfg_name_len != 64) {
		do {
			do {
				extern void
				__compiletime_assert_2451(void) __attribute__((__error__(
					"BUILD_BUG_ON failed: "
					"err_str[sizeof(err_str) - 2] != '\\n'")));
				if (!(!(err_str[sizeof(err_str) - 2] != '\n')))
					__compiletime_assert_2451();
			} while (0);
			__iwl_warn((fwrt)->dev, err_str, ext, "debug cfg",
				   dbg_cfg_name_len, 64);
		} while (0);
		return;
	}

	if (ext) {
		memcpy(fwrt->dump.external_dbg_cfg_name, dbg_info->dbg_cfg_name,
		       sizeof(fwrt->dump.external_dbg_cfg_name));
	} else {
		memcpy(fwrt->dump.img_name, dbg_info->img_name,
		       sizeof(fwrt->dump.img_name));
		memcpy(fwrt->dump.internal_dbg_cfg_name, dbg_info->dbg_cfg_name,
		       sizeof(fwrt->dump.internal_dbg_cfg_name));
	}
}

The only real difference I see is the addition of the message in the compiletime_assert string, which originates from https://github.com/torvalds/linux/blob/v5.2-rc7/include/linux/compiler-gcc.h#L76 and https://github.com/torvalds/linux/blob/v5.2-rc7/include/linux/compiler.h#L324.

nickdesaulniers · 2019-07-03T21:29:21Z

Wasn't able to come up with a short reproducer: https://godbolt.org/z/tR9v22
Maybe creduce to the rescue?

Also, is that the correct snippet of preprocessed source? The number/counter suffix on those __compiletime_assert_s doesn't match the linker failure (but maybe your source changed between runs)?

nathanchance · 2019-07-03T21:32:49Z

I tried creduce but it seems to get stuck around 50%. I'll have to try again.

Yes, it is the right snippet. I don't think I used the same revision between runs.

nathanchance · 2019-07-04T03:17:52Z

I have tried getting creduce to work with the following interestingness script, along with some tricks to try to get it to keep __compiletime_assert_* around but it just seems to get past the replace-function-def-with-decl pass then hang at the remove-unused-function pass.

#!/bin/bash

rm -rf /root/creduce/dbg.o

/root/tc-build/install/bin/clang -c -o /root/creduce/dbg.o /root/creduce/dbg.i &>/dev/null && \
nm /root/creduce/dbg.o | grep __compiletime_assert_2446

dbg.i

Does the interestingness test need to be improved or is creduce just not going to work for this?

nathanchance · 2019-07-05T19:18:17Z

Figured out what I was doing wrong: the dbg.i and dbg.o need to be relative so that they are properly tested by creduce. This bit in the README clued me in:

Each invocation of the interestingness test is performed in a fresh temporary directory containing a copy of the file that is being reduced.

I am attempting to properly reduce now.

nathanchance · 2019-07-05T22:41:28Z

Turns out this is somehow related to CONFIG_KASAN...

creduce spits out:

a;
b() {
  char c[] = "WRT ext=%d. Invalid %s name length %d expected %d\n";
  if (a)
    if (c[sizeof(c) - 2] != '\n')
      __compiletime_assert_2446__iwl_warn(c);
}

with the following interestingness test:

#!/bin/bash

gcc -O2 -c -o dbg-gcc.o dbg.i && \
! nm dbg-gcc.o | grep __compiletime_assert_2446 && \
/home/nathan/cbl/usr/bin/clang -O2 -no-integrated-as -c -o dbg-clang.o dbg.i && \
! nm dbg-clang.o | grep __compiletime_assert_2446 && \
/home/nathan/cbl/usr/bin/clang -O2 -no-integrated-as -fsanitize=kernel-address -c -o dbg-clang.o dbg.i && \
nm dbg-clang.o | grep __compiletime_assert_2446

The code generation massively changes with -fsanitize=kernel-address: https://godbolt.org/z/njzBEf

nickdesaulniers · 2019-07-08T07:36:41Z

cc @ramosian-glider

nickdesaulniers · 2019-07-10T22:01:57Z

I feel like

#define CHECK_FOR_NEWLINE(f) BUILD_BUG_ON(f[sizeof(f) - 2] != '\n')

/* No matter what is m (priv, bus, trans), this will work */
#define IWL_ERR_DEV(d, f, a...)						\
	do {								\
		CHECK_FOR_NEWLINE(f);					\
		__iwl_err((d), false, false, f, ## a);			\
	} while (0)

should be replaced with:

#define IWL_ERR_DEV(d, f, a...) \
    do { \
        __iwl_err((d), false, false, f "\n", ## a); \
    } while (0)

That way the preprocessor just always appends a new line to the format string. Then callers never need to remember to add a newline, and there's no non-portable obscure linkage failure. And worst case, there's two newlines which is no big deal. cc @gburgessiv

nathanchance · 2019-07-11T05:34:35Z

I don't think that is a terrible idea. It might be worth sending along as an RFC to the iwlwifi maintainers just to gauge their reactions.

However, I think it is rather interesting that KASAN prevents clang from being able to figure out that that string does end with a newline character and that should still probably be looked into.

nickdesaulniers · 2019-07-11T17:19:58Z

However, I think it is rather interesting that KASAN prevents clang from being able to figure out that that string does end with a newline character and that should still probably be looked into.

Quoting @gburgessiv :

sanitizers make DCE way harder, since they can add a lot of uncertainty to codepaths that were previously pretty trivial. in this case, assuming asan instruments the accesses to the non-const array, it's probably reasonable for llvm to be conservative and assume the array changes somehow
in which case, constant folding can't happen

nathanchance · 2019-07-11T17:21:43Z

That makes sense then, worth bringing up to the maintainers and see how they react.

nickdesaulniers · 2019-07-11T18:01:05Z

@arndb filed an upstream bug: https://llvm.org/pr42580

nathanchance · 2019-07-11T20:20:29Z

I bisected using Arnd's reproducer: https://llvm.org/pr42580

nickdesaulniers · 2019-07-11T23:28:12Z

@nathanchance can you provide steps to reproduce? I cannot repro with:

x86 defconfig + CONFIG_IWLWIFI + CONFIG_KASAN

➜  linux-next git:(master) ✗ ag IWL_WARN | wc -l
75
➜  linux-next git:(master) ✗ ag IWL_INFO | wc -l
36
➜  linux-next git:(master) ✗ ag IWL_CRIT | wc -l
2
➜  linux-next git:(master) ✗ ag IWL_ERR | wc -l 
618

:(

nathanchance · 2019-07-11T23:39:45Z

I can reproduce with x86_64_defconfig +

CONFIG_EXPERT=y
CONFIG_PM=y
CONFIG_DEBUG_FS=y
CONFIG_MAC80211_DEBUGFS=y
CONFIG_IWLWIFI=y
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLDVM=y
CONFIG_IWLMVM=y
CONFIG_IWLWIFI_BCAST_FILTERING=y
CONFIG_IWLWIFI_PCIE_RTPM=y
CONFIG_IWLWIFI_DEBUG=y
CONFIG_IWLWIFI_DEBUGFS=y
CONFIG_IWLWIFI_DEVICE_TRACING=y
CONFIG_KASAN=y

For my bisect, I used Arnd's test case and the following script:

#!/bin/bash

/home/nathan/cbl/tc-build/build/llvm/stage1/bin/clang -O2 -fsanitize=kernel-address -Wno-implicit-int -Wno-return-type -c -o test.o test.c
nm test.o | grep compiletime_assert

nickdesaulniers · 2019-07-11T23:40:27Z

Eli mentions on the LLVM bug that marking err_str in iwl_fw_dbg_info_apply may help.

nickdesaulniers · 2019-07-12T00:01:07Z

CONFIG_IWLMVM is needed to compile drivers/net/wireless/intel/iwlwifi/fw/dbg.o. Then I can repro.

nickdesaulniers · 2019-07-12T00:04:20Z

diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index e411ac98290d..f8c90ea4e9b4 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -2438,7 +2438,7 @@ static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
 {
        u32 img_name_len = le32_to_cpu(dbg_info->img_name_len);
        u32 dbg_cfg_name_len = le32_to_cpu(dbg_info->dbg_cfg_name_len);
-       const char err_str[] =
+       static const char err_str[] =
                "WRT: ext=%d. Invalid %s name length %d, expected %d\n";
 
        if (img_name_len != IWL_FW_INI_MAX_IMG_NAME_LEN) {
@@ -2775,7 +2775,7 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
                struct iwl_ucode_tlv *tlv = iter;
                void *ini_tlv = (void *)tlv->data;
                u32 type = le32_to_cpu(tlv->type);
-               const char invalid_ap_str[] =
+               static const char invalid_ap_str[] =
                        "WRT: ext=%d. Invalid apply point %d for %s\n";
 
                switch (type) {

is a fix. Packaging it up now.

nickdesaulniers · 2019-07-12T00:19:23Z

https://lore.kernel.org/r/20190712001708.170259-1-ndesaulniers@google.com/

nathanchance · 2019-08-02T08:38:30Z

This was fixed by an internal Intel patch (GCC 4.6.3 errors finally brought it out...): https://git.kernel.org/kvalo/wireless-drivers/c/1f66072503316134873060b24b7895dbbcccf00e

It is now in -next, hopefully will be in 5.3-rc3 if we are lucky.

dileks · 2019-08-06T22:30:20Z

net.git#master has it now, so it should go soon in Linux v5.3-rc3+.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=1f66072503316134873060b24b7895dbbcccf00e

nathanchance · 2019-08-07T00:35:50Z

Fixed: https://git.kernel.org/linus/1f66072503316134873060b24b7895dbbcccf00e

nathanchance added [BUG] Untriaged [ARCH] x86_64 [BUG] linux-next labels Jul 1, 2019

nickdesaulniers added [BUG] llvm [PATCH] Exists and removed [BUG] Untriaged labels Jul 12, 2019

nickdesaulniers self-assigned this Jul 12, 2019

nickdesaulniers added [PATCH] Submitted and removed [PATCH] Exists labels Jul 12, 2019

nathanchance added [BUG] linux and removed [BUG] linux-next labels Jul 12, 2019

nathanchance added [PATCH] Accepted and removed [PATCH] Submitted labels Aug 2, 2019

nathanchance closed this as completed Aug 7, 2019

nathanchance added [FIXED][LINUX] 5.3 and removed [PATCH] Accepted labels Aug 7, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

__compiletime_assert in drivers/net/wireless/intel/iwlwifi/fw/dbg.c #580

__compiletime_assert in drivers/net/wireless/intel/iwlwifi/fw/dbg.c #580

nathanchance commented Jul 1, 2019

nickdesaulniers commented Jul 2, 2019

nathanchance commented Jul 2, 2019 •

edited

Loading

nathanchance commented Jul 3, 2019

nickdesaulniers commented Jul 3, 2019 •

edited

Loading

nathanchance commented Jul 3, 2019

nathanchance commented Jul 3, 2019

nickdesaulniers commented Jul 3, 2019

nathanchance commented Jul 3, 2019

nathanchance commented Jul 4, 2019

nathanchance commented Jul 5, 2019 •

edited

Loading

nathanchance commented Jul 5, 2019 •

edited

Loading

nickdesaulniers commented Jul 8, 2019

nickdesaulniers commented Jul 10, 2019

nathanchance commented Jul 11, 2019

nickdesaulniers commented Jul 11, 2019

nathanchance commented Jul 11, 2019

nickdesaulniers commented Jul 11, 2019 •

edited by nathanchance

Loading

nathanchance commented Jul 11, 2019 •

edited

Loading

nickdesaulniers commented Jul 11, 2019

nathanchance commented Jul 11, 2019

nickdesaulniers commented Jul 11, 2019

nickdesaulniers commented Jul 12, 2019

nickdesaulniers commented Jul 12, 2019

nickdesaulniers commented Jul 12, 2019 •

edited by nathanchance

Loading

nathanchance commented Aug 2, 2019

dileks commented Aug 6, 2019

nathanchance commented Aug 7, 2019

__compiletime_assert in drivers/net/wireless/intel/iwlwifi/fw/dbg.c #580

__compiletime_assert in drivers/net/wireless/intel/iwlwifi/fw/dbg.c #580

Comments

nathanchance commented Jul 1, 2019

nickdesaulniers commented Jul 2, 2019

nathanchance commented Jul 2, 2019 • edited Loading

nathanchance commented Jul 3, 2019

nickdesaulniers commented Jul 3, 2019 • edited Loading

nathanchance commented Jul 3, 2019

nathanchance commented Jul 3, 2019

nickdesaulniers commented Jul 3, 2019

nathanchance commented Jul 3, 2019

nathanchance commented Jul 4, 2019

nathanchance commented Jul 5, 2019 • edited Loading

nathanchance commented Jul 5, 2019 • edited Loading

nickdesaulniers commented Jul 8, 2019

nickdesaulniers commented Jul 10, 2019

nathanchance commented Jul 11, 2019

nickdesaulniers commented Jul 11, 2019

nathanchance commented Jul 11, 2019

nickdesaulniers commented Jul 11, 2019 • edited by nathanchance Loading

nathanchance commented Jul 11, 2019 • edited Loading

nickdesaulniers commented Jul 11, 2019

nathanchance commented Jul 11, 2019

nickdesaulniers commented Jul 11, 2019

nickdesaulniers commented Jul 12, 2019

nickdesaulniers commented Jul 12, 2019

nickdesaulniers commented Jul 12, 2019 • edited by nathanchance Loading

nathanchance commented Aug 2, 2019

dileks commented Aug 6, 2019

nathanchance commented Aug 7, 2019

nathanchance commented Jul 2, 2019 •

edited

Loading

nickdesaulniers commented Jul 3, 2019 •

edited

Loading

nathanchance commented Jul 5, 2019 •

edited

Loading

nathanchance commented Jul 5, 2019 •

edited

Loading

nickdesaulniers commented Jul 11, 2019 •

edited by nathanchance

Loading

nathanchance commented Jul 11, 2019 •

edited

Loading

nickdesaulniers commented Jul 12, 2019 •

edited by nathanchance

Loading