From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8055C1A3154 for ; Sat, 18 Apr 2026 09:32:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776504744; cv=none; b=nOHk3ttvx6qmsMxur3/ZYO/sLOGJLhb0E4xmoXU2hi2v8sOGoWmJJ1QX44NVbwVMnFac3b9wywccgnc3s/u5x1Z/Ky4IVTSkM01FP+1c74k0sbNir7MHY2NJULLPwm+SWtCMqcx37njEZOKhtuv2/+FgPCp0+FNhzhUf4B/+zcw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776504744; c=relaxed/simple; bh=LuNgNR4zWEnIVng3Iao/eYGyIMmZ7NSZVhPM11xUPG0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qMzsUFSNDMxm1RVTEB0Ky/nWFNUIAK1T6uJx4hA5wFziH2QZm8sn1UojD2vvUogynpB3DUWgH2JXMMawLMXmo2rAfCbx8qqoOcgjym/v7Sy4YoYEXbU9imWyAxmZzp9az1PhyJ1mvjHZIX0hSF1Ehm8hLJ7kmeoUM2uyNUCivQ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PR3QDKoA; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PR3QDKoA" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488d2079582so15972575e9.2 for ; Sat, 18 Apr 2026 02:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776504742; x=1777109542; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=HxD+is+pbahMT9dB8HsDTaseFAqKL6o1uQcZ5xCt9OM=; b=PR3QDKoAQHIqsylGPQhxRqff3L39Q043sOAxZJcd0nxS2mtJdFSUbDR1CCz0SEllQm 8nHU4lxlH/rILF2dVgfY1ssi6ecRdvW9rBgzSzQ6yOcUx7bjG6utcfuOqg4ft6cfLuw/ cav3ii5FwAf/YS/QPe0tRZBG+JfJ1Al9nw3EMHYAkg2jpKppI2kKfrvtGyQxnttvj73R Ct6m8ZQmn/NJObmVKnxKGHgiiw9/IhemlXLnrZKFnLozhFn/w9Y1P27LlCAx8oNKtcXl 7CxPWtEXofqE3ONYCWTU5QzpHBMrOsDgnzR2cN8BrtvurBreX0OQU1iaCAVOK9AqOazw OIjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776504742; x=1777109542; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=HxD+is+pbahMT9dB8HsDTaseFAqKL6o1uQcZ5xCt9OM=; b=EtQQndZ8OCTFfIeS0D9lmgRegyfrc1LCulG/UzgHzmmVBIJ48WxRgIyD/sJ6aaSx3W Jc8oSme1dxj1FoDGYnMT9Cl/dARZSMlqjI9+FJaSIqbIksnAdI6cPHuTFMJS4Z0HlrYU uHNEjvj7QnRSQPlvmHVNPH6kejaelvmQ57ugGKEMrHGzSAffF0tbUGW9mg4Ss3gbIm+G nzF41UAcfLweFm/UuX5LoBWgok7MNKUV9BmuqwESYtVPu4l/M/biSp5zzVGqNMU9Zs7U 1Bkntj9Qf5ENbZSqNyW2mxJbER2dezqodvY8QBKYzl3xBSbZ+semIVjQnTT1E+MmV2ss gjmA== X-Forwarded-Encrypted: i=1; AFNElJ+zEy0drmICQa2w6Fj61ZbQj8elhMD5CA128vnSJVwW8SGVF2KHKm5ItvU8IecEXyDy64XIhX46DZDDq6A=@vger.kernel.org X-Gm-Message-State: AOJu0YybGNhYi6X7SDP27UClTvI9MF6GMNJgA376Pv9rN1SgqXal3ew+ ce1OK007kknm5XQT91Af3Dc+Q0u8S+8/yR7Zg52nlxiLYz2x3A/S9J7Y X-Gm-Gg: AeBDieubDsNdSXnFwBxVNov3ovME4mjwKL+8Yqi6qtYMG7o60mNhhELOzZ4qrmJDLKP ta7aEIOy+93bL+jCC68+Jw+BxFe+6LnPWyZ08gdJABLz/+86adxOw5KTRXW7WkORQRaoOuJnHfG 3pdrwLh6NSV9FhtLX56ZkHDjyc9IpNNPFos7k4Tp+nwkRxSSpLwDsVF2398JiRDo9XR0U9HWa8E CpWRrn6K3WXXLkGlBJ8C6qUaqc3QsXJrAGxmNcH/mCbMfIkKUXXSIcqT9gtjhfE4ZELrbcdGn33 7i9+FqFP1Qx4zZvVLXGfTni/jNJdmXJXkiM4QrdDV8/ecguJqxZcQX8k4khVJOjoqhE9P4tbuL9 MJxiOAr8D1cwk1KLw4jRIBnPWVZdjzPbu/9fqme2a+LV3rltwFx4OOIQ0IKbdJk0fCyygGhi2CO KzDCuxRmJ41Jq0WRl8OaYMhoANmNwWWwDN+LpEHAjLYhQDdVPc6N2s1ryoEguMzs1Mkuh0tWydY 8U= X-Received: by 2002:a05:600c:a30b:b0:487:4eb:d125 with SMTP id 5b1f17b1804b1-488fb74dff1mr59895795e9.9.1776504741623; Sat, 18 Apr 2026 02:32:21 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fc13938fsm166946075e9.10.2026.04.18.02.32.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Apr 2026 02:32:21 -0700 (PDT) Date: Sat, 18 Apr 2026 10:32:19 +0100 From: David Laight To: Herbert Xu Cc: kernel test robot , 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' Message-ID: <20260418103219.1024d2ce@pumpkin> In-Reply-To: References: <202604161035.PMTaI4Cg-lkp@intel.com> <20260416112406.68b7afcd@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 17 Apr 2026 11:59:12 +0800 Herbert Xu wrote: > On Thu, Apr 16, 2026 at 11:24:06AM +0100, David Laight wrote: > > > > > 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 ? > > Yes, it's checked in hmac_create_ahash: > > ds = halg->digestsize; > ss = halg->statesize; > if (ds > alg->cra_blocksize || ss < alg->cra_blocksize) > goto err_free_inst; > > Thanks, Ok, so the comment on the definition of 'struct crypto_ahash' could reasonably be changed to say that pads[] is large enough for two copies of any the digest, block or state. And then line 260 (above) changed to use 'bs'. The memcpy(opad, ipad, bs) could also be replaced by putting opad[i] = ipad[i] ^ HMAC_OPAD_VALUE; into the loop. None of this helps find why this build explodes the stack. I've had another look and can't see any inline functions calls that might cause grief. David