Message ID | ZG0fDdY/PPQ/ijlt@work |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2403293vqo; Tue, 23 May 2023 13:36:25 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6n7RmRJ+Zj2yIN4iXFBIoLToWTzzDIBcMPY5NtDChthNWHxWTZMmcFyjawBVQZAMWgj+PE X-Received: by 2002:a05:6a20:4306:b0:104:1428:8d36 with SMTP id h6-20020a056a20430600b0010414288d36mr15591180pzk.35.1684874185052; Tue, 23 May 2023 13:36:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684874185; cv=none; d=google.com; s=arc-20160816; b=tneFbdXfakLyxzIERaQPutO55J6jsze2TgZILTX/nNq3IQMs7JI1SMuFICLuuzKUzo lYxkqsdvHxoOHF41h2KsUYcWl+t0ahuAa6IDTeMSAPkIh29TIj/2xI636Dr6DDyL4sXs MkkeGxLhH7CTVdGDaHHWbO1OQEMH+yvRrgYGX651jn6dWUKuBsl1cohCSEQ2vz4XtDcJ SKaFM+hFTjGFyfogSOkc/jkkzd1EPr5UxNW4bhi1VnbbV4nr5WsbQn9Poh9x/vsV6xlo lNXeug7/Ejqf3EnWgUJm2QIYGbkns3QIBAtKGgbhIN2d0xtJdOUx574xZxvK+Uoch+TM xs5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=hWWoTAGOnGK9lFW0Dq35O55vYi6PaK/pirfzqjUAvPM=; b=Z1QN68y2Kgy3xz0sqXHPVzMfCRnFB3J1HfV8WyR0RXYnOYwzCXX8fDXoAqXsFH7jKc 97Prj8UGBmnPss+9a+jrW1PUqfUudPp7Z1VIn7U9Ux+wyVfGzOgwD2Z+AZI1l3Jyu9wD zAT4DfgtF/GA0fpVv+1Ew4706XFoi981FrF3edTfuMuqOrHfxjnR86EbFErcpQPEIPWo xffPAizGBupH+UMrGQPkknbtvImihyc3BU5rcfJ30dEIfA8drYv/gW0qkyRIMk34FQjb LI7gLiyRJqX3oroLskVQjRu/YeHji45NZn/iuvXhxiXiGQG8J0GvVcpjQpbkbTn83xiZ S0/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VtH6B7Wz; 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 206-20020a6300d7000000b00517aa9db92dsi3396597pga.396.2023.05.23.13.36.12; Tue, 23 May 2023 13:36:25 -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=VtH6B7Wz; 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 S238530AbjEWUPZ (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Tue, 23 May 2023 16:15:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234164AbjEWUPX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 23 May 2023 16:15:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B2D5129; Tue, 23 May 2023 13:15:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DA75461272; Tue, 23 May 2023 20:15:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F10F5C433EF; Tue, 23 May 2023 20:15:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684872921; bh=bY6N2RxrtkdOJFb0NaV4w4DW0/gqoN0tnW3Zao2HvYs=; h=Date:From:To:Cc:Subject:From; b=VtH6B7WzLJnkm8MmBMlZKipm/TbzeB4OX83fSJgoGJ5oQ2CUPK9ftS5U+bOcPV2NY K36tlHrkzJQ7hIKjyEP6+eMmgQucr12O4S8p2F9b4ZW/qy6kcOC0yIpMF36HuWlPgL erqzRg86D56gfnFn66FoSvOhR935/mVd1ep2Qul4MTE5AXfZomouGrlHCUt8Q1VdO1 VnzGJj4jYVVecWXH8HALGANFWejiL0IhawonWUGH6apKlvrtXPCqV3xzzEemT6Nqtx keZtujjY5IBag47VzYQHcwZmf0abFZM3rWG79aMOVjeCVRhn4P5j6evgtZfzUdPRrj IWga5Zh5hVcUg== Date: Tue, 23 May 2023 14:16:13 -0600 From: "Gustavo A. R. Silva" <gustavoars@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: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, "Gustavo A. R. Silva" <gustavoars@kernel.org>, linux-hardening@vger.kernel.org, Kees Cook <keescook@chromium.org> Subject: [PATCH v2][next] scsi: lpfc: Use struct_size() helper Message-ID: <ZG0fDdY/PPQ/ijlt@work> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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?1766718633129889852?= X-GMAIL-MSGID: =?utf-8?q?1766718633129889852?= |
Series |
[v2,next] scsi: lpfc: Use struct_size() helper
|
|
Commit Message
Gustavo A. R. Silva
May 23, 2023, 8:16 p.m. UTC
Prefer struct_size() over open-coded versions of idiom:
sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count
where count is the max number of items the flexible array is supposed to
contain.
Link: https://github.com/KSPP/linux/issues/160
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
Changes in v2:
- Use literal 1 in call to struct_size(), instead of rap->no_of_objects
(Kees Cook).
v1:
- Link: https://lore.kernel.org/linux-hardening/99e06733f5f35c6cd62e05f530b93107bfd03362.1684358315.git.gustavoars@kernel.org/
drivers/scsi/lpfc/lpfc_ct.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
Comments
no_of_objects may be hardcoded to 1 right now, but does it make more sense to use? struct_size(rap, obj, be32_to_cpu(rap->no_of_objects)); We probably should have declared no_of_objects as __be32 to have avoided this confusion. On Tue, May 23, 2023 at 1:33 PM Gustavo A. R. Silva <gustavoars@kernel.org> wrote: > > Prefer struct_size() over open-coded versions of idiom: > > sizeof(struct-with-flex-array) + sizeof(typeof-flex-array-elements) * count > > where count is the max number of items the flexible array is supposed to > contain. > > Link: https://github.com/KSPP/linux/issues/160 > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > Changes in v2: > - Use literal 1 in call to struct_size(), instead of rap->no_of_objects > (Kees Cook). > > v1: > - Link: https://lore.kernel.org/linux-hardening/99e06733f5f35c6cd62e05f530b93107bfd03362.1684358315.git.gustavoars@kernel.org/ > > drivers/scsi/lpfc/lpfc_ct.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c > index e880d127d7f5..f52aeb73af8d 100644 > --- a/drivers/scsi/lpfc/lpfc_ct.c > +++ b/drivers/scsi/lpfc/lpfc_ct.c > @@ -3747,9 +3747,7 @@ lpfc_vmid_cmd(struct lpfc_vport *vport, > rap->no_of_objects = cpu_to_be32(1); > rap->obj[0].entity_id_len = vmid->vmid_len; > memcpy(rap->obj[0].entity_id, vmid->host_vmid, vmid->vmid_len); > - size = RAPP_IDENT_OFFSET + > - sizeof(struct lpfc_vmid_rapp_ident_list) + > - sizeof(struct entity_id_object); > + size = RAPP_IDENT_OFFSET + struct_size(rap, obj, 1); > retry = 1; > break; > > @@ -3767,9 +3765,7 @@ lpfc_vmid_cmd(struct lpfc_vport *vport, > dap->no_of_objects = cpu_to_be32(1); > dap->obj[0].entity_id_len = vmid->vmid_len; > memcpy(dap->obj[0].entity_id, vmid->host_vmid, vmid->vmid_len); > - size = DAPP_IDENT_OFFSET + > - sizeof(struct lpfc_vmid_dapp_ident_list) + > - sizeof(struct entity_id_object); > + size = DAPP_IDENT_OFFSET + struct_size(dap, obj, 1); > write_lock(&vport->vmid_lock); > vmid->flag &= ~LPFC_VMID_REGISTERED; > write_unlock(&vport->vmid_lock); > -- > 2.34.1 >
On Tue, May 23, 2023 at 10:25:20PM -0700, Justin Tee wrote: > no_of_objects may be hardcoded to 1 right now, but does it make more > sense to use? > > struct_size(rap, obj, be32_to_cpu(rap->no_of_objects)); Oh yeah, that's nicer. :) > We probably should have declared no_of_objects as __be32 to have > avoided this confusion. Perhaps this patch can add that too?
> > We probably should have declared no_of_objects as __be32 to have > > avoided this confusion. > > Perhaps this patch can add that too? Yes, please. Something like this is fine: diff --git a/drivers/scsi/lpfc/lpfc_hw.h b/drivers/scsi/lpfc/lpfc_hw.h index 19b2d2754f32..e5a639d96122 100644 --- a/drivers/scsi/lpfc/lpfc_hw.h +++ b/drivers/scsi/lpfc/lpfc_hw.h @@ -1414,12 +1414,12 @@ struct app_id_object { }; struct lpfc_vmid_rapp_ident_list { - uint32_t no_of_objects; + __be32 no_of_objects; struct entity_id_object obj[1]; }; struct lpfc_vmid_dapp_ident_list { - uint32_t no_of_objects; + __be32 no_of_objects; struct entity_id_object obj[1]; };
Gustavo/Justin, >> > We probably should have declared no_of_objects as __be32 to have >> > avoided this confusion. >> >> Perhaps this patch can add that too? > > Yes, please. Something like this is fine: Please send a formal patch. Thanks!
Hi Martin, Sure, will do. I'll post the formal patch shortly. The __be32 no_of_objects comment can be ignored for this patch as I've already incorporated that into another patch with subject line: [PATCH 1/1] lpfc: Fix incorrect big endian type assignments in FDMI and VMID paths Thanks, Justin On Wed, May 31, 2023 at 8:27 AM Martin K. Petersen <martin.petersen@oracle.com> wrote: > > > Gustavo/Justin, > > >> > We probably should have declared no_of_objects as __be32 to have > >> > avoided this confusion. > >> > >> Perhaps this patch can add that too? > > > > Yes, please. Something like this is fine: > > Please send a formal patch. Thanks! > > -- > Martin K. Petersen Oracle Linux Engineering
diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c index e880d127d7f5..f52aeb73af8d 100644 --- a/drivers/scsi/lpfc/lpfc_ct.c +++ b/drivers/scsi/lpfc/lpfc_ct.c @@ -3747,9 +3747,7 @@ lpfc_vmid_cmd(struct lpfc_vport *vport, rap->no_of_objects = cpu_to_be32(1); rap->obj[0].entity_id_len = vmid->vmid_len; memcpy(rap->obj[0].entity_id, vmid->host_vmid, vmid->vmid_len); - size = RAPP_IDENT_OFFSET + - sizeof(struct lpfc_vmid_rapp_ident_list) + - sizeof(struct entity_id_object); + size = RAPP_IDENT_OFFSET + struct_size(rap, obj, 1); retry = 1; break; @@ -3767,9 +3765,7 @@ lpfc_vmid_cmd(struct lpfc_vport *vport, dap->no_of_objects = cpu_to_be32(1); dap->obj[0].entity_id_len = vmid->vmid_len; memcpy(dap->obj[0].entity_id, vmid->host_vmid, vmid->vmid_len); - size = DAPP_IDENT_OFFSET + - sizeof(struct lpfc_vmid_dapp_ident_list) + - sizeof(struct entity_id_object); + size = DAPP_IDENT_OFFSET + struct_size(dap, obj, 1); write_lock(&vport->vmid_lock); vmid->flag &= ~LPFC_VMID_REGISTERED; write_unlock(&vport->vmid_lock);