From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9732EC433EF for ; Wed, 1 Dec 2021 17:30:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EF326B0075; Wed, 1 Dec 2021 12:30:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 19C546B007B; Wed, 1 Dec 2021 12:30:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08B506B007D; Wed, 1 Dec 2021 12:30:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id EEFCE6B0075 for ; Wed, 1 Dec 2021 12:30:13 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AB5B57F6F2 for ; Wed, 1 Dec 2021 17:30:03 +0000 (UTC) X-FDA: 78869913486.30.8AC2394 Received: from sipsolutions.net (s3.sipsolutions.net [144.76.43.62]) by imf11.hostedemail.com (Postfix) with ESMTP id 3B5C6F0000B8 for ; Wed, 1 Dec 2021 17:30:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=Content-Transfer-Encoding:MIME-Version: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=3+enRW4wqvxQSzs2ckAuZdLgTzu8Rxf6BfXjB+5YXoI=; t=1638379802; x=1639589402; b=sEvx2iTWhnIuig03pB/gf0N0pFqJJ+tyK0Fu60cEzBF8g5d gYrkO+PxxgQjunaoyDEFOoPM4rav6OtgGVWardgh/79rI2P9OVc9wsI76Ir73xhqHm+4V+K6fVDWo tsP5bus/biBdIpjGORTDa5Z3mrONLFIItcnVC+/YrXLN+JGkemc7wgMOHDubbbc0oAzNquApEO+k1 LYpEYbwL/ZJYkNuDHXe4or4vmf641zYvQp81o4hULy2qKlQZF/cm0zJvH30Wpps/YuzPoy6rDI5Px pngAG0ufCAVfpZeFT9618qQdwtCrO7V89+PsZtdCnPCgx5WcNqQeXbK24SKI3qNw==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.95) (envelope-from ) id 1msTQU-005Vc0-PL; Wed, 01 Dec 2021 18:29:50 +0100 Message-ID: <17ccfc4f9f9e74e1d6b48366a87cbcf887521dab.camel@sipsolutions.net> Subject: Re: [linux-next:master 3615/4301] 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 From: Johannes Berg To: Kees Cook , Kalle Valo Cc: kernel test robot , kbuild-all@lists.01.org, Linux Memory Management List , linux-wireless@vger.kernel.org Date: Wed, 01 Dec 2021 18:29:49 +0100 In-Reply-To: <202112010840.0AD4D41162@keescook> References: <202111302102.apaePz2J-lkp@intel.com> <87pmqgsrcq.fsf@codeaurora.org> <202112010840.0AD4D41162@keescook> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 (3.42.1-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned X-Stat-Signature: rh4hjpox3c4us6ouip1p9jgfbh67djq9 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=sipsolutions.net header.s=mail header.b=sEvx2iTW; dmarc=pass (policy=none) header.from=sipsolutions.net; spf=pass (imf11.hostedemail.com: domain of johannes@sipsolutions.net designates 144.76.43.62 as permitted sender) smtp.mailfrom=johannes@sipsolutions.net X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3B5C6F0000B8 X-HE-Tag: 1638379803-148459 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 2021-12-01 at 08:41 -0800, Kees Cook wrote: > > > > 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