include/linux/compiler_types.h:335:45: error: call to '__compiletime_assert_314' declared with attribute error: BUILD_BUG_ON failed: sizeof(txpd->tx_dest_addr) != ETH_ALEN
335 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:316:25: note: in definition of macro '__compiletime_assert'
316 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:335:9: note: in expansion of macro '_compiletime_assert'
335 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
drivers/net/wireless/marvell/libertas/tx.c:116:9: note: in expansion of macro 'BUILD_BUG_ON'
116 | BUILD_BUG_ON(sizeof(txpd->tx_dest_addr) != ETH_ALEN);
| ^~~~~~~~~~~~
Kees, can you take a look at this build error? You added the
BUILD_BUG_ON(), right?
I will investigate! Given this doesn't happen on allmodconfig but
a randconfig trips it, this might be finding a legit issue, but I'll
report back more details.
Thanks for the heads-up!
--
Kees Cook
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-12-01 17:30:24
On Wed, 2021-12-01 at 08:41 -0800, Kees Cook wrote:
quoted
quoted
drivers/net/wireless/marvell/libertas/tx.c:116:9: note: in expansion of macro 'BUILD_BUG_ON'
116 | BUILD_BUG_ON(sizeof(txpd->tx_dest_addr) != ETH_ALEN);
| ^~~~~~~~~~~~
Kees, can you take a look at this build error? You added the
BUILD_BUG_ON(), right?
I will investigate! Given this doesn't happen on allmodconfig but
a randconfig trips it, this might be finding a legit issue, but I'll
report back more details.
It's probably some alignment thing - note it happened on a specific ARM
with a specific compiler?
But there's not really a good reason to even have the struct_group here,
we only use it as if it was
u8 tx_dest_addr[ETH_ALEN];
anyway?
johannes
On Wed, Dec 01, 2021 at 06:29:49PM +0100, Johannes Berg wrote:
On Wed, 2021-12-01 at 08:41 -0800, Kees Cook wrote:
quoted
quoted
quoted
drivers/net/wireless/marvell/libertas/tx.c:116:9: note: in expansion of macro 'BUILD_BUG_ON'
116 | BUILD_BUG_ON(sizeof(txpd->tx_dest_addr) != ETH_ALEN);
| ^~~~~~~~~~~~
Kees, can you take a look at this build error? You added the
BUILD_BUG_ON(), right?
I will investigate! Given this doesn't happen on allmodconfig but
a randconfig trips it, this might be finding a legit issue, but I'll
report back more details.
It's probably some alignment thing - note it happened on a specific ARM
with a specific compiler?
Yup, that was it. It's an interesting bit of "accidentally correct"
problems that I think I've now fixed with this series:
https://lore.kernel.org/all/20211201173234.578124-1-keescook@chromium.org/
My pahole before/after testing appears to have been too limited and
missed this case. :( I'm currently reviewing all the others I've sent as
well.
But there's not really a good reason to even have the struct_group here,
we only use it as if it was
u8 tx_dest_addr[ETH_ALEN];
anyway?
Ah yeah, nothing uses tx_dest_addr_high nor tx_dest_addr_low. Should I
send another patch to just rip out the struct_group entirely?
--
Kees Cook
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-12-01 19:38:11
On Wed, 2021-12-01 at 11:04 -0800, Kees Cook wrote:
On Wed, Dec 01, 2021 at 06:29:49PM +0100, Johannes Berg wrote:
quoted
On Wed, 2021-12-01 at 08:41 -0800, Kees Cook wrote:
quoted
quoted
quoted
drivers/net/wireless/marvell/libertas/tx.c:116:9: note: in expansion of macro 'BUILD_BUG_ON'
116 | BUILD_BUG_ON(sizeof(txpd->tx_dest_addr) != ETH_ALEN);
| ^~~~~~~~~~~~
Kees, can you take a look at this build error? You added the
BUILD_BUG_ON(), right?
I will investigate! Given this doesn't happen on allmodconfig but
a randconfig trips it, this might be finding a legit issue, but I'll
report back more details.
It's probably some alignment thing - note it happened on a specific ARM
with a specific compiler?