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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.