From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (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 EA18D3D3481 for ; Tue, 28 Apr 2026 08:20:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777364426; cv=none; b=fm22hZbi7slPd3/G8Xr+PFFTUAgm7Ct6JzF6ilU/npuflQWGBDI7KxbgEekQsp8PPvjZ3sIbp6hH0+i48gIqIu+MA116vvenBcvBZUT0sp7Hpob6btzCxvbrL9Ar8ryLAc9myCIqHxaks2ckkXfhikN0F7HBMkfKm5ocrJqnPck= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777364426; c=relaxed/simple; bh=9aXcY0AV1qtSnfN/bX+A0N9tMeZsDrVOfumXOkBSD/U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=f0+/pVCbXZLdv0Eg8s0xs3Hbo6FQ5dCdZ/h0ALGCuvJRhMHkQgszE+OLQdBMdvkKVUwQrU6vP1JmiXbfUnwZygv7BIIYMuch9SsLsB27q6BfvJJLig2DDE82AQAHfayiYjrn1UPFGvuLxKlYwe4Hi8sFwCwZJav1l6E9PVDRTSA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Ygwqy2Ad; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Ygwqy2Ad" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 8DE31C5CD52; Tue, 28 Apr 2026 08:21:03 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id EB2B4601D0; Tue, 28 Apr 2026 08:20:19 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 8C1F1107284EB; Tue, 28 Apr 2026 10:20:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1777364419; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=9aXcY0AV1qtSnfN/bX+A0N9tMeZsDrVOfumXOkBSD/U=; b=Ygwqy2Ad16PHxg6Azhkhz4AXBcHgjyHdY6MAccdU6RO9tB4gOirALtlRTrvC3peVLG+yaF 4TO82X+auIp/OdOTI4WiiuHIyz8mMLX/sxYZnV6xMxJjVsx3ujzntXYaS1E97hstNXUZqJ 3Y2Y8KN8LfDsC1E6aZXCqZRKDuzVn7C1Ddkl3jR6LzUS/qcnuaAItxc3wi5CFExaCVuhm/ +UBDgggQuj4Oe6KmRByLHRmRBaB0VVN9D5umw95A9bTw9IcQALa9UuTmm93yOwMZSgwmEA xBvzmvc0mVaXdGbaNXXO3pvcENSBEoPkI9fbFibm17iXOM+UZvUFraul76JuWQ== From: Miquel Raynal To: Andy Shevchenko 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 In-Reply-To: (Andy Shevchenko's message of "Mon, 27 Apr 2026 18:47:58 +0300") References: <20260408211407.2295175-1-andriy.shevchenko@linux.intel.com> <20260409082611.73fac9ab@pumpkin> <20260409122846.7d08d2b4@pumpkin> <87ik9cfm6g.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Tue, 28 Apr 2026 10:20:16 +0200 Message-ID: <87pl3jebsv.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=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 >> >> > 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. >> >>=20 >> >> Ugg - that code is horrid. >> >> Returning structures by value isn't really a good idea. >>=20 >> 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? >>=20 >> 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. Surprising flannel from someone sorely insisting to force contributors into doing zillions more changes than they initially wanted, easily triggering iniquitously NACKs otherwise. > Consider my patch > as a bug report that needs to be addressed, Currently it might break some > builds when `make W=3D1` is passed. Hopefully you will remember that you have your own limits too. Maybe that will allow others to breeze next time there will be something that matters so much to you that you prefer to fully block their work. >> 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 :-) Thanks, Miqu=C3=A8l