Message ID | Y6wCbyttJ+WVzmZX@gondor.apana.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1792648wrt; Wed, 28 Dec 2022 01:09:10 -0800 (PST) X-Google-Smtp-Source: AMrXdXujQtkzGi1bTbU/4a5vZhUdVKCLArScw2dHE2LD5OZYWzQ5jgkCuY0xKb7AZKMk2YemDAbc X-Received: by 2002:aa7:c6c2:0:b0:46b:aedf:f328 with SMTP id b2-20020aa7c6c2000000b0046baedff328mr19612457eds.20.1672218550718; Wed, 28 Dec 2022 01:09:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672218550; cv=none; d=google.com; s=arc-20160816; b=RYXLirv5qcRoISVcqgWeDDHO2MSqwogYROXp1u8X75Iv+vVhMDnLgFROs+9KC7jW+r oWwLhDxOcGKeSqBBYcwXQ6S53MprUOHSmIYiyC1jEwd4JiU7oUnBNerG7zejvUvPKWCJ 2N8sjDmMG1XFEDHgMJ1HP2+b1wGD3QnaaHyZgyyFYBxw6jyEXIWg7qEchQLvUEu4zunS XM48/WdoUyTnU4Ub9Wxvv7Wy9ojUD4sAHm4AJlJWc73kDfOL+s/16X4KF4oh0W8mf1Pm fVUJKI3PqI6os1Cx9d/MLFzovnWSO8Mnyyyks+F4Rd0HAk9pOjyRJxzz2KJ4d5XIuHVe mJPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=gECJ/qprc05E5DktSoUZ3O9JTpyLOuz1Pgrzp/+VcOg=; b=T8QQvu+nYRdP+7UQU90SJpME4pf70RepnO+lIWSptuvkHUwtlAUPAD1HZ7ngFgeTmh KTNRGXn+RIgmQv1JwPlpE/VIeDloVB79tRhyMejUyggJHCK4FcUu9q8k/nFLl2dyTGzR orZjNHl2mAI1xeC15P/cb3W6KrNwtMq1XRhqop7LPwoCluzscXbWsWF05SwXr3P/9oP7 cFQZTidkgSGgBcpg8ShZxMpVUGiRRh4jrz3WROFROxvdA00VPHjWUI2QSr8NyGh1fV4r 4gIX9B7fHwtBFQclaWhD4X+4jd5gpsfx/InJzxzI2XzCywvryU4O7buqvI+y1xNe5n/X Jikg== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y6-20020a056402270600b0047035379d79si13544395edd.556.2022.12.28.01.08.46; Wed, 28 Dec 2022 01:09:10 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232770AbiL1It0 (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Wed, 28 Dec 2022 03:49:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232808AbiL1Is4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 28 Dec 2022 03:48:56 -0500 Received: from formenos.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B467CE72; Wed, 28 Dec 2022 00:46:53 -0800 (PST) Received: from loth.rohan.me.apana.org.au ([192.168.167.2]) by formenos.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1pAS59-00BTqH-2k; Wed, 28 Dec 2022 16:46:40 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Wed, 28 Dec 2022 16:46:39 +0800 Date: Wed, 28 Dec 2022 16:46:39 +0800 From: Herbert Xu <herbert@gondor.apana.org.au> To: Uwe =?iso-8859-1?q?Kleine-K=F6nig?= <u.kleine-koenig@pengutronix.de> Cc: Horia =?utf-8?q?Geant=C4=83?= <horia.geanta@nxp.com>, Gaurav Jain <gaurav.jain@nxp.com>, Pankaj Gupta <pankaj.gupta@nxp.com>, linux-crypto@vger.kernel.org, kernel@pengutronix.de, "David S. Miller" <davem@davemloft.net>, Kees Cook <keescook@chromium.org>, kernel test robot <lkp@intel.com>, Anders Roxell <anders.roxell@linaro.org>, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH] crypto: caam - Avoid GCC memset bug warning Message-ID: <Y6wCbyttJ+WVzmZX@gondor.apana.org.au> References: <20221222162513.4021928-1-u.kleine-koenig@pengutronix.de> <Y6VK4IJkHiawAbJz@gondor.apana.org.au> <20221223174719.4n6pmwio4zycj2qm@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221223174719.4n6pmwio4zycj2qm@pengutronix.de> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS 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?1753448238643298596?= X-GMAIL-MSGID: =?utf-8?q?1753448238643298596?= |
Series |
crypto: caam - Avoid GCC memset bug warning
|
|
Commit Message
Herbert Xu
Dec. 28, 2022, 8:46 a.m. UTC
Certain versions of gcc don't like the memcpy with a NULL dst
(which only happens with a zero length). This only happens
when debugging is enabled so add an if clause to work around
these warnings.
A similar warning used to be generated by sparse but that was
fixed years ago.
Link: https://lore.kernel.org/lkml/202210290446.qBayTfzl-lkp@intel.com
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Kees Cook <keescook@chromium.org>
Reported-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Comments
On Wed, Dec 28, 2022 at 04:46:39PM +0800, Herbert Xu wrote: > Certain versions of gcc don't like the memcpy with a NULL dst > (which only happens with a zero length). This only happens > when debugging is enabled so add an if clause to work around > these warnings. > > A similar warning used to be generated by sparse but that was > fixed years ago. > > Link: https://lore.kernel.org/lkml/202210290446.qBayTfzl-lkp@intel.com > Reported-by: kernel test robot <lkp@intel.com> > Reported-by: Kees Cook <keescook@chromium.org> > Reported-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de> Huh, broken encoding in the mail. I'd appreciate someone to doublecheck it's fine in the final commit. Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Best regards Uwe
On Wed, Dec 28, 2022 at 04:46:39PM +0800, Herbert Xu wrote: > Certain versions of gcc don't like the memcpy with a NULL dst > (which only happens with a zero length). This only happens > when debugging is enabled so add an if clause to work around > these warnings. > > A similar warning used to be generated by sparse but that was > fixed years ago. > > Link: https://lore.kernel.org/lkml/202210290446.qBayTfzl-lkp@intel.com > Reported-by: kernel test robot <lkp@intel.com> > Reported-by: Kees Cook <keescook@chromium.org> > Reported-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > diff --git a/drivers/crypto/caam/desc_constr.h b/drivers/crypto/caam/desc_constr.h > index 62ce6421bb3f..824c94d44f94 100644 > --- a/drivers/crypto/caam/desc_constr.h > +++ b/drivers/crypto/caam/desc_constr.h > @@ -163,7 +163,8 @@ static inline void append_data(u32 * const desc, const void *data, int len) > { > u32 *offset = desc_end(desc); > > - if (len) /* avoid sparse warning: memcpy with byte count of 0 */ > + /* Avoid gcc warning: memcpy with data == NULL */ > + if (!IS_ENABLED(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG) || data) I just tried: For me a plain if (data) is also enough to make both gcc and sparse happy. (On a related note, sparse reports: CHECK drivers/crypto/caam/jr.c drivers/crypto/caam/jr.c: note: in included file (through arch/arm64/include/asm/io.h, include/linux/io.h, include/linux/irq.h, ...): include/asm-generic/io.h:290:22: warning: incorrect type in argument 1 (different base types) include/asm-generic/io.h:290:22: expected unsigned long long [usertype] val include/asm-generic/io.h:290:22: got restricted __le64 [usertype] include/asm-generic/io.h:290:22: warning: incorrect type in argument 1 (different base types) include/asm-generic/io.h:290:22: expected unsigned long long [usertype] val include/asm-generic/io.h:290:22: got restricted __le64 [usertype] Didn't look into that though.) Best regards Uwe
On Wed, Dec 28, 2022 at 12:30:35PM +0100, Uwe Kleine-König wrote: > > > - if (len) /* avoid sparse warning: memcpy with byte count of 0 */ > > + /* Avoid gcc warning: memcpy with data == NULL */ > > + if (!IS_ENABLED(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG) || data) > > I just tried: For me a plain > > if (data) > > is also enough to make both gcc and sparse happy. Of course it is. The point of the extra condition is to remove the unnecessary check on data unless we are in debugging mode (as it is only needed in debugging mode to work around the buggy compiler). > (On a related note, sparse reports: > > CHECK drivers/crypto/caam/jr.c > drivers/crypto/caam/jr.c: note: in included file (through arch/arm64/include/asm/io.h, include/linux/io.h, include/linux/irq.h, ...): > include/asm-generic/io.h:290:22: warning: incorrect type in argument 1 (different base types) > include/asm-generic/io.h:290:22: expected unsigned long long [usertype] val > include/asm-generic/io.h:290:22: got restricted __le64 [usertype] > include/asm-generic/io.h:290:22: warning: incorrect type in argument 1 (different base types) > include/asm-generic/io.h:290:22: expected unsigned long long [usertype] val > include/asm-generic/io.h:290:22: got restricted __le64 [usertype] That's a bug in include/asm-generic/io.h. It feeds an __le64 to __raw_writeq which wants a u64. Cheers,
From: Herbert Xu > Sent: 29 December 2022 01:49 > > On Wed, Dec 28, 2022 at 12:30:35PM +0100, Uwe Kleine-König wrote: > > > > > - if (len) /* avoid sparse warning: memcpy with byte count of 0 */ > > > + /* Avoid gcc warning: memcpy with data == NULL */ > > > + if (!IS_ENABLED(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG) || data) > > > > I just tried: For me a plain > > > > if (data) > > > > is also enough to make both gcc and sparse happy. > > Of course it is. The point of the extra condition is to remove > the unnecessary check on data unless we are in debugging mode > (as it is only needed in debugging mode to work around the buggy > compiler). IIRC the 'problematic' case is one where 'len' and 'data' are actually compile-time zeros - in which case you don't want to call memcpy() at all. In all other cases I think there is something to copy so you don't really want the check (or the one in memcpy() will do). Whether (builtin_constant_p(data) && !data) is good enough is another matter. It might need the (sizeof *(1 ? (void *)(data) : (int *)0) == 1) test. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
diff --git a/drivers/crypto/caam/desc_constr.h b/drivers/crypto/caam/desc_constr.h index 62ce6421bb3f..824c94d44f94 100644 --- a/drivers/crypto/caam/desc_constr.h +++ b/drivers/crypto/caam/desc_constr.h @@ -163,7 +163,8 @@ static inline void append_data(u32 * const desc, const void *data, int len) { u32 *offset = desc_end(desc); - if (len) /* avoid sparse warning: memcpy with byte count of 0 */ + /* Avoid gcc warning: memcpy with data == NULL */ + if (!IS_ENABLED(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG) || data) memcpy(offset, data, len); (*desc) = cpu_to_caam32(caam32_to_cpu(*desc) +