Message ID | 20230616090705.2623408-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp1196241vqr; Fri, 16 Jun 2023 02:28:00 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6HEDieWDQUDIluL0ZsCrz2JI1T7bOSGYe0KNM8mUqNul+Pom0AwwSbi3S5+EQKJxgczWmL X-Received: by 2002:a05:6a20:8e26:b0:11e:e87b:2b5e with SMTP id y38-20020a056a208e2600b0011ee87b2b5emr1499549pzj.37.1686907680498; Fri, 16 Jun 2023 02:28:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686907680; cv=none; d=google.com; s=arc-20160816; b=BYOiCZ/h1AVJkr3ojlPNvD+qX/C/8HDrVuK6MqtOPZppEDHVL9qJwT+AYa4J/m4aKE QQzPRYuCAjobTaeBET7uEgFsDFOJlSHHscNH29I66Gd1BygJ9e1ulglRz3DMPx263rQZ 2wUubgcPH2nWLx4VD7f1QMW1HhVi/YpKkW/7ibKkEiiB7GK3D8pKOopjRZESjhl91523 wPwZG1udaChW/8XGxXOJgqD/TM+C3tWn1Eu6qB/wqd9fdOKPsoLO1PPjahcnvG1dWvEq MtqOxFcWgQlNU4NJNu0peFhF0vKGyBCLSRPNIQBXlY5pwu/W0LiqCKAf9c7iS051EzYy pQ1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=UN5/xC2LQnuIq6pe3my2tOKtEIaFKRV7fCpFOWOU4So=; b=JY25Rn70Ez1v80FhbGykrZyqVyyR+M77LJIiGyhK1vdDK7W4SuS8HlTmfzMt3diru/ bwmQVuIQRGGT+Dkm6BBSZ2HxluQbLerfUPKHQm9IQ6B9ilaxWIky77jvz/cKKzAad+f9 xuXLUFSZ/l2ZYlox6ysDrwDxVO51B7VlYuiI3eVs2UcaG3y2k5lSdsWboQUWZnk0uaaG AQCV72K3m41SYYHAetMBDb7LRoBMGFH+QJyyMEnc852OCMrxhAD30wR+6SFqNDx3MYoc 8wbLqQBsCxkxsDrGe1Xm+m3jUwxJIty+yYHiz/J1Pg2smzDrRZOt+XxXYmzUeoPg7dNy G8lA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Fzi//9Zx"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u3-20020a170902e5c300b001ab29399c72si14651806plf.502.2023.06.16.02.27.46; Fri, 16 Jun 2023 02:28:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="Fzi//9Zx"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343985AbjFPJJQ (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Fri, 16 Jun 2023 05:09:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245052AbjFPJIz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 16 Jun 2023 05:08:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 499AE423E; Fri, 16 Jun 2023 02:07:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CAC5461844; Fri, 16 Jun 2023 09:07:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 161B3C433C0; Fri, 16 Jun 2023 09:07:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686906432; bh=SssK4C+MROZYzi+b4Qyu0IIYF+H8yC2OIjf9lSsuvAQ=; h=From:To:Cc:Subject:Date:From; b=Fzi//9ZxgLWQfoZfdtXHI64hId/FbDLxPXsJA0sig9i/8y+vTgILgL3B0gbK78OgQ pWOqcI8a3q2uq8HLkgEfQ5zCkQGXAk3VO3Yy3K3/E6WFGUtTB+LZlkl2Gdy8x2q544 0BIm/723DnL+o3tMD/pJX6xIBGKG8qP1xinjGVCtWoaU6ikf9qqLsx9J4aqYECkrE9 d/ay8T+HcYRMl9UHHkPDM9hD8fsPNos8NNmLtD1Xo5YtAY2ed8TDRXod1Aj29JnmR/ mBA0S/t6/zjEWn1Rba8+mxH2EDydli+aEWC9MgbUzd/5QvtF6/mCmbvALM99j5ypBe tnh/wyjYUlFEQ== From: Arnd Bergmann <arnd@kernel.org> To: James Smart <james.smart@broadcom.com>, Dick Kennedy <dick.kennedy@broadcom.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>, Justin Tee <justin.tee@broadcom.com>, Kees Cook <keescook@chromium.org>, "Gustavo A. R. Silva" <gustavoars@kernel.org>, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: [PATCH] scsi: lpfc: fix lpfc_name struct packing Date: Fri, 16 Jun 2023 11:06:56 +0200 Message-Id: <20230616090705.2623408-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768850908035372088?= X-GMAIL-MSGID: =?utf-8?q?1768850908035372088?= |
Series |
scsi: lpfc: fix lpfc_name struct packing
|
|
Commit Message
Arnd Bergmann
June 16, 2023, 9:06 a.m. UTC
From: Arnd Bergmann <arnd@arndb.de> clang points out that the lpfc_name structure has an 8-byte alignement requirement on most architectures, but is embedded in a number of other structures that are forced to be only 1-byte aligned: drivers/scsi/lpfc/lpfc_hw.h:1516:30: error: field pe within 'struct lpfc_fdmi_reg_port_list' is less aligned than 'struct lpfc_fdmi_port_entry' and is usually due to 'struct lpfc_fdmi_reg_port_list' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] struct lpfc_fdmi_port_entry pe; drivers/scsi/lpfc/lpfc_hw.h:850:19: error: field portName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] drivers/scsi/lpfc/lpfc_hw.h:851:19: error: field nodeName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] drivers/scsi/lpfc/lpfc_hw.h:922:19: error: field portName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] drivers/scsi/lpfc/lpfc_hw.h:923:19: error: field nodeName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] From the git history, I can see that all the __packed annotations were done specifically to avoid introducing implicit padding around the lpfc_name instances, though this was probably the wrong approach. To improve this, only annotate the one uint64_t field inside of lpfc_name as packed, with an explicit 4-byte alignment, as is the default already on the 32-bit x86 ABI but not on most others. With this, the other __packed annotations can be removed again, as this avoids the incorrect padding. Two other structures change their layout as a result of this change: - struct _LOGO never gained a __packed annotation even though it has the same alignment problem as the others but is not used anywhere in the driver today. - struct serv_param similarly has this issue, and it is used, my guess is that this is only an internal structure rather than part of a binary interface, so the padding has no negative effect here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/scsi/lpfc/lpfc_hw.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
Comments
Hi Arnd, Thanks looks good. Reviewed-by: Justin Tee <justin.tee@broadcom.com> On Fri, Jun 16, 2023 at 2:07 AM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > clang points out that the lpfc_name structure has an 8-byte alignement requirement > on most architectures, but is embedded in a number of other structures that are > forced to be only 1-byte aligned: > > drivers/scsi/lpfc/lpfc_hw.h:1516:30: error: field pe within 'struct lpfc_fdmi_reg_port_list' is less aligned than 'struct lpfc_fdmi_port_entry' and is usually due to 'struct lpfc_fdmi_reg_port_list' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > struct lpfc_fdmi_port_entry pe; > drivers/scsi/lpfc/lpfc_hw.h:850:19: error: field portName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > drivers/scsi/lpfc/lpfc_hw.h:851:19: error: field nodeName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > drivers/scsi/lpfc/lpfc_hw.h:922:19: error: field portName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > drivers/scsi/lpfc/lpfc_hw.h:923:19: error: field nodeName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > > From the git history, I can see that all the __packed annotations were done > specifically to avoid introducing implicit padding around the lpfc_name > instances, though this was probably the wrong approach. > > To improve this, only annotate the one uint64_t field inside of lpfc_name > as packed, with an explicit 4-byte alignment, as is the default already on > the 32-bit x86 ABI but not on most others. With this, the other __packed > annotations can be removed again, as this avoids the incorrect padding. > > Two other structures change their layout as a result of this change: > > - struct _LOGO never gained a __packed annotation even though it has the > same alignment problem as the others but is not used anywhere in the > driver today. > > - struct serv_param similarly has this issue, and it is used, my guess > is that this is only an internal structure rather than part of a binary > interface, so the padding has no negative effect here. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/scsi/lpfc/lpfc_hw.h | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/scsi/lpfc/lpfc_hw.h b/drivers/scsi/lpfc/lpfc_hw.h > index 663755842e4a4..aaea3e31944d0 100644 > --- a/drivers/scsi/lpfc/lpfc_hw.h > +++ b/drivers/scsi/lpfc/lpfc_hw.h > @@ -365,7 +365,7 @@ struct lpfc_name { > uint8_t IEEE[6]; /* FC IEEE address */ > } s; > uint8_t wwn[8]; > - uint64_t name; > + uint64_t name __packed __aligned(4); > } u; > }; > > @@ -850,7 +850,7 @@ typedef struct _ADISC { /* Structure is in Big Endian format */ > struct lpfc_name portName; > struct lpfc_name nodeName; > uint32_t DID; > -} __packed ADISC; > +} ADISC; > > typedef struct _FARP { /* Structure is in Big Endian format */ > uint32_t Mflags:8; > @@ -880,7 +880,7 @@ typedef struct _FAN { /* Structure is in Big Endian format */ > uint32_t Fdid; > struct lpfc_name FportName; > struct lpfc_name FnodeName; > -} __packed FAN; > +} FAN; > > typedef struct _SCR { /* Structure is in Big Endian format */ > uint8_t resvd1; > @@ -924,7 +924,7 @@ typedef struct _RNID { /* Structure is in Big Endian format */ > union { > RNID_TOP_DISC topologyDisc; /* topology disc (0xdf) */ > } un; > -} __packed RNID; > +} RNID; > > struct RLS { /* Structure is in Big Endian format */ > uint32_t rls; > @@ -1514,7 +1514,7 @@ struct lpfc_fdmi_hba_ident { > struct lpfc_fdmi_reg_port_list { > __be32 EntryCnt; > struct lpfc_fdmi_port_entry pe; > -} __packed; > +}; > > /* > * Register HBA(RHBA) > -- > 2.39.2 >
Arnd, > clang points out that the lpfc_name structure has an 8-byte alignement > requirement on most architectures, but is embedded in a number of > other structures that are forced to be only 1-byte aligned: Applied to 6.5/scsi-staging, thanks!
On Fri, 16 Jun 2023 11:06:56 +0200, Arnd Bergmann wrote: > clang points out that the lpfc_name structure has an 8-byte alignement requirement > on most architectures, but is embedded in a number of other structures that are > forced to be only 1-byte aligned: > > drivers/scsi/lpfc/lpfc_hw.h:1516:30: error: field pe within 'struct lpfc_fdmi_reg_port_list' is less aligned than 'struct lpfc_fdmi_port_entry' and is usually due to 'struct lpfc_fdmi_reg_port_list' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > struct lpfc_fdmi_port_entry pe; > drivers/scsi/lpfc/lpfc_hw.h:850:19: error: field portName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > drivers/scsi/lpfc/lpfc_hw.h:851:19: error: field nodeName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > drivers/scsi/lpfc/lpfc_hw.h:922:19: error: field portName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > drivers/scsi/lpfc/lpfc_hw.h:923:19: error: field nodeName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] > > [...] Applied to 6.5/scsi-queue, thanks! [1/1] scsi: lpfc: fix lpfc_name struct packing https://git.kernel.org/mkp/scsi/c/00c2cae6b66a
diff --git a/drivers/scsi/lpfc/lpfc_hw.h b/drivers/scsi/lpfc/lpfc_hw.h index 663755842e4a4..aaea3e31944d0 100644 --- a/drivers/scsi/lpfc/lpfc_hw.h +++ b/drivers/scsi/lpfc/lpfc_hw.h @@ -365,7 +365,7 @@ struct lpfc_name { uint8_t IEEE[6]; /* FC IEEE address */ } s; uint8_t wwn[8]; - uint64_t name; + uint64_t name __packed __aligned(4); } u; }; @@ -850,7 +850,7 @@ typedef struct _ADISC { /* Structure is in Big Endian format */ struct lpfc_name portName; struct lpfc_name nodeName; uint32_t DID; -} __packed ADISC; +} ADISC; typedef struct _FARP { /* Structure is in Big Endian format */ uint32_t Mflags:8; @@ -880,7 +880,7 @@ typedef struct _FAN { /* Structure is in Big Endian format */ uint32_t Fdid; struct lpfc_name FportName; struct lpfc_name FnodeName; -} __packed FAN; +} FAN; typedef struct _SCR { /* Structure is in Big Endian format */ uint8_t resvd1; @@ -924,7 +924,7 @@ typedef struct _RNID { /* Structure is in Big Endian format */ union { RNID_TOP_DISC topologyDisc; /* topology disc (0xdf) */ } un; -} __packed RNID; +} RNID; struct RLS { /* Structure is in Big Endian format */ uint32_t rls; @@ -1514,7 +1514,7 @@ struct lpfc_fdmi_hba_ident { struct lpfc_fdmi_reg_port_list { __be32 EntryCnt; struct lpfc_fdmi_port_entry pe; -} __packed; +}; /* * Register HBA(RHBA)