From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C1A63537F7 for ; Mon, 27 Apr 2026 15:48:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777304884; cv=none; b=KiQx+xNE903bGOl5oMEqXbBACuCp9ZZAJvchBCXVmJAoTe1ZSWD+6TMb28cNxW2toFEpuhyHt7MmK9v5iXLtyhhCvOLJVuf2IzqUGlmKpBXzUEmtT0xb2Tj8rHfX5Coi8V4/zwEohqw1Ec4l90E16sHsV8HBGyep2zoLz8w2Wgw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777304884; c=relaxed/simple; bh=X0yZ8fv//dJjQj72P4wIFoT4NGZLaIID0GSsUCfRQXk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c+gEFnXN5WfV1wEpcKmTIW/2BymcMQB+5CJ8XeMF4iUEzyDo6aKkpcQw54Qv4rPnCa9+sw7RITraLFqNfR5DEgtEFLSJ6Kgi9Dt1O7W4UDCuLZwJ1peAsgpousvx4HI277Q5BCYnM3URNBmWkxVrTmq3Mb5cLqz3wvPxuY6KLwc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=N5d3X5Dy; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="N5d3X5Dy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777304883; x=1808840883; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=X0yZ8fv//dJjQj72P4wIFoT4NGZLaIID0GSsUCfRQXk=; b=N5d3X5DyvntZ+3LQxQY5ZAZpmwMHAVSBQAjMpTBoB4EF6li5AOlbI0ta MWorrewQ62El8HjCvwoZdJM8tNXEQDh5zYA1wdR4SBKuuHBzFWBhVgblr K4yQa2J7MhwPqYuHgNg1I8KvdNUSpKHtxnQsBdEEnDya5++5jtvV2KBFg ECr5Ie6Rk7c4YxWLArygURQszkT84JPF2ZEW2AFui+83/EETQb+0pclHv slCHS/kwCke4fyl9aZwtM5RH4CwK4SnUcgp8d2e21nX3AwFXbp99u1Vfp SRncsjDaKKMYRx4wn7gcwPajCCQsM+y8hcbPKV6/auFbULsv+TG7ckIkS A==; X-CSE-ConnectionGUID: aufYbEanTNqr0AZGT7HLXA== X-CSE-MsgGUID: al5nmGuzRCS/0MNumCzm7A== X-IronPort-AV: E=McAfee;i="6800,10657,11769"; a="88797392" X-IronPort-AV: E=Sophos;i="6.23,202,1770624000"; d="scan'208";a="88797392" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2026 08:48:02 -0700 X-CSE-ConnectionGUID: DQJu360zTWS6XVnQGHAY+Q== X-CSE-MsgGUID: nehGvcVATL6KshOwM11xtg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,202,1770624000"; d="scan'208";a="256986764" Received: from fpallare-mobl4.ger.corp.intel.com (HELO localhost) ([10.245.244.2]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2026 08:48:00 -0700 Date: Mon, 27 Apr 2026 18:47:58 +0300 From: Andy Shevchenko To: Miquel Raynal Cc: David Laight , Lukas Wunner , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Richard Weinberger , Vignesh Raghavendra , Andrew Morton Subject: Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out do_write_buffer_locked() to reduce stack frame Message-ID: References: <20260408211407.2295175-1-andriy.shevchenko@linux.intel.com> <20260409082611.73fac9ab@pumpkin> <20260409122846.7d08d2b4@pumpkin> <87ik9cfm6g.fsf@bootlin.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ik9cfm6g.fsf@bootlin.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Mon, Apr 27, 2026 at 05:38:31PM +0200, Miquel Raynal wrote: > On 14/04/2026 at 15:38:38 +03, Andy Shevchenko wrote: > > On Thu, Apr 09, 2026 at 12:28:46PM +0100, David Laight wrote: > >> On Thu, 9 Apr 2026 09:58:28 +0200 > >> Lukas Wunner wrote: > >> > On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wrote: > >> > > On Wed, 8 Apr 2026 23:11:48 +0200 Andy Shevchenko wrote: > >> > > > Compiler is not happy about used stack frame: > >> > > > > >> > > > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer': > >> > > > drivers/mtd/chips/cfi_cmdset_0001.c:1887:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] > >> > > > > >> > > > Fix this by factoring out do_write_buffer_locked(). > >> > > > >> > > Does this just split the large stack frame between two nested functions? > >> > > I'd also expect the compiler to inline do_write_buffer_locked() so it > >> > > makes little difference. > >> > > OTOH I can't immediately see where the large stack frame comes from. > >> > > >> > The error occurs for an allmodconfig build on arm, which implies > >> > CONFIG_KASAN_STACK=y and thus increases stack usage vis-à-vis a > >> > "regular" build. > >> > > >> > Stack usage is high here because of the three "map_word" types, > >> > which can each be up to 256 unsigned longs (32 * 8), see the > >> > definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in > >> > include/linux/mtd/map.h. > >> > >> Ugg - that code is horrid. > >> Returning structures by value isn't really a good idea. > > Looks like the primary reason for the stack over usage, no? Isn't > playing with inline and refactoring just a tiny fix that prevents > problem by just a couple of bytes? > > I haven't looked too carefully, but could we (Andy?) have a fix that > reduces the number of map_word (as suggested, IIUC) and/or avoid passing > them by value? I am not an expert for this particular change, I am afraid. Consider my patch as a bug report that needs to be addressed, Currently it might break some builds when `make W=1` is passed. > I can also take this cleanup if enclosed in a bigger > series, I don't mind because it may make the code easier to read as > well, but I feel like this is not a proper fix. If it is, please explain > to me again :-) -- With Best Regards, Andy Shevchenko