From: Arnd Bergmann <arnd@arndb.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Mark Brown <broonie@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Liam Girdwood <lgirdwood@gmail.com>,
Linux Crypto List <linux-crypto@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the sound-asoc tree with the crypto tree
Date: Tue, 12 May 2020 22:31:27 +0200 [thread overview]
Message-ID: <CAK8P3a2C-91vCNv8NV6ut8GDu2z9Yt6VwX+P2WggWnuCcMjcvg@mail.gmail.com> (raw)
In-Reply-To: <20200512200805.GA175421@gmail.com>
On Tue, May 12, 2020 at 10:08 PM Eric Biggers <ebiggers@kernel.org> wrote:
> On Tue, May 12, 2020 at 06:08:01PM +0100, Mark Brown wrote:
>
> For later: if SHASH_DESC_ON_STACK is causing problems, we really ought to find a
> better solution, since lots of users are using this macro. A version of
> crypto_shash_tfm_digest() that falls back to heap allocation if the descsize is
> too large would be possible, but that wouldn't fully solve the problem since
> some users do incremental hashing.
It's hard to know how many of the users of SHASH_DESC_ON_STACK() are
likely to cause problems, as multiple factors are involved:
- this one triggered the warning because it was on the stack of a function
that got inlined into another that has other large variables. Whether it
got inlined makes little difference to the stack usage, but does make a
difference to warning about it.
- generally the structure is larger than we like it, especially on architectures
with 128 byte CRYPTO_MINALIGN like ARM. This actually got worse
because of b68a7ec1e9a3 ("crypto: hash - Remove VLA usage"), as
the stack usage is now always the maximum of all hashes where it used
to be specific to the hash that was actually used and could be smaller
- the specific instance in calculate_sha256() feels a bit silly, as this
function allocates a tfm and a descriptor, runs the digest and then
frees both again. I don't know how common this pattern is, but
it seems a higher-level abstraction might be helpful anyway.
Arnd
next prev parent reply other threads:[~2020-05-12 20:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 4:49 linux-next: manual merge of the sound-asoc tree with the crypto tree Stephen Rothwell
2020-05-12 16:22 ` Mark Brown
2020-05-12 16:36 ` Eric Biggers
2020-05-12 17:08 ` Mark Brown
2020-05-12 20:08 ` Eric Biggers
2020-05-12 20:31 ` Arnd Bergmann [this message]
2020-05-14 13:21 ` Ard Biesheuvel
2020-05-13 2:52 ` Herbert Xu
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=CAK8P3a2C-91vCNv8NV6ut8GDu2z9Yt6VwX+P2WggWnuCcMjcvg@mail.gmail.com \
--to=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=lgirdwood@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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;
as well as URLs for NNTP newsgroup(s).