Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Naresh Kamboju <naresh.kamboju@linaro.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Cc: open list <linux-kernel@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	lkft-triage@lists.linaro.org,
	Linux Regressions <regressions@lists.linux.dev>,
	clang-built-linux <llvm@lists.linux.dev>,
	thara gopinath <thara.gopinath@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Anders Roxell <anders.roxell@linaro.org>,
	Dan Carpenter <dan.carpenter@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: next-20241216: drivers/crypto/qce/sha.c:365:3: error: cannot jump from this goto statement to its label
Date: Mon, 16 Dec 2024 11:02:31 -0700	[thread overview]
Message-ID: <20241216180231.GA1069997@ax162> (raw)
In-Reply-To: <CA+G9fYtpAwXa5mUQ5O7vDLK2xN4t-kJoxgUe1ZFRT=AGqmLSRA@mail.gmail.com>

Hi Naresh,

Thanks for the report.

+ Bartosz as author of ce8fd0500b74

On Mon, Dec 16, 2024 at 10:04:05PM +0530, Naresh Kamboju wrote:
> The arm and arm64 builds failed on Linux next-20241216 due to following
> build warnings / errors with clang-19 and clang-nightly toolchain.
> Whereas the gcc-13 builds pass.
> 
> arm, arm64:
>   * build/clang-19-defconfig
>   * build/clang-nightly-defconfig
> 
> First seen on Linux next-20241216.
>   Good: next-20241216
>   Bad:  next-20241213
> 
> Build log:
> -----------
<trimmed irrelevant warning>
> drivers/crypto/qce/sha.c:365:3: error: cannot jump from this goto
> statement to its label
>   365 |                 goto err_free_ahash;
>       |                 ^
> drivers/crypto/qce/sha.c:373:6: note: jump bypasses initialization of
> variable with __attribute__((cleanup))
>   373 |         u8 *buf __free(kfree) = kzalloc(keylen + QCE_MAX_ALIGN_SIZE,
>       |             ^
> 1 error generated.

It is a bug to jump over the initialization of a cleanup variable
because the cleanup function will be called on an uninitialized pointer
in those cases. GCC does not catch this at compile time like clang does
(it would be nice if we could document this somewhere and really
encourage people doing cleanup annotations to ensure their patches pass
a clang build except in architecture code where clang does not support
that target):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951

It may be worth just reverting commit ce8fd0500b74 ("crypto: qce - use
__free() for a buffer that's always freed") since it seems like little
value in this case but if we want to forward fix it, I think we could
just mirror what the rest of the kernel does and keep the declaration at
the top of the function and initialize the pointer to NULL. The diff
below resolves the issue for me, which I don't mind sending as a formal
patch.

Cheers,
Nathan

diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
index c4ddc3b265ee..e251f0f9a4fd 100644
--- a/drivers/crypto/qce/sha.c
+++ b/drivers/crypto/qce/sha.c
@@ -337,6 +337,7 @@ static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm, const u8 *key,
 	struct scatterlist sg;
 	unsigned int blocksize;
 	struct crypto_ahash *ahash_tfm;
+	u8 *buf __free(kfree) = NULL;
 	int ret;
 	const char *alg_name;
 
@@ -370,8 +371,7 @@ static int qce_ahash_hmac_setkey(struct crypto_ahash *tfm, const u8 *key,
 				   crypto_req_done, &wait);
 	crypto_ahash_clear_flags(ahash_tfm, ~0);
 
-	u8 *buf __free(kfree) = kzalloc(keylen + QCE_MAX_ALIGN_SIZE,
-					GFP_KERNEL);
+	buf = kzalloc(keylen + QCE_MAX_ALIGN_SIZE, GFP_KERNEL);
 	if (!buf) {
 		ret = -ENOMEM;
 		goto err_free_req;

  reply	other threads:[~2024-12-16 18:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 16:34 next-20241216: drivers/crypto/qce/sha.c:365:3: error: cannot jump from this goto statement to its label Naresh Kamboju
2024-12-16 18:02 ` Nathan Chancellor [this message]
2024-12-16 18:45   ` Bartosz Golaszewski

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=20241216180231.GA1069997@ax162 \
    --to=nathan@kernel.org \
    --cc=anders.roxell@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=dan.carpenter@linaro.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=llvm@lists.linux.dev \
    --cc=naresh.kamboju@linaro.org \
    --cc=neil.armstrong@linaro.org \
    --cc=regressions@lists.linux.dev \
    --cc=thara.gopinath@gmail.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