From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (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 2F0AB339A8 for ; Tue, 14 Apr 2026 12:38:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776170325; cv=none; b=adCLb/jWcvQs1DGCWmgvkM7RtL6OhV4x2z3cb4R6woTtZQs2H7Ab3HAzw6FNRYMrpfYDY9dgNYwouU9c7C71XrKAedgSzw9N7H50OMjq7CTLcv2YGQr9TSWVl4cs1a261IjZrpsGqhXV93/LDTrpqrpi2Ntr65LpMVxD5wKa5N8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776170325; c=relaxed/simple; bh=9gD9t0+kbSxr6E+N0FKZKJlGgNjiqmd6/XrBToiXwVo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GDLfMsTGD9aDoSWePH2mPctA2qdDFPjP9/G9HMHx5t21du6HZiCQCATzOOaSGSbLV/m4U4Lg8olr2/1fRd09/vuXp1MboYQCGYqRGX7a7PD805ce8DaVRrSmPdQz/1lqgp5EK96Pyopxf8DV/1yHU7yeuXDRtmzS/mmpZ3necf0= 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=PVgSoSCU; arc=none smtp.client-ip=198.175.65.19 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="PVgSoSCU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776170325; x=1807706325; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=9gD9t0+kbSxr6E+N0FKZKJlGgNjiqmd6/XrBToiXwVo=; b=PVgSoSCU4GFnai5/fr2z77fMePpKrTAYVrVDY8JIqiYYa/leP62Ot8c+ ZZ1zayOZ+noWryaFXh9gOzxFioKaf6GESatqj6fgZjb7vC0OvJuvBkcVU p/tH8UvNoQS5/4174zHENxMd0oaPBeSFsfq9O9Ra6J1HlOAt7DZtc/qlB B35q4Pl1BA3wdI0MykVN0R7I/aQ/7uAOSubmrbJ3uZfKPPL/Ci3krVCqq xkHHT61AjHCd1rlw4y3fVFeVj3iiHz2W3q/jBo+6KNtajnXY2ZxW/p+tp 1u0IQnOnm8saGGcLs3w1DXh5049oJMtCx1Ah/xG+UO0mxmIqpkv4aAQ+n A==; X-CSE-ConnectionGUID: LVEHzwgmQzqBgerbNFREeQ== X-CSE-MsgGUID: FI9uuk2KRFqGrmAc5RdgXA== X-IronPort-AV: E=McAfee;i="6800,10657,11759"; a="77029664" X-IronPort-AV: E=Sophos;i="6.23,179,1770624000"; d="scan'208";a="77029664" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2026 05:38:44 -0700 X-CSE-ConnectionGUID: G700Qm/mTxqCxUFLOBuj+g== X-CSE-MsgGUID: 7OKeXwtGTeK90m0Jx2XsAA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,179,1770624000"; d="scan'208";a="229953827" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.245.106]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2026 05:38:41 -0700 Date: Tue, 14 Apr 2026 15:38:38 +0300 From: Andy Shevchenko To: David Laight Cc: Lukas Wunner , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Miquel Raynal , 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> 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: <20260409122846.7d08d2b4@pumpkin> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo 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. > > > > > Possible solutions: > > > > - Disable KASAN entirely for this file: > > https://lore.kernel.org/all/adX3SHYgazijahbG@wunner.de/ > > > > Not always a good option, particularly for stuff like lib/maple_tree.c > > where the same issue exists in mas_wr_spanning_store() and KASAN would > > certainly be good to have for that one. > > I've peeked at that at least once. > Some big functions get inlined; IIRC one small function is basically: > if (expr) a(args) else b(args); > and marking both a and b noinline would help a lot. > > > > > - Use heap instead of stack. > > > > - Split function in smaller chunks and mark them "noinline". > > That might make the code easier to read as well. > > But looking at it, I think that a small amount of refactoring > (mostly moving the initial 'status' check before the command > is written) would mean that only one 'map_word' would be valid > at any one time. > > I didn't look at what was really happening though. > I suspect it is similar to some code I've written for accessing serial > EEPROM where the control data is written one bit at a time, but the > data itself is read/written in 4 bit chunks (although the low-level hardware > did multiple 'nibble' accesses for wider transfers). > In any case it surely can't be necessary to have a 256+ byte structure > to hold the 8-bit command/status values. > (In my case the 8 bits got 'spread' across a 32bit word and written > (to the fgpa - helped because I was writing that end as well) as a single word.) Okay, I leave this to maintainers to decide what to do with my contribution. Dunno if this refactoring helps doing better one in the future (like David suggested) or should be rewritten completely. In my opinion, smaller functions are always easier to follow. -- With Best Regards, Andy Shevchenko