[{"id":3675109,"web_url":"http://patchwork.ozlabs.org/comment/3675109/","msgid":"<20260409082611.73fac9ab@pumpkin>","list_archive_url":null,"date":"2026-04-09T07:26:11","subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","submitter":{"id":89989,"url":"http://patchwork.ozlabs.org/api/people/89989/","name":"David Laight","email":"david.laight.linux@gmail.com"},"content":"On Wed, 8 Apr 2026 23:11:48 +0200\nAndy Shevchenko wrote:\n\n> Compiler is not happy about used stack frame:\n> \n> drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':\n> 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=]\n> \n> Fix this by factoring out do_write_buffer_locked().\n\nDoes this just split the large stack frame between two nested functions?\nI'd also expect the compiler to inline do_write_buffer_locked() so it\nmakes little difference.\nOTOH I can't immediately see where the large stack frame comes from.\n\n\tDavid\n\n> \n> Signed-off-by: Andy Shevchenko \n> ---\n> v3: addressed set but unused variables when MTD_XIP=y (LKP)\n> v2: kept DIS/ENABLE_VPP paired\n> \n> drivers/mtd/chips/cfi_cmdset_0001.c | 88 +++++++++++++++++------------\n> 1 file changed, 51 insertions(+), 37 deletions(-)\n> \n> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c\n> index 5a4d2e16a9d1..7733e076ad40 100644\n> --- a/drivers/mtd/chips/cfi_cmdset_0001.c\n> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c\n> @@ -1154,7 +1154,8 @@ static void __xipram xip_enable(struct map_info *map, struct flchip *chip,\n> \n> static int __xipram xip_wait_for_operation(\n> \t\tstruct map_info *map, struct flchip *chip,\n> -\t\tunsigned long adr, unsigned int chip_op_time_max)\n> +\t\tunsigned long adr, unsigned long inval_adr, int inval_len,\n> +\t\tunsigned int chip_op_time, unsigned int chip_op_time_max)\n> {\n> \tstruct cfi_private *cfi = map->fldrv_priv;\n> \tstruct cfi_pri_intelext *cfip = cfi->cmdset_priv;\n> @@ -1276,8 +1277,7 @@ static int __xipram xip_wait_for_operation(\n> #define XIP_INVAL_CACHED_RANGE(map, from, size) \\\n> \tINVALIDATE_CACHED_RANGE(map, from, size)\n> \n> -#define INVAL_CACHE_AND_WAIT(map, chip, cmd_adr, inval_adr, inval_len, usec, usec_max) \\\n> -\txip_wait_for_operation(map, chip, cmd_adr, usec_max)\n> +#define INVAL_CACHE_AND_WAIT xip_wait_for_operation\n\nIsn't that separate and unrelated?\nThe compiler might optimise away the parameters you are adding back.\n\n\tDavid\n\n> \n> #else\n> \n> @@ -1720,42 +1720,24 @@ static int cfi_intelext_write_words (struct mtd_info *mtd, loff_t to , size_t le\n> }\n> \n> \n> -static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,\n> -\t\t\t\t unsigned long adr, const struct kvec **pvec,\n> -\t\t\t\t unsigned long *pvec_seek, int len)\n> +static int __xipram do_write_buffer_locked(struct map_info *map, struct flchip *chip,\n> +\t\t\t\t\t unsigned long cmd_adr, unsigned long adr,\n> +\t\t\t\t\t const struct kvec **pvec,\n> +\t\t\t\t\t unsigned long *pvec_seek, int len)\n> {\n> \tstruct cfi_private *cfi = map->fldrv_priv;\n> \tmap_word status, write_cmd, datum;\n> -\tunsigned long cmd_adr;\n> -\tint ret, wbufsize, word_gap, words;\n> +\tint ret, word_gap, words;\n> \tconst struct kvec *vec;\n> \tunsigned long vec_seek;\n> \tunsigned long initial_adr;\n> \tint initial_len = len;\n> \n> -\twbufsize = cfi_interleave(cfi) << cfi->cfiq->MaxBufWriteSize;\n> -\tadr += chip->start;\n> \tinitial_adr = adr;\n> -\tcmd_adr = adr & ~(wbufsize-1);\n> -\n> -\t/* Sharp LH28F640BF chips need the first address for the\n> -\t * Page Buffer Program command. See Table 5 of\n> -\t * LH28F320BF, LH28F640BF, LH28F128BF Series (Appendix FUM00701) */\n> -\tif (is_LH28F640BF(cfi))\n> -\t\tcmd_adr = adr;\n> \n> \t/* Let's determine this according to the interleave only once */\n> \twrite_cmd = (cfi->cfiq->P_ID != P_ID_INTEL_PERFORMANCE) ? CMD(0xe8) : CMD(0xe9);\n> \n> -\tmutex_lock(&chip->mutex);\n> -\tret = get_chip(map, chip, cmd_adr, FL_WRITING);\n> -\tif (ret) {\n> -\t\tmutex_unlock(&chip->mutex);\n> -\t\treturn ret;\n> -\t}\n> -\n> -\tXIP_INVAL_CACHED_RANGE(map, initial_adr, initial_len);\n> -\tENABLE_VPP(map);\n> \txip_disable(map, chip, cmd_adr);\n> \n> \t/* §4.8 of the 28FxxxJ3A datasheet says \"Any time SR.4 and/or SR.5 is set\n> @@ -1789,7 +1771,7 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,\n> \t\txip_enable(map, chip, cmd_adr);\n> \t\tprintk(KERN_ERR \"%s: Chip not ready for buffer write. Xstatus = %lx, status = %lx\\n\",\n> \t\t\t\tmap->name, Xstatus.x[0], status.x[0]);\n> -\t\tgoto out;\n> +\t\treturn ret;\n> \t}\n> \n> \t/* Figure out the number of words to write */\n> @@ -1853,7 +1835,7 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,\n> \t\tchip->state = FL_STATUS;\n> \t\txip_enable(map, chip, cmd_adr);\n> \t\tprintk(KERN_ERR \"%s: buffer write error (status timeout)\\n\", map->name);\n> -\t\tgoto out;\n> +\t\treturn ret;\n> \t}\n> \n> \t/* check for errors */\n> @@ -1866,21 +1848,53 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,\n> \t\tmap_write(map, CMD(0x70), cmd_adr);\n> \t\txip_enable(map, chip, cmd_adr);\n> \n> -\t\tif (chipstatus & 0x02) {\n> -\t\t\tret = -EROFS;\n> -\t\t} else if (chipstatus & 0x08) {\n> +\t\tif (chipstatus & 0x02)\n> +\t\t\treturn -EROFS;\n> +\n> +\t\tif (chipstatus & 0x08) {\n> \t\t\tprintk(KERN_ERR \"%s: buffer write error (bad VPP)\\n\", map->name);\n> -\t\t\tret = -EIO;\n> -\t\t} else {\n> -\t\t\tprintk(KERN_ERR \"%s: buffer write error (status 0x%lx)\\n\", map->name, chipstatus);\n> -\t\t\tret = -EINVAL;\n> +\t\t\treturn -EIO;\n> \t\t}\n> \n> -\t\tgoto out;\n> +\t\tprintk(KERN_ERR \"%s: buffer write error (status 0x%lx)\\n\", map->name, chipstatus);\n> +\t\treturn -EINVAL;\n> \t}\n> \n> \txip_enable(map, chip, cmd_adr);\n> - out:\tDISABLE_VPP(map);\n> +\treturn 0;\n> +}\n> +\n> +static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,\n> +\t\t\t\t unsigned long adr, const struct kvec **pvec,\n> +\t\t\t\t unsigned long *pvec_seek, int len)\n> +{\n> +\tstruct cfi_private *cfi = map->fldrv_priv;\n> +\tunsigned long cmd_adr;\n> +\tint ret, wbufsize;\n> +\n> +\twbufsize = cfi_interleave(cfi) << cfi->cfiq->MaxBufWriteSize;\n> +\tadr += chip->start;\n> +\tcmd_adr = adr & ~(wbufsize - 1);\n> +\n> +\t/* Sharp LH28F640BF chips need the first address for the\n> +\t * Page Buffer Program command. See Table 5 of\n> +\t * LH28F320BF, LH28F640BF, LH28F128BF Series (Appendix FUM00701) */\n> +\tif (is_LH28F640BF(cfi))\n> +\t\tcmd_adr = adr;\n> +\n> +\tmutex_lock(&chip->mutex);\n> +\tret = get_chip(map, chip, cmd_adr, FL_WRITING);\n> +\tif (ret) {\n> +\t\tmutex_unlock(&chip->mutex);\n> +\t\treturn ret;\n> +\t}\n> +\n> +\tXIP_INVAL_CACHED_RANGE(map, adr, len);\n> +\tENABLE_VPP(map);\n> +\n> +\tret = do_write_buffer_locked(map, chip, cmd_adr, adr, pvec, pvec_seek, len);\n> +\n> +\tDISABLE_VPP(map);\n> \tput_chip(map, chip, cmd_adr);\n> \tmutex_unlock(&chip->mutex);\n> \treturn ret;","headers":{"Return-Path":"\n ","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=QfvnSdlz;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=sttlUfSM;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=lists.infradead.org\n (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;\n envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frs1v21tCz1yD3\n\tfor ; Thu, 09 Apr 2026 17:26:35 +1000 (AEST)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wAjmO-00000009qhT-24FF;\n\tThu, 09 Apr 2026 07:26:20 +0000","from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wAjmJ-00000009qh4-43Pi\n\tfor linux-mtd@lists.infradead.org;\n\tThu, 09 Apr 2026 07:26:17 +0000","by mail-wm1-x32a.google.com with SMTP id\n 5b1f17b1804b1-48374014a77so6786625e9.3\n for ;\n Thu, 09 Apr 2026 00:26:15 -0700 (PDT)","from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36])\n by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-488cf9e8ab4sm36505175e9.4.2026.04.09.00.26.12\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 09 Apr 2026 00:26:13 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tMessage-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=JZPNudfkhkfop88BGTFTWCo/IS73gCBWSOqK9Uag7mw=; b=QfvnSdlzY0RdlF\n\t/b+E08JvuPKDWsWJiML8XSkxDlxUXLFKGFR405urWDiMb7XKn//+9RyXVXrJ4qwa5uqHO4xnu8n8b\n\tJYdyM83JKlUz246CjgB7CkHPjtkbC3rNirFvLvl/iVHgXUCgu6DsTH7GAg0O2ayaH9ORdfl3G4WLL\n\tG9hO/ugy6MNXUk7etaq1OMWUAitQ+fM9B/gOvCqdEIZmeN9q28HcUXulSsZ2TtxPFNgLf3QityxRA\n\t6LSALcLqZKacPxqYOkkY4wvFImDfVXlEgNrz+AP41pUWraWov82HTftKHRTibCEqM4CiO+6HXjlNs\n\tow9JzxMeLH/3oH8MB5Ew==;","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775719574; x=1776324374;\n darn=lists.infradead.org;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:subject:cc:to:from:date:from:to:cc:subject:date\n :message-id:reply-to;\n bh=lx+GdFng53t/7o6Wd37aZBbOEPPHmmkYglUTJhwvwJs=;\n b=sttlUfSMAjAr/tZGCsHUqLWj/BhLrjVI+pYcemyRh1uOeYfHWBMOV9BJVfBHvlBLf8\n I5D9yR/bRUKeKYgJ8mVwv5JPELPuW6FlZ4NnKaJaJFxkk1VEpcXmow+5+r/y6rpuOgBz\n twEJ3MCdSSCQlde+VohU/1SKgf9zSWDtj2q4aR7hXQJtJRJ+5Q8X5HJIr0v+9PaVLRqQ\n Heehbqo1mZ6wGa40zaESiOXGaodO+7RlytUr1iVPcFEAcCbdy7FHKHQoNoYcVBl7BF2G\n rnUjascdLY5oVMIxSP31eC0Ba9JkDP1joHRmh/TlXkLCl4IvEaA8TVtn3z72/MMg5FOH\n 1okg=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775719574; x=1776324374;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=lx+GdFng53t/7o6Wd37aZBbOEPPHmmkYglUTJhwvwJs=;\n b=m9u9Ec3bwGhy5Ba0heeSC2NGogaSxSScDhNYTbxaPg5WzBKoSptmgITn8EwcsE137/\n Pe54UgBXO/0/pRLTyQEIC/Qz0kDXXapyDD08EsLhUeuiD0+S/kl6X9dBP+AfZSS7lf3q\n Df+/Spe16awkoKemSwzu7O6Y2kf9XsbjRVLaCOodLwq88nBNHR+6P5+nOOcyEEjs3+VN\n ZfKTToOjGhS3Lfa2Z2rMYD+BMg7EPN9NLvwp6Y2jWXPnZIxHbLPoqNV6bm0F0uF+f8Sq\n z3Szmb+JPs7a5lD3lmFIHfb8No0HhRHsCY74Jy/YYQ19zcdkIlV/E+xEYuTuJyibsaGq\n AdqA==","X-Gm-Message-State":"AOJu0YwI6pqHKFvOEBd/jj0VcECA3IeEIBIEiasMBqT580ucrgbQxnFg\n\t5b5g9io0loTy2Q8f8zY+OCgMZOKG8Z9sBpOZWyqG5YRFefOQcCL5aGVm","X-Gm-Gg":"AeBDietIT9DmCQx/9gLbw9Chv0gzyBkQKKbCQfBT2UgstYNAXziTzJYJt1Vq6GSJBNE\n\tefbn5d1anWvhqFlWrWxfiOIEnnDdr2kItn3z2RTONvG4WZgHLeYuDQGMRXW01PnYJdUosnEeeM8\n\tYTCZLT44g3zLV1ElzZdUoBQIVqAIJW+7PL82p7NVW4MK6PC2gYrY3zc+VmQqJFe6YtateCywLoI\n\tMdWiHV85zJYcUrHEN8jZw8Y6FtoafEFkc/OtFyfybdGWEIYWDomfpS68myvYUJVzEHl3ltrwHSs\n\tk9GskzUEGTR5qpKM5o4Z3yBvQgj+rmyBHJz7RAPaq1q5gDNXgVwKFCqbGjGPfyvYyWSqMIb2tbi\n\tDkvGsQMQL/uI5OL4yZt1suAteqGWGgwnjqayqY67t3NaGar6A4vhqYqQt/zCW0xbQFSBKsZQT7D\n\tE1BWawemZONE1MRtUtcfNFSFwuiQI9RKsGt3950NKJIIQbabwfC3uq1AU38TSYx692","X-Received":"by 2002:a05:600c:3b87:b0:486:fe23:1707 with SMTP id\n 5b1f17b1804b1-488997ac1bdmr347254275e9.20.1775719573502;\n Thu, 09 Apr 2026 00:26:13 -0700 (PDT)","Date":"Thu, 9 Apr 2026 08:26:11 +0100","From":"David Laight ","To":"Andy Shevchenko ","Cc":"linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Miquel\n Raynal , Richard Weinberger ,\n Vignesh Raghavendra , Lukas Wunner ,\n Andrew Morton ","Subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","Message-ID":"<20260409082611.73fac9ab@pumpkin>","In-Reply-To":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>","References":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>","X-Mailer":"Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf)","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260409_002616_047601_FEF301D6 ","X-CRM114-Status":"GOOD ( 27.83 )","X-Spam-Score":"-2.1 (--)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam. The original\n message has been attached to this so you can view it or label\n similar future email. If you have any questions, see\n the administrator of that system for details.\n Content preview: On Wed, 8 Apr 2026 23:11:48 +0200 Andy Shevchenko wrote: >\n Compiler is not happy about used stack frame: > >\n drivers/mtd/chips/cfi_cmdset_0001.c:\n In function 'do_write_buffer': >\n drivers/mtd/chips/cfi_cmdset_0001.c:1887:1:\n error: the frame size of 1296 byte [...]\n Content analysis details: (-2.1 points, 5.0 required)\n pts rule name description\n ---- ----------------------\n --------------------------------------------------\n -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no\n trust\n [2a00:1450:4864:20:0:0:0:32a listed in]\n [list.dnswl.org]\n -0.0 SPF_PASS SPF: sender matches SPF record\n 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record\n -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from\n envelope-from domain\n 0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n not necessarily valid\n -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n author's\n domain\n -0.1 DKIM_VALID Message has at least one valid DKIM or DK\n signature\n -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n [score: 0.0000]\n 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n provider\n [david.laight.linux(at)gmail.com]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":3675133,"web_url":"http://patchwork.ozlabs.org/comment/3675133/","msgid":"","list_archive_url":null,"date":"2026-04-09T07:58:28","subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","submitter":{"id":68499,"url":"http://patchwork.ozlabs.org/api/people/68499/","name":"Lukas Wunner","email":"lukas@wunner.de"},"content":"On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wrote:\n> On Wed, 8 Apr 2026 23:11:48 +0200 Andy Shevchenko wrote:\n> > Compiler is not happy about used stack frame:\n> > \n> > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':\n> > 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=]\n> > \n> > Fix this by factoring out do_write_buffer_locked().\n> \n> Does this just split the large stack frame between two nested functions?\n> I'd also expect the compiler to inline do_write_buffer_locked() so it\n> makes little difference.\n> OTOH I can't immediately see where the large stack frame comes from.\n\nThe error occurs for an allmodconfig build on arm, which implies\nCONFIG_KASAN_STACK=y and thus increases stack usage vis-à-vis a\n\"regular\" build.\n\nStack usage is high here because of the three \"map_word\" types,\nwhich can each be up to 256 unsigned longs (32 * 8), see the\ndefinitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in\ninclude/linux/mtd/map.h.\n\nPossible solutions:\n\n- Disable KASAN entirely for this file:\n https://lore.kernel.org/all/adX3SHYgazijahbG@wunner.de/\n\n Not always a good option, particularly for stuff like lib/maple_tree.c\n where the same issue exists in mas_wr_spanning_store() and KASAN would\n certainly be good to have for that one.\n\n- Use heap instead of stack.\n\n- Split function in smaller chunks and mark them \"noinline\".\n\nThanks,\n\nLukas","headers":{"Return-Path":"\n ","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=AID85ZIw;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=lists.infradead.org\n (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;\n envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frskw133pz1yD3\n\tfor ; Thu, 09 Apr 2026 17:58:48 +1000 (AEST)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wAkHg-00000009tUm-1Qqi;\n\tThu, 09 Apr 2026 07:58:40 +0000","from mailout2.hostsharing.net ([83.223.78.233])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wAkHd-00000009tTF-0S3K\n\tfor linux-mtd@lists.infradead.org;\n\tThu, 09 Apr 2026 07:58:39 +0000","from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384\n\t client-signature ECDSA (secp384r1) client-digest SHA384)\n\t(Client CN \"*.hostsharing.net\",\n Issuer \"GlobalSign GCC R6 AlphaSSL CA 2025\" (verified OK))\n\tby mailout2.hostsharing.net (Postfix) with ESMTPS id 9C23910594;\n\tThu, 09 Apr 2026 09:58:28 +0200 (CEST)","by h08.hostsharing.net (Postfix, from userid 100393)\n\tid 94086602E9E7; Thu, 9 Apr 2026 09:58:28 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=RzsNvRAMuowP46Te6AspKwOyNNoFEtTkHceBjQJgpeE=; b=AID85ZIwXLuirQ\n\tPuoF1AcZrBFOn8wVKSeZI0fPD3NT6H3uN8bdPl/lvlEOmr/9oSdOmIZZ4BtkVMRin0FhGGNCtNaMX\n\t77UW61C0e4c9LmkeuPt5lOMvLE1XcFr03Ih7GiDtDtZZtmYNX23XPiWH+eSuB+mcDFD8sgE5Dbqc2\n\tuaX25PRDncxzPR8xvSHAKNzOIbtYY3JascniDH/9JG/cD44tDO7fU/IQQJBG9a2M6vu6D8GA+eFTk\n\tsYxGCcjd348leH33vZ/QZTzTSrOLffTKunE7TqMANxiP/yJ4EiZO7U+KnSK/0wb19ZlIFhuW6Ht9G\n\tislm/nkDchLuCEqzcUBA==;","Date":"Thu, 9 Apr 2026 09:58:28 +0200","From":"Lukas Wunner ","To":"David Laight ","Cc":"Andy Shevchenko ,\n\tlinux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tMiquel Raynal ,\n\tRichard Weinberger ,\n\tVignesh Raghavendra ,\n\tAndrew Morton ","Subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","Message-ID":"","References":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>\n <20260409082611.73fac9ab@pumpkin>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20260409082611.73fac9ab@pumpkin>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260409_005837_302509_7BFB82EF ","X-CRM114-Status":"GOOD ( 14.72 )","X-Spam-Score":"-2.6 (--)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam. The original\n message has been attached to this so you can view it or label\n similar future email. If you have any questions, see\n the administrator of that system for details.\n Content preview: On Thu, Apr 09, 2026 at 08:26:11AM +0100,\n David Laight wrote:\n > On Wed,\n 8 Apr 2026 23:11:48 +0200 Andy Shevchenko \n wrote: > > Compiler is not happy about used stack [...]\n Content analysis details: (-2.6 points, 5.0 required)\n pts rule name description\n ---- ----------------------\n --------------------------------------------------\n -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low\n trust\n [83.223.78.233 listed in list.dnswl.org]\n 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The\n query to Validity was blocked. See\n https://knowledge.validity.com/hc/en-us/articles/20961730681243\n for more information.\n [83.223.78.233 listed in\n sa-trusted.bondedsender.org]\n 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to\n Validity was blocked. See\n https://knowledge.validity.com/hc/en-us/articles/20961730681243\n for more information.\n [83.223.78.233 listed in sa-accredit.habeas.com]\n 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to\n Validity was blocked. See\n https://knowledge.validity.com/hc/en-us/articles/20961730681243\n for more information.\n [83.223.78.233 listed in\n bl.score.senderscore.com]\n -0.0 SPF_PASS SPF: sender matches SPF record\n -0.0 SPF_HELO_PASS SPF: HELO matches SPF record\n -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n [score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":3675259,"web_url":"http://patchwork.ozlabs.org/comment/3675259/","msgid":"<20260409122846.7d08d2b4@pumpkin>","list_archive_url":null,"date":"2026-04-09T11:28:46","subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","submitter":{"id":89989,"url":"http://patchwork.ozlabs.org/api/people/89989/","name":"David Laight","email":"david.laight.linux@gmail.com"},"content":"On Thu, 9 Apr 2026 09:58:28 +0200\nLukas Wunner wrote:\n\n> On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wrote:\n> > On Wed, 8 Apr 2026 23:11:48 +0200 Andy Shevchenko wrote: \n> > > Compiler is not happy about used stack frame:\n> > > \n> > > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':\n> > > 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=]\n> > > \n> > > Fix this by factoring out do_write_buffer_locked(). \n> > \n> > Does this just split the large stack frame between two nested functions?\n> > I'd also expect the compiler to inline do_write_buffer_locked() so it\n> > makes little difference.\n> > OTOH I can't immediately see where the large stack frame comes from. \n> \n> The error occurs for an allmodconfig build on arm, which implies\n> CONFIG_KASAN_STACK=y and thus increases stack usage vis-à-vis a\n> \"regular\" build.\n> \n> Stack usage is high here because of the three \"map_word\" types,\n> which can each be up to 256 unsigned longs (32 * 8), see the\n> definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in\n> include/linux/mtd/map.h.\n\nUgg - that code is horrid.\nReturning structures by value isn't really a good idea.\n\n> \n> Possible solutions:\n> \n> - Disable KASAN entirely for this file:\n> https://lore.kernel.org/all/adX3SHYgazijahbG@wunner.de/\n> \n> Not always a good option, particularly for stuff like lib/maple_tree.c\n> where the same issue exists in mas_wr_spanning_store() and KASAN would\n> certainly be good to have for that one.\n\nI've peeked at that at least once.\nSome big functions get inlined; IIRC one small function is basically:\n\tif (expr) a(args) else b(args);\nand marking both a and b noinline would help a lot.\n\n> \n> - Use heap instead of stack.\n> \n> - Split function in smaller chunks and mark them \"noinline\".\n\nThat might make the code easier to read as well.\n\nBut looking at it, I think that a small amount of refactoring\n(mostly moving the initial 'status' check before the command\nis written) would mean that only one 'map_word' would be valid\nat any one time.\n\nI didn't look at what was really happening though.\nI suspect it is similar to some code I've written for accessing serial\nEEPROM where the control data is written one bit at a time, but the\ndata itself is read/written in 4 bit chunks (although the low-level hardware\ndid multiple 'nibble' accesses for wider transfers).\nIn any case it surely can't be necessary to have a 256+ byte structure\nto hold the 8-bit command/status values.\n(In my case the 8 bits got 'spread' across a 32bit word and written\n(to the fgpa - helped because I was writing that end as well) as a single word.)\n\n\tDavid\n\n> \n> Thanks,\n> \n> Lukas\n>","headers":{"Return-Path":"\n ","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=x6qYy6S9;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=rqKDFCdL;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=lists.infradead.org\n (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;\n envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fryPt01HHz1yCv\n\tfor ; Thu, 09 Apr 2026 21:29:12 +1000 (AEST)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wAnZ7-0000000AGvl-2NyD;\n\tThu, 09 Apr 2026 11:28:53 +0000","from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wAnZ5-0000000AGvQ-3KtN\n\tfor linux-mtd@lists.infradead.org;\n\tThu, 09 Apr 2026 11:28:53 +0000","by mail-wm1-x32d.google.com with SMTP id\n 5b1f17b1804b1-488b0e1b870so11251955e9.2\n for ;\n Thu, 09 Apr 2026 04:28:51 -0700 (PDT)","from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36])\n by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-488cd1a028esm21313545e9.35.2026.04.09.04.28.48\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 09 Apr 2026 04:28:49 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:\n\tMessage-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=bPq19sblKpfNX6ZDf2/idqQP5p3Am1GWyxZ4a0tfubg=; b=x6qYy6S9D3IcOx\n\t3cVeEYE0nHp54IOQ9YFYFSy5NT9XXCabepruf5FpkqJJco0HO4hMkoG8//ufbTHEZOg0XmxHrcbOU\n\tZzplqi4ZkHQN19aa/Rm5ESeEum1tYcC+qCP17eEUhhPFL0kHYKznw/Yw52uQm427MxEUpkOm6F0Op\n\tITCDGSDKp59ENoTRHahWBDNG0MVHZxtRN2JzgZ58xIQ76F9K6qCV6Ii0udUT8Jr/cvUeLa1/8Y0Zg\n\tNuT3a4Rrb4xePjjljkrhvo8e0vQdJbI4bdMHo3O+ZgtQeZdms7pR6ul6teUUkhX2bvA/NhTydBgbA\n\t/Ssb0nZVYCr3TGIN+aVw==;","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775734130; x=1776338930;\n darn=lists.infradead.org;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:subject:cc:to:from:date:from:to:cc:subject:date\n :message-id:reply-to;\n bh=D2BUFDAL9oSVMfLEfPisTlW9oC5QFI4D3xBlET5WyxE=;\n b=rqKDFCdLDkNtslbwM9zuEFOe/uVna5+YbnDwC9uEDwXYEEy0zcwj0dyzR4uuj/SD3r\n 5LabgvYD29DbQkSgmn00546Wwa/ieHfr50wmQ5ao4fRQ5yKHdtOavtwstq7I2C6wwJ/c\n kOULvvfOvlYmxFFTJWP6LMR4/6xz2bT/reLv/uVYv6TgTQdH5JPoaYESS1KTxBVZcpsy\n xA1kXhA72aiJrt+et0cw3+Zyo9H6bZYXEKBFWs1pT14rmZHjbUu6946EVbZf4BymqHW9\n PrQhKL32Uhr8evAWFaM8akh0/XDggU77rAszUswveZ87UstlwAbhGDGN3OCrSbJutIMg\n abrg=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775734130; x=1776338930;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=D2BUFDAL9oSVMfLEfPisTlW9oC5QFI4D3xBlET5WyxE=;\n b=mHTg+MwBGj0am8SgfIapxQgrP77WipFI8Kj61OPekkUBeg7auGrWU/aeackOKSPuSP\n p0n96tE1v5GBQYWtOE0ogIygXvdEDhIbC2TyVhBPyE19e9sTcYdUQ7M9QqzE3MNT8VdA\n JWVmAltdQHhIDg2TiE9Gy/xSPu/ko41DLAE7kUMSVy56pyXt7FOjuVIFb5Sf3rfrAVDw\n vEXUUmh75KBs5O1LTkTFD5AnL8JJmsPYIbiUq/g9s8Mmwlbr+8Jrvx3SqF976WJcYUtx\n jDDJnKLorUKTcxhI1PzFoQ0IDCPQj6pFWKTvb95+Osh7Q8PVX0kSK82BTaeywhl0NxA3\n b14Q==","X-Forwarded-Encrypted":"i=1;\n AJvYcCUaV7p0uKQu5bjVPKlmpSdGBeu0pIHxk7ybDFa7crm9fHdSmXoYOWTfYQXuBsbWQJA5OpDxqPXSSoQ=@lists.infradead.org","X-Gm-Message-State":"AOJu0YxNLQ3FFAW5qCp2s62gzgp7kcSmVmP41WEfYesRz9bVW7dexUgB\n\tfunhL4hB0ntTkCLyOPFfRDQyZLm0CXVCQ0A3pAWn31wAevBdZJE0UkEp","X-Gm-Gg":"AeBDievKhtzoIx6ZEX8tsxsl0f+9mBiaQoxnyRvloQchzY7FkmYGYjUFVHO/oa2IbGv\n\tQzcXgNTqnBVt88cI9sZsRMLnHElzN+c5d0/OD4/ylaSt/7uuJ0pNiahueSk/ghysRglWVXK46yI\n\t9xmLUw2qX2zggxVvUdQfwNJS+g5A3cp/2XghnAF9vDx46+gUg2JKBdUMgrEwFtOp0cQCVmWXEYG\n\tDWTjx3cYF61xxGxkReSKQNv6KoPRxK/BQAqzwdPCwdWH9jWUCnEayqniWotnx3AaYbxMEU3Ty8v\n\t8HFKN5/Rq5EOAEAwAYVC6EUT1V8uemNMPFzepPzfxmzpDDCul8Ih1GoGmEYTLVu6n2E9IMpK0km\n\t7yV3q4Lis0DXP/rewF3L2v9OtM6Ox0WcbkcA3GIaqM4OFndufn+vO5Hf4BwdSSJVFmCc1GnjA63\n\tiLWbZ4sS2OBUdRC3VI6e4+xR0D8mSVXsKqrtMqmxs/0x88iWtDE3lsr90XlH/G/jFu","X-Received":"by 2002:a05:600c:4188:b0:488:a2ac:a34c with SMTP id\n 5b1f17b1804b1-488a2aca466mr158005365e9.12.1775734129648;\n Thu, 09 Apr 2026 04:28:49 -0700 (PDT)","Date":"Thu, 9 Apr 2026 12:28:46 +0100","From":"David Laight ","To":"Lukas Wunner ","Cc":"Andy Shevchenko ,\n linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Miquel Raynal\n , Richard Weinberger , Vignesh\n Raghavendra , Andrew Morton ","Subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","Message-ID":"<20260409122846.7d08d2b4@pumpkin>","In-Reply-To":"","References":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>\n\t<20260409082611.73fac9ab@pumpkin>\n\t","X-Mailer":"Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf)","MIME-Version":"1.0","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260409_042851_897838_EF56BD34 ","X-CRM114-Status":"GOOD ( 26.31 )","X-Spam-Score":"-2.1 (--)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam. The original\n message has been attached to this so you can view it or label\n similar future email. If you have any questions, see\n the administrator of that system for details.\n Content preview: On Thu, 9 Apr 2026 09:58:28 +0200 Lukas Wunner wrote: > On\n Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wrote: > > On Wed, 8\n Apr 2026 23:11:48 +0200 Andy Shevchenko wrote: > > > Compiler is not happy\n about used stack frame: > > > > > > drivers/m [...]\n Content analysis details: (-2.1 points, 5.0 required)\n pts rule name description\n ---- ----------------------\n --------------------------------------------------\n -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no\n trust\n [2a00:1450:4864:20:0:0:0:32d listed in]\n [list.dnswl.org]\n -0.0 SPF_PASS SPF: sender matches SPF record\n 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record\n -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from\n envelope-from domain\n 0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n not necessarily valid\n -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n author's\n domain\n -0.1 DKIM_VALID Message has at least one valid DKIM or DK\n signature\n -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n [score: 0.0000]\n 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n provider\n [david.laight.linux(at)gmail.com]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":3677168,"web_url":"http://patchwork.ozlabs.org/comment/3677168/","msgid":"","list_archive_url":null,"date":"2026-04-14T12:38:38","subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","submitter":{"id":8583,"url":"http://patchwork.ozlabs.org/api/people/8583/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Thu, Apr 09, 2026 at 12:28:46PM +0100, David Laight wrote:\n> On Thu, 9 Apr 2026 09:58:28 +0200\n> Lukas Wunner wrote:\n> > On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wrote:\n> > > On Wed, 8 Apr 2026 23:11:48 +0200 Andy Shevchenko wrote: \n> > > > Compiler is not happy about used stack frame:\n> > > > \n> > > > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':\n> > > > 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=]\n> > > > \n> > > > Fix this by factoring out do_write_buffer_locked(). \n> > > \n> > > Does this just split the large stack frame between two nested functions?\n> > > I'd also expect the compiler to inline do_write_buffer_locked() so it\n> > > makes little difference.\n> > > OTOH I can't immediately see where the large stack frame comes from. \n> > \n> > The error occurs for an allmodconfig build on arm, which implies\n> > CONFIG_KASAN_STACK=y and thus increases stack usage vis-à-vis a\n> > \"regular\" build.\n> > \n> > Stack usage is high here because of the three \"map_word\" types,\n> > which can each be up to 256 unsigned longs (32 * 8), see the\n> > definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in\n> > include/linux/mtd/map.h.\n> \n> Ugg - that code is horrid.\n> Returning structures by value isn't really a good idea.\n> \n> > \n> > Possible solutions:\n> > \n> > - Disable KASAN entirely for this file:\n> > https://lore.kernel.org/all/adX3SHYgazijahbG@wunner.de/\n> > \n> > Not always a good option, particularly for stuff like lib/maple_tree.c\n> > where the same issue exists in mas_wr_spanning_store() and KASAN would\n> > certainly be good to have for that one.\n> \n> I've peeked at that at least once.\n> Some big functions get inlined; IIRC one small function is basically:\n> \tif (expr) a(args) else b(args);\n> and marking both a and b noinline would help a lot.\n> \n> > \n> > - Use heap instead of stack.\n> > \n> > - Split function in smaller chunks and mark them \"noinline\".\n> \n> That might make the code easier to read as well.\n> \n> But looking at it, I think that a small amount of refactoring\n> (mostly moving the initial 'status' check before the command\n> is written) would mean that only one 'map_word' would be valid\n> at any one time.\n> \n> I didn't look at what was really happening though.\n> I suspect it is similar to some code I've written for accessing serial\n> EEPROM where the control data is written one bit at a time, but the\n> data itself is read/written in 4 bit chunks (although the low-level hardware\n> did multiple 'nibble' accesses for wider transfers).\n> In any case it surely can't be necessary to have a 256+ byte structure\n> to hold the 8-bit command/status values.\n> (In my case the 8 bits got 'spread' across a 32bit word and written\n> (to the fgpa - helped because I was writing that end as well) as a single word.)\n\nOkay, I leave this to maintainers to decide what to do with my contribution.\nDunno if this refactoring helps doing better one in the future (like David\nsuggested) or should be rewritten completely. In my opinion, smaller functions\nare always easier to follow.","headers":{"Return-Path":"\n ","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=EyxlBIis;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=Wk52GaWd;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=lists.infradead.org\n (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;\n envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fw3kC47S2z1yDF\n\tfor ; Tue, 14 Apr 2026 22:39:06 +1000 (AEST)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wCd2W-0000000HIzg-36Kt;\n\tTue, 14 Apr 2026 12:38:48 +0000","from mgamail.intel.com ([198.175.65.19])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wCd2T-0000000HIzL-3Q9C\n\tfor linux-mtd@lists.infradead.org;\n\tTue, 14 Apr 2026 12:38:47 +0000","from orviesa009.jf.intel.com ([10.64.159.149])\n by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 14 Apr 2026 05:38:44 -0700","from pgcooper-mobl3.ger.corp.intel.com (HELO localhost)\n ([10.245.245.106])\n by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 14 Apr 2026 05:38:41 -0700"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=saQdRQTqDS7Vev6iGscCzBz6i3EQymVOfRuiGXJTVd0=; b=EyxlBIisIiecXd\n\tW4CJKG2H2Q8NH4auQOFwsWRk296kL9KsYhTQ8dzbMVI7T2w8QkQls+k2AVLzBo/TaKLdBxmaiBJkV\n\taFy4trlpcuvO69joKBHAUniEUDGKEwYyuLJaioHKo6qUqB8GGaK2lP5M8DeQfSQr4E+6EQizT03xp\n\t88aQsOFzI9g5c2vVKxvkYhONArv/5h54qAadj8TiuINVdcsaSpbf0mvS/mjeBCWzm6Ii+O5NazWBq\n\tpYN5IjwAjTI09hChMO/dX/fOZeYk8YhSJxOxcSTII5dx0qpAHwOJI4CM4u+JjJ/4gc6pHn1ZvDYjn\n\tUInTeZ4Xg15c2viZl99g==;","v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1776170326; x=1807706326;\n h=date:from:to:cc:subject:message-id:references:\n mime-version:content-transfer-encoding:in-reply-to;\n bh=9gD9t0+kbSxr6E+N0FKZKJlGgNjiqmd6/XrBToiXwVo=;\n b=Wk52GaWdabmOEEu6lKPL2Pvw/r44IxagNBItwp71ctgyjQZELkQO8ls6\n uSS560zLJgppQZyRneOxWjpim13TrCwEQ02sAh0JUFlkmxIvNJNzWC69c\n sLCnHqSGWTiCqhZPb1AFLJBhcBdfQpTC3JgEvtoZvOFNONJhRHZGlLqHG\n aDSSkd2MLNMpBRkOx1FubU28aoILLkDBdlnHkIr6tX3gV48pOD6zp92tt\n G0touykSrmunO8P/d9ta96tfDem7iAXtnbYFNU9lRXE+9Q06s6hmomZSE\n PrDZDxxOHBMoYEbQj9DRmA5yH90OPKmh2g+Fayg5pDw2LM9V438T8CI94\n g==;"],"X-CSE-ConnectionGUID":["Yrdcu4EyRU6CPI2+kr43UQ==","G700Qm/mTxqCxUFLOBuj+g=="],"X-CSE-MsgGUID":["frGAfX8zSrWmcbIjkOV3Hg==","7OKeXwtGTeK90m0Jx2XsAA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11759\"; a=\"77029669\"","E=Sophos;i=\"6.23,179,1770624000\";\n d=\"scan'208\";a=\"77029669\"","E=Sophos;i=\"6.23,179,1770624000\";\n d=\"scan'208\";a=\"229953827\""],"X-ExtLoop1":"1","Date":"Tue, 14 Apr 2026 15:38:38 +0300","From":"Andy Shevchenko ","To":"David Laight ","Cc":"Lukas Wunner , linux-mtd@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org,\n\tMiquel Raynal ,\n\tRichard Weinberger ,\n\tVignesh Raghavendra ,\n\tAndrew Morton ","Subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","Message-ID":"","References":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>\n <20260409082611.73fac9ab@pumpkin>\n \n <20260409122846.7d08d2b4@pumpkin>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20260409122846.7d08d2b4@pumpkin>","Organization":"Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6\n krs, Bertel Jungin Aukio 5, 02600 Espoo","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260414_053845_928751_CED4570F ","X-CRM114-Status":"GOOD ( 33.16 )","X-Spam-Score":"-4.7 (----)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam. The original\n message has been attached to this so you can view it or label\n similar future email. If you have any questions, see\n the administrator of that system for details.\n Content preview: On Thu, Apr 09, 2026 at 12:28:46PM +0100,\n David Laight wrote:\n > On Thu,\n 9 Apr 2026 09:58:28 +0200 > Lukas Wunner wrote:\n > > On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wro [...]\n Content analysis details: (-4.7 points, 5.0 required)\n pts rule name description\n ---- ----------------------\n --------------------------------------------------\n -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/,\n medium trust\n [198.175.65.19 listed in list.dnswl.org]\n 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to\n Validity was blocked. See\n https://knowledge.validity.com/hc/en-us/articles/20961730681243\n for more information.\n [198.175.65.19 listed in sa-accredit.habeas.com]\n 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The\n query to Validity was blocked. See\n https://knowledge.validity.com/hc/en-us/articles/20961730681243\n for more information.\n [198.175.65.19 listed in\n sa-trusted.bondedsender.org]\n -0.0 SPF_PASS SPF: sender matches SPF record\n 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record\n 0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n not necessarily valid\n -0.1 DKIM_VALID Message has at least one valid DKIM or DK\n signature\n -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n [score: 0.0000]\n 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to\n Validity was blocked. See\n https://knowledge.validity.com/hc/en-us/articles/20961730681243\n for more information.\n [198.175.65.19 listed in\n bl.score.senderscore.com]\n -0.5 DKIMWL_WL_HIGH DKIMwl.org - High trust sender","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":3682782,"web_url":"http://patchwork.ozlabs.org/comment/3682782/","msgid":"<87ik9cfm6g.fsf@bootlin.com>","list_archive_url":null,"date":"2026-04-27T15:38:31","subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","submitter":{"id":73368,"url":"http://patchwork.ozlabs.org/api/people/73368/","name":"Miquel Raynal","email":"miquel.raynal@bootlin.com"},"content":"Hello,\n\nOn 14/04/2026 at 15:38:38 +03, Andy Shevchenko wrote:\n\n> On Thu, Apr 09, 2026 at 12:28:46PM +0100, David Laight wrote:\n>> On Thu, 9 Apr 2026 09:58:28 +0200\n>> Lukas Wunner wrote:\n>> > On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wrote:\n>> > > On Wed, 8 Apr 2026 23:11:48 +0200 Andy Shevchenko wrote: \n>> > > > Compiler is not happy about used stack frame:\n>> > > > \n>> > > > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':\n>> > > > 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=]\n>> > > > \n>> > > > Fix this by factoring out do_write_buffer_locked(). \n>> > > \n>> > > Does this just split the large stack frame between two nested functions?\n>> > > I'd also expect the compiler to inline do_write_buffer_locked() so it\n>> > > makes little difference.\n>> > > OTOH I can't immediately see where the large stack frame comes from. \n>> > \n>> > The error occurs for an allmodconfig build on arm, which implies\n>> > CONFIG_KASAN_STACK=y and thus increases stack usage vis-à-vis a\n>> > \"regular\" build.\n>> > \n>> > Stack usage is high here because of the three \"map_word\" types,\n>> > which can each be up to 256 unsigned longs (32 * 8), see the\n>> > definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in\n>> > include/linux/mtd/map.h.\n>> \n>> Ugg - that code is horrid.\n>> Returning structures by value isn't really a good idea.\n\nLooks like the primary reason for the stack over usage, no? Isn't\nplaying with inline and refactoring just a tiny fix that prevents\nproblem by just a couple of bytes?\n\nI haven't looked too carefully, but could we (Andy?) have a fix that\nreduces the number of map_word (as suggested, IIUC) and/or avoid passing\nthem by value? I can also take this cleanup if enclosed in a bigger\nseries, I don't mind because it may make the code easier to read as\nwell, but I feel like this is not a proper fix. If it is, please explain\nto me again :-)\n\nThanks,\nMiquèl","headers":{"Return-Path":"\n ","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=RrE/qaC2;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256\n header.s=dkim header.b=Q1EJCOu0;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=lists.infradead.org\n (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;\n envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g475R0h6jz1xvV\n\tfor ; Tue, 28 Apr 2026 01:38:51 +1000 (AEST)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wHO2k-0000000HDpl-0dlc;\n\tMon, 27 Apr 2026 15:38:42 +0000","from smtpout-04.galae.net ([185.171.202.116])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wHO2f-0000000HDpQ-3rAL\n\tfor linux-mtd@lists.infradead.org;\n\tMon, 27 Apr 2026 15:38:40 +0000","from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233])\n\tby smtpout-04.galae.net (Postfix) with ESMTPS id 5DE63C5CD4A;\n\tMon, 27 Apr 2026 15:39:18 +0000 (UTC)","from mail.galae.net (mail.galae.net [212.83.136.155])\n\tby smtpout-01.galae.net (Postfix) with ESMTPS id 079D0600D1;\n\tMon, 27 Apr 2026 15:38:35 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id A9EE710728068;\n\tMon, 27 Apr 2026 17:38:30 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References\n\t:In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=7IIQsS7UaO1UexbeRp63atfU+/zafBQYH+Q0Ba6jZP8=; b=RrE/qaC2kI1hlH\n\t006yJneqN6Two7X6h4Ls7ggZO5qyTpTaCCf7CKnksU36esPmLogZikIw+Xq+9+eWqyFzjfBISVclY\n\tKL5ajoZ4fHAhZYXzie+dTd1Yb9NwhQc/2lu7IiFG6991P9FuoEJfKygT2dpOFbCUwBiVzvtHd+NxC\n\t1c5LKSELoJDvQ9vpEtRODD/x/vwdy0dJ8wq59gzWZ/e3uuGk8w4ASWV4ueqxpTZMt8tMhU3wq65ev\n\tWXGUJYuEM7187dZvcfA0I18M2yvFxqNCwvgr3MJpDiD81CQ2VexvS3kWPv4slHr1HjB3E59DV0Jez\n\tAZTmpDWCkWvxpFesWTyg==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim;\n\tt=1777304314; h=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:in-reply-to:references;\n\tbh=h4EAmgSRIF0VbCoFpzON8QNgX3RE3NgJm+NruHt7Das=;\n\tb=Q1EJCOu0FMQP1X4wvVFZHxOXP8OKLGxy9qs38SL/7FhKV+FYApEaxNJq9hvY4xUbZRrrlJ\n\tWxXbwNeuOlPLkJb3lmd4D6Nvy+o18yEynHh8QpsX1srdiWabjePSSNCzdHGwzsNIc3yzpq\n\tIwvP2TbOvdSAetCJ/oxU4mcMugZz47ERxhrMMD0+YR2fP6vxttXSdbfPZy42zlpocT35ww\n\tA64Hi2mgpNpxAnMV3KYs3fKDYkvy7rvyb+A0q+VUmyjmLOdb4oA0IQhKlBFw0QKRhHYD98\n\tsBdf+rWcLSNXLGxUXVXmAWDl/ag+hrulZXy95MMpIm7vsOeJV8lChRA0/siurQ=="],"From":"Miquel Raynal ","To":"Andy Shevchenko ","Cc":"David Laight , Lukas Wunner\n , linux-mtd@lists.infradead.org,\n linux-kernel@vger.kernel.org, Richard Weinberger ,\n Vignesh Raghavendra , Andrew Morton\n ","Subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","In-Reply-To":" (Andy Shevchenko's message\n\tof \"Tue, 14 Apr 2026 15:38:38 +0300\")","References":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>\n\t<20260409082611.73fac9ab@pumpkin> \n\t<20260409122846.7d08d2b4@pumpkin>\n\t","User-Agent":"mu4e 1.12.7; emacs 30.2","Date":"Mon, 27 Apr 2026 17:38:31 +0200","Message-ID":"<87ik9cfm6g.fsf@bootlin.com>","MIME-Version":"1.0","X-Last-TLS-Session-Version":"TLSv1.3","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260427_083838_450479_D25031DB ","X-CRM114-Status":"GOOD ( 19.82 )","X-Spam-Score":"-2.1 (--)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam. The original\n message has been attached to this so you can view it or label\n similar future email. If you have any questions, see\n the administrator of that system for details.\n Content preview: Hello, On 14/04/2026 at 15:38:38 +03,\n Andy Shevchenko \n wrote: > On Thu, Apr 09, 2026 at 12:28:46PM +0100, David Laight wrote: >>\n On Thu, 9 Apr 2026 09:58:28 +0200 >> Lukas Wunner wrote:\n >> > On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laigh [...]\n Content analysis details: (-2.1 points, 5.0 required)\n pts rule name description\n ---- ----------------------\n --------------------------------------------------\n -0.0 SPF_PASS SPF: sender matches SPF record\n -0.0 SPF_HELO_PASS SPF: HELO matches SPF record\n -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from\n envelope-from domain\n -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n author's\n domain\n -0.1 DKIM_VALID Message has at least one valid DKIM or DK\n signature\n 0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n not necessarily valid\n -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n [score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":3682789,"web_url":"http://patchwork.ozlabs.org/comment/3682789/","msgid":"","list_archive_url":null,"date":"2026-04-27T15:47:58","subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","submitter":{"id":8583,"url":"http://patchwork.ozlabs.org/api/people/8583/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Mon, Apr 27, 2026 at 05:38:31PM +0200, Miquel Raynal wrote:\n> On 14/04/2026 at 15:38:38 +03, Andy Shevchenko wrote:\n> > On Thu, Apr 09, 2026 at 12:28:46PM +0100, David Laight wrote:\n> >> On Thu, 9 Apr 2026 09:58:28 +0200\n> >> Lukas Wunner wrote:\n> >> > On Thu, Apr 09, 2026 at 08:26:11AM +0100, David Laight wrote:\n> >> > > On Wed, 8 Apr 2026 23:11:48 +0200 Andy Shevchenko wrote: \n> >> > > > Compiler is not happy about used stack frame:\n> >> > > > \n> >> > > > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer':\n> >> > > > 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=]\n> >> > > > \n> >> > > > Fix this by factoring out do_write_buffer_locked(). \n> >> > > \n> >> > > Does this just split the large stack frame between two nested functions?\n> >> > > I'd also expect the compiler to inline do_write_buffer_locked() so it\n> >> > > makes little difference.\n> >> > > OTOH I can't immediately see where the large stack frame comes from. \n> >> > \n> >> > The error occurs for an allmodconfig build on arm, which implies\n> >> > CONFIG_KASAN_STACK=y and thus increases stack usage vis-à-vis a\n> >> > \"regular\" build.\n> >> > \n> >> > Stack usage is high here because of the three \"map_word\" types,\n> >> > which can each be up to 256 unsigned longs (32 * 8), see the\n> >> > definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in\n> >> > include/linux/mtd/map.h.\n> >> \n> >> Ugg - that code is horrid.\n> >> Returning structures by value isn't really a good idea.\n> \n> Looks like the primary reason for the stack over usage, no? Isn't\n> playing with inline and refactoring just a tiny fix that prevents\n> problem by just a couple of bytes?\n> \n> I haven't looked too carefully, but could we (Andy?) have a fix that\n> reduces the number of map_word (as suggested, IIUC) and/or avoid passing\n> them by value?\n\nI am not an expert for this particular change, I am afraid. Consider my patch\nas a bug report that needs to be addressed, Currently it might break some\nbuilds when `make W=1` is passed.\n\n> I can also take this cleanup if enclosed in a bigger\n> series, I don't mind because it may make the code easier to read as\n> well, but I feel like this is not a proper fix. If it is, please explain\n> to me again :-)","headers":{"Return-Path":"\n ","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=hUIPT5Fx;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=N5d3X5Dy;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=lists.infradead.org\n (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org;\n envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g47JC5jQjz1yHX\n\tfor ; Tue, 28 Apr 2026 01:48:11 +1000 (AEST)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wHOBp-0000000HEkV-2RCj;\n\tMon, 27 Apr 2026 15:48:05 +0000","from mgamail.intel.com ([192.198.163.11])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wHOBm-0000000HEjT-3dmu\n\tfor linux-mtd@lists.infradead.org;\n\tMon, 27 Apr 2026 15:48:03 +0000","from fmviesa002.fm.intel.com ([10.60.135.142])\n by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 27 Apr 2026 08:48:02 -0700","from fpallare-mobl4.ger.corp.intel.com (HELO localhost)\n ([10.245.244.2])\n by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 27 Apr 2026 08:48:00 -0700"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=0yiIgwl1xqb8p5HumQl2IhDp4AcMMgFq/6LyyPT0Y9U=; b=hUIPT5FxSTLGJp\n\tS1v9tPvFbnPEWj16rVswRD6+WVyxG4pfvLs6+AR0BvhMBRqY//5REtUviYmjBLQkTwhXA2p9fS/Sb\n\tmC3YdEtKx+sbdjfPMv9R15/gTIZTjhAWWpXl1ASba+sJTAgGEUJBV2XcSH7iYqTHDvsSnljZrgZL2\n\tc5kdn/TxSPdb95I3wI30BxW2YryQmwGK9zk4wLKRKlEc11H07+TIfuHLT9FgDCnKHyUBstb58xQn4\n\t3yt85QUsxUffxB9djjZeVMa74/HJnXGo6K3jYhfwnNwl+Lw3ryZeVTnBzPlK481kaUPnoooJCgESh\n\th75egaUN/bGnhzuFIdkw==;","v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1777304883; x=1808840883;\n h=date:from:to:cc:subject:message-id:references:\n mime-version:content-transfer-encoding:in-reply-to;\n bh=X0yZ8fv//dJjQj72P4wIFoT4NGZLaIID0GSsUCfRQXk=;\n b=N5d3X5DyvntZ+3LQxQY5ZAZpmwMHAVSBQAjMpTBoB4EF6li5AOlbI0ta\n MWorrewQ62El8HjCvwoZdJM8tNXEQDh5zYA1wdR4SBKuuHBzFWBhVgblr\n K4yQa2J7MhwPqYuHgNg1I8KvdNUSpKHtxnQsBdEEnDya5++5jtvV2KBFg\n ECr5Ie6Rk7c4YxWLArygURQszkT84JPF2ZEW2AFui+83/EETQb+0pclHv\n slCHS/kwCke4fyl9aZwtM5RH4CwK4SnUcgp8d2e21nX3AwFXbp99u1Vfp\n SRncsjDaKKMYRx4wn7gcwPajCCQsM+y8hcbPKV6/auFbULsv+TG7ckIkS\n A==;"],"X-CSE-ConnectionGUID":["qXot3YGqSIC5+Gr4ifs2rw==","DQJu360zTWS6XVnQGHAY+Q=="],"X-CSE-MsgGUID":["fZ5Idy5fQ1e8/HoRSLjQSA==","nehGvcVATL6KshOwM11xtg=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11769\"; a=\"88797394\"","E=Sophos;i=\"6.23,202,1770624000\";\n d=\"scan'208\";a=\"88797394\"","E=Sophos;i=\"6.23,202,1770624000\";\n d=\"scan'208\";a=\"256986764\""],"X-ExtLoop1":"1","Date":"Mon, 27 Apr 2026 18:47:58 +0300","From":"Andy Shevchenko ","To":"Miquel Raynal ","Cc":"David Laight ,\n\tLukas Wunner , linux-mtd@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org, Richard Weinberger ,\n\tVignesh Raghavendra ,\n\tAndrew Morton ","Subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","Message-ID":"","References":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>\n <20260409082611.73fac9ab@pumpkin>\n \n <20260409122846.7d08d2b4@pumpkin>\n \n <87ik9cfm6g.fsf@bootlin.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87ik9cfm6g.fsf@bootlin.com>","Organization":"Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6\n krs, Bertel Jungin Aukio 5, 02600 Espoo","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260427_084802_941184_B0B455F7 ","X-CRM114-Status":"GOOD ( 27.69 )","X-Spam-Score":"-4.2 (----)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam. The original\n message has been attached to this so you can view it or label\n similar future email. If you have any questions, see\n the administrator of that system for details.\n Content preview: On Mon, Apr 27, 2026 at 05:38:31PM +0200,\n Miquel Raynal wrote:\n > On 14/04/2026 at 15:38:38 +03,\n Andy Shevchenko \n wrote: > > On Thu, Apr 09, 2026 at 12:28:46PM +0100, [...]\n Content analysis details: (-4.2 points, 5.0 required)\n pts rule name description\n ---- ----------------------\n --------------------------------------------------\n -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/,\n medium trust\n [192.198.163.11 listed in list.dnswl.org]\n -0.0 SPF_PASS SPF: sender matches SPF record\n 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record\n -0.1 DKIM_VALID Message has at least one valid DKIM or DK\n signature\n 0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n not necessarily valid\n -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n [score: 0.0000]\n -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}},{"id":3683233,"web_url":"http://patchwork.ozlabs.org/comment/3683233/","msgid":"<87pl3jebsv.fsf@bootlin.com>","list_archive_url":null,"date":"2026-04-28T08:20:16","subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","submitter":{"id":73368,"url":"http://patchwork.ozlabs.org/api/people/73368/","name":"Miquel Raynal","email":"miquel.raynal@bootlin.com"},"content":">> >> > Stack usage is high here because of the three \"map_word\" types,\n>> >> > which can each be up to 256 unsigned longs (32 * 8), see the\n>> >> > definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, map_word in\n>> >> > include/linux/mtd/map.h.\n>> >> \n>> >> Ugg - that code is horrid.\n>> >> Returning structures by value isn't really a good idea.\n>> \n>> Looks like the primary reason for the stack over usage, no? Isn't\n>> playing with inline and refactoring just a tiny fix that prevents\n>> problem by just a couple of bytes?\n>> \n>> I haven't looked too carefully, but could we (Andy?) have a fix that\n>> reduces the number of map_word (as suggested, IIUC) and/or avoid passing\n>> them by value?\n>\n> I am not an expert for this particular change, I am afraid.\n\nSurprising flannel from someone sorely insisting to force contributors\ninto doing zillions more changes than they initially wanted, easily\ntriggering iniquitously NACKs otherwise.\n\n> Consider my patch\n> as a bug report that needs to be addressed, Currently it might break some\n> builds when `make W=1` is passed.\n\nHopefully you will remember that you have your own limits too. Maybe\nthat will allow others to breeze next time there will be something that\nmatters so much to you that you prefer to fully block their work.\n\n>> I can also take this cleanup if enclosed in a bigger\n>> series, I don't mind because it may make the code easier to read as\n>> well, but I feel like this is not a proper fix. If it is, please explain\n>> to me again :-)\n\nThanks,\nMiquèl","headers":{"Return-Path":"\n ","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=lists.infradead.org header.i=@lists.infradead.org\n header.a=rsa-sha256 header.s=bombadil.20210309 header.b=heJlTxSm;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256\n header.s=dkim header.b=Ygwqy2Ad;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=temperror (SPF Temporary Error: DNS Timeout)\n smtp.helo=bombadil.infradead.org (client-ip=2607:7c80:54:3::133;\n helo=bombadil.infradead.org;\n envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n [IPv6:2607:7c80:54:3::133])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g4YKm1QKzz1yHv\n\tfor ; Tue, 28 Apr 2026 18:20:36 +1000 (AEST)","from localhost ([::1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wHdg9-00000000sGH-3mGt;\n\tTue, 28 Apr 2026 08:20:25 +0000","from smtpout-02.galae.net ([185.246.84.56])\n\tby bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wHdg6-00000000sF8-0P6m\n\tfor linux-mtd@lists.infradead.org;\n\tTue, 28 Apr 2026 08:20:23 +0000","from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233])\n\tby smtpout-02.galae.net (Postfix) with ESMTPS id 2E9AB1A3474;\n\tTue, 28 Apr 2026 08:20:20 +0000 (UTC)","from mail.galae.net (mail.galae.net [212.83.136.155])\n\tby smtpout-01.galae.net (Postfix) with ESMTPS id EB2B4601D0;\n\tTue, 28 Apr 2026 08:20:19 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 8C1F1107284EB;\n\tTue, 28 Apr 2026 10:20:14 +0200 (CEST)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20210309; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References\n\t:In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=5IkwsjaIOeWKQx3hialG/rbLiQaGRl34643R7EV/e9w=; b=heJlTxSmNDiPuN\n\tUYhtfA5GHkSKgzG6DhvwlXFLlC5oFba1WqG9GnqkLAFztW4t4tmuhBvWVgQUhR4smgZcjQNmqbuuM\n\tKXgeTmE8w2b/T4sqpHJyhN/xFWKH3YlbtXOSesG53fHr9h9bPXT5Zuig99a1LFivbtEarcI+jpMlr\n\tkIOibPbLcvw+3WiC+5kKGt0o+1t4LSQyLd0pV6HhGAMyKxTTFFj5REvJSSxpgNag/FSv7hRYAgvFH\n\tFcEBsVeXVe2+5Io3XMeU1AlhUahfv0SOEUlGLELXjQ/j7y0Os2JhNgMtzpdfDOybJUQPtt92AqipG\n\tLCB/Alzf5emY9gD2rYjg==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim;\n\tt=1777364419; h=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:in-reply-to:references;\n\tbh=9aXcY0AV1qtSnfN/bX+A0N9tMeZsDrVOfumXOkBSD/U=;\n\tb=Ygwqy2Ad16PHxg6Azhkhz4AXBcHgjyHdY6MAccdU6RO9tB4gOirALtlRTrvC3peVLG+yaF\n\t4TO82X+auIp/OdOTI4WiiuHIyz8mMLX/sxYZnV6xMxJjVsx3ujzntXYaS1E97hstNXUZqJ\n\t3Y2Y8KN8LfDsC1E6aZXCqZRKDuzVn7C1Ddkl3jR6LzUS/qcnuaAItxc3wi5CFExaCVuhm/\n\t+UBDgggQuj4Oe6KmRByLHRmRBaB0VVN9D5umw95A9bTw9IcQALa9UuTmm93yOwMZSgwmEA\n\txBvzmvc0mVaXdGbaNXXO3pvcENSBEoPkI9fbFibm17iXOM+UZvUFraul76JuWQ=="],"From":"Miquel Raynal ","To":"Andy Shevchenko ","Cc":"David Laight , Lukas Wunner\n , linux-mtd@lists.infradead.org,\n linux-kernel@vger.kernel.org, Richard Weinberger ,\n Vignesh Raghavendra , Andrew Morton\n ","Subject":"Re: [PATCH v3 1/1] mtd: cfi_cmdset_0001: Factor out\n do_write_buffer_locked() to reduce stack frame","In-Reply-To":" (Andy Shevchenko's message\n\tof \"Mon, 27 Apr 2026 18:47:58 +0300\")","References":"<20260408211407.2295175-1-andriy.shevchenko@linux.intel.com>\n\t<20260409082611.73fac9ab@pumpkin> \n\t<20260409122846.7d08d2b4@pumpkin>\n\t <87ik9cfm6g.fsf@bootlin.com>\n\t","User-Agent":"mu4e 1.12.7; emacs 30.2","Date":"Tue, 28 Apr 2026 10:20:16 +0200","Message-ID":"<87pl3jebsv.fsf@bootlin.com>","MIME-Version":"1.0","X-Last-TLS-Session-Version":"TLSv1.3","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20260428_012022_265346_145B7C0E ","X-CRM114-Status":"GOOD ( 15.12 )","X-Spam-Score":"-2.1 (--)","X-Spam-Report":"Spam detection software,\n running on the system \"bombadil.infradead.org\",\n has NOT identified this incoming email as spam. The original\n message has been attached to this so you can view it or label\n similar future email. If you have any questions, see\n the administrator of that system for details.\n Content preview: >> >> > Stack usage is high here because of the three\n \"map_word\"\n types, >> >> > which can each be up to 256 unsigned longs (32 * 8),\n see the\n >> >> > definitions of MAX_MAP_LONGS, MAX_MAP_BANKWIDTH, m [...]\n Content analysis details: (-2.1 points, 5.0 required)\n pts rule name description\n ---- ----------------------\n --------------------------------------------------\n -0.0 SPF_PASS SPF: sender matches SPF record\n -0.0 SPF_HELO_PASS SPF: HELO matches SPF record\n -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from\n envelope-from domain\n 0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n not necessarily valid\n -0.1 DKIM_VALID Message has at least one valid DKIM or DK\n signature\n -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n author's\n domain\n -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n [score: 0.0000]","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.34","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}}]