From: David Laight <david.laight.linux@gmail.com>
To: kernel test robot <lkp@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: crypto/hmac.c:251:12: warning: stack frame size (1152) exceeds limit (1024) in 'hmac_setkey_ahash'
Date: Thu, 16 Apr 2026 11:24:06 +0100 [thread overview]
Message-ID: <20260416112406.68b7afcd@pumpkin> (raw)
In-Reply-To: <202604161035.PMTaI4Cg-lkp@intel.com>
On Thu, 16 Apr 2026 11:04:43 +0800
kernel test robot <lkp@intel.com> wrote:
> Hi Herbert,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 9e1e9d660255d7216067193d774f338d08d8528d
> commit: c3103416d5217655d707d9417aaf66f184e3d72f crypto: hmac - Add ahash support
> date: 11 months ago
> config: mips-eyeq6_defconfig (https://download.01.org/0day-ci/archive/20260416/202604161035.PMTaI4Cg-lkp@intel.com/config)
> compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260416/202604161035.PMTaI4Cg-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Fixes: c3103416d521 ("crypto: hmac - Add ahash support")
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202604161035.PMTaI4Cg-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> >> crypto/hmac.c:251:12: warning: stack frame size (1152) exceeds limit (1024) in 'hmac_setkey_ahash' [-Wframe-larger-than]
> 251 | static int hmac_setkey_ahash(struct crypto_ahash *parent,
> | ^
> 1 warning generated.
For a typical x86-64 build with gcc the frame is 700 bytes.
Most will be for req - so it should be pretty architecture/compiler neutral.
Really need the associated object file to see what is going on.
The config file doesn't seem to contain anything unusual.
There are some unrelated oddities though.
>
>
> vim +/hmac_setkey_ahash +251 crypto/hmac.c
>
> 250
> > 251 static int hmac_setkey_ahash(struct crypto_ahash *parent,
> 252 const u8 *inkey, unsigned int keylen)
> 253 {
> 254 struct ahash_hmac_ctx *tctx = crypto_ahash_ctx(parent);
> 255 struct crypto_ahash *fb = crypto_ahash_fb(tctx->hash);
> 256 int ds = crypto_ahash_digestsize(parent);
> 257 int bs = crypto_ahash_blocksize(parent);
> 258 int ss = crypto_ahash_statesize(parent);
> 259 HASH_REQUEST_ON_STACK(req, fb);
> 260 u8 *opad = &tctx->pads[ss];
Is ss actually guaranteed to be not smaller than bs ?
> 261 u8 *ipad = &tctx->pads[0];
> 262 int err, i;
> 263
> 264 if (fips_enabled && (keylen < 112 / 8))
> 265 return -EINVAL;
> 266
> 267 ahash_request_set_callback(req, 0, NULL, NULL);
> 268
> 269 if (keylen > bs) {
> 270 ahash_request_set_virt(req, inkey, ipad, keylen);
> 271 err = crypto_ahash_digest(req);
> 272 if (err)
> 273 goto out_zero_req;
> 274
> 275 keylen = ds;
Is ds guaranteed to be not larger than bs?
> 276 } else
> 277 memcpy(ipad, inkey, keylen);
> 278
> 279 memset(ipad + keylen, 0, bs - keylen);
> 280 memcpy(opad, ipad, bs);
> 281
> 282 for (i = 0; i < bs; i++) {
> 283 ipad[i] ^= HMAC_IPAD_VALUE;
> 284 opad[i] ^= HMAC_OPAD_VALUE;
> 285 }
> 286
> 287 ahash_request_set_virt(req, ipad, NULL, bs);
> 288 err = crypto_ahash_init(req) ?:
> 289 crypto_ahash_update(req) ?:
> 290 crypto_ahash_export(req, ipad);
> 291
> 292 ahash_request_set_virt(req, opad, NULL, bs);
> 293 err = err ?:
> 294 crypto_ahash_init(req) ?:
> 295 crypto_ahash_update(req) ?:
> 296 crypto_ahash_export(req, opad);
> 297
> 298 out_zero_req:
> 299 HASH_REQUEST_ZERO(req);
> 300 return err;
> 301 }
> 302
>
next prev parent reply other threads:[~2026-04-16 10:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 3:04 crypto/hmac.c:251:12: warning: stack frame size (1152) exceeds limit (1024) in 'hmac_setkey_ahash' kernel test robot
2026-04-16 10:24 ` David Laight [this message]
2026-04-17 3:59 ` Herbert Xu
2026-04-18 9:32 ` David Laight
-- strict thread matches above, loose matches on Subject: below --
2026-01-12 22:49 kernel test robot
2025-12-03 0:12 kernel test robot
2025-10-28 15:04 kernel test robot
2025-09-14 21:06 kernel test robot
2025-07-23 21:28 kernel test robot
2025-06-19 12:13 kernel test robot
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=20260416112406.68b7afcd@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
/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