From: Anders Roxell <anders.roxell@linaro.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Kees Cook" <keescook@chromium.org>,
"Horia Geantă" <horia.geanta@nxp.com>,
"Pankaj Gupta" <pankaj.gupta@nxp.com>,
"Gaurav Jain" <gaurav.jain@nxp.com>,
"David S. Miller" <davem@davemloft.net>,
linux-crypto@vger.kernel.org, "kernel test robot" <lkp@intel.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] crypto/caam: Avoid GCC constprop bug warning
Date: Thu, 1 Dec 2022 12:52:44 +0100 [thread overview]
Message-ID: <20221201115244.GC69385@mutt> (raw)
In-Reply-To: <Y2TVXDfQUwlYFv9S@gondor.apana.org.au>
On 2022-11-04 17:03, Herbert Xu wrote:
> On Fri, Oct 28, 2022 at 02:05:31PM -0700, Kees Cook wrote:
> >
> > @@ -163,7 +163,7 @@ 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 */
> > + if (data && len) /* avoid sparse warning: memcpy with byte count of 0 */
> > memcpy(offset, data, len);
>
> How about just killing the if clause altogether? I don't see
> any sparse warnings without it. What am I missing?
I think that was fixed in sparse release v0.5.1 [1]. The workaround 'if
(len)' was introduced back in 2011, and the sparse release v0.5.1 was
done in 2017. So it should probably be safe to remove the 'if (len)' or
what do you think?
Cheers,
Anders
[1] https://sparse.docs.kernel.org/en/latest/release-notes/v0.5.1.html
next prev parent reply other threads:[~2022-12-01 11:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 21:05 [PATCH] crypto/caam: Avoid GCC constprop bug warning Kees Cook
2022-10-29 11:40 ` David Laight
2022-11-04 9:03 ` Herbert Xu
2022-12-01 11:52 ` Anders Roxell [this message]
2022-12-01 12:10 ` Herbert Xu
2022-12-02 0:59 ` Anders Roxell
2022-12-02 0:58 ` Anders Roxell
2022-12-02 10:01 ` David Laight
2022-12-02 18:58 ` Kees Cook
2022-12-02 22:08 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221201115244.GC69385@mutt \
--to=anders.roxell@linaro.org \
--cc=davem@davemloft.net \
--cc=gaurav.jain@nxp.com \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=keescook@chromium.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=pankaj.gupta@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox