Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp91296ybl; Thu, 15 Aug 2019 13:16:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqwSwrD11Q4lQvMdKeE/cSko9tFuX+64DR+dgZTzv6I5/96TEb5FLVV0+R6jjABdhwMdrNvu X-Received: by 2002:a65:6458:: with SMTP id s24mr4791755pgv.158.1565900195184; Thu, 15 Aug 2019 13:16:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565900195; cv=none; d=google.com; s=arc-20160816; b=POekRRCfF8Esfm1YleyEdJG9IqCLb02tmQHnky82ax4WPLTtC42C6FC3lsPV/bOCt5 DU65AMplfdgcPzLDRkfy6Sldbn2pah+eUou7jtqgO8zsN6sdopP2hnJSx29AkHu7Tn9i UHb35fKDGIvuksNPNTQqFVCL/o9r7L+1r+dAdlVB98m9aZhLe7496NeASZhg5GYpm3Yh VWvrwBSH8zjL8fwQyGr63LQB7zty9FkTMEy3r8DKxZJN1aA2fh7dFdAn695Qto2+SlBS K1XsBJmGwBi4Kes5R697LHZr8FrGoWNb0I4YYS4jzGVm5XLqU85JaUVgxLWTqibOYZAM NbeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=N7Tm6+mfa3+K/bgm6QIdV+VeBL3KbxC3AiYGTqLoSm8=; b=vpquj7Zt45jxGMt41Wn4eoo55SZby52VGg+htJjKAOmqyfNhysrk1+qE/WRIa+M7pt yerhRwsXdhoxv46Ig58RF6ScQonTbrxYOm06i0ByVczUG2+QJAkk5aMZh9zG4+1x2xln SbX5SbaaweSoMuJLZcDoXnSBUqMyoTpJXi/biMOIUmsgCKDO4xDQpVyIiNWJ0XxP6c+L 78GyI4sVJWAyaCG4bJTeQMM9dPAZvRhhZ1CyAKubRF1tYu0+frGYPegtF3K0BQ8mCk0c H05+JUp+z1V0fM9uD1ObyPPyiMtog44JnXx5eEZY4RkofsyOld55rcbS5FQ37x7DcLFC 4/Jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x12si2409271pgq.220.2019.08.15.13.16.19; Thu, 15 Aug 2019 13:16:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732430AbfHOTch (ORCPT + 99 others); Thu, 15 Aug 2019 15:32:37 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:49012 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728762AbfHOTcg (ORCPT ); Thu, 15 Aug 2019 15:32:36 -0400 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::d71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 176741400EC64; Thu, 15 Aug 2019 12:32:36 -0700 (PDT) Date: Thu, 15 Aug 2019 12:32:35 -0700 (PDT) Message-Id: <20190815.123235.516041583959546572.davem@davemloft.net> To: terry.s.duncan@linux.intel.com Cc: sam@mendozajonas.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org, wak@google.com, joel@jms.id.au Subject: Re: [PATCH] net/ncsi: Ensure 32-bit boundary for data cksum From: David Miller In-Reply-To: <20190814011840.9387-1-terry.s.duncan@linux.intel.com> References: <20190814011840.9387-1-terry.s.duncan@linux.intel.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 15 Aug 2019 12:32:36 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Terry S. Duncan" Date: Tue, 13 Aug 2019 18:18:40 -0700 > The NCSI spec indicates that if the data does not end on a 32 bit > boundary, one to three padding bytes equal to 0x00 shall be present to > align the checksum field to a 32-bit boundary. > > Signed-off-by: Terry S. Duncan > --- > net/ncsi/internal.h | 1 + > net/ncsi/ncsi-cmd.c | 2 +- > net/ncsi/ncsi-rsp.c | 12 ++++++++---- > 3 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h > index 0b3f0673e1a2..468a19fdfd88 100644 > --- a/net/ncsi/internal.h > +++ b/net/ncsi/internal.h > @@ -185,6 +185,7 @@ struct ncsi_package; > #define NCSI_TO_CHANNEL(p, c) (((p) << NCSI_PACKAGE_SHIFT) | (c)) > #define NCSI_MAX_PACKAGE 8 > #define NCSI_MAX_CHANNEL 32 > +#define NCSI_ROUND32(x) (((x) + 3) & ~3) /* Round to 32 bit boundary */ I think we have enough of a proliferation of alignment macros, let's not add more. Either define this to "ALIGN(x, 4)" or expand that into each of the locations: > pchecksum = (__be32 *)((void *)h + sizeof(struct ncsi_pkt_hdr) + > - nca->payload); > + NCSI_ROUND32(nca->payload)); ALIGN(nca->payload, 4) > - pchecksum = (__be32 *)((void *)(h + 1) + payload - 4); > + pchecksum = (__be32 *)((void *)(h + 1) + NCSI_ROUND32(payload) - 4); ALIGN(payload, 4) etc.