All of lore.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 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.