public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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	
> 


  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