From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 9F930288B1 for ; Thu, 9 Apr 2026 11:28:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775734133; cv=none; b=lkawvPQ4/1SPzinH4JzI3lhgY35bETy8Yh3Pcl0Ks0kmIx64z5WZVnWO58AmWz36G34DouxHsNRIJD0fegQl0ibXp59GFsHsfVlAtKKC4nmf9rNHK7a3J296t3rYupYHwAWvV+h2XkFiesOjomCmqYcy62cfJ9Vu3GfIgHBG8xg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775734133; c=relaxed/simple; bh=WNhq0sk1fP6k3zq7z2JYGYazV57Uq0t7WSqU6HzevJI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QxRWue/cEfwN7X+COeoFraG2KHQW8iD/oA37iWsUOoqYeCZE7j0HKS1U0gELYUrEBC7aBeb05cJXxI6o3zgWZsDa251tdRa59D2zAb4LmEwJZcIKw1oeqD5XEtY9wxQbVaq8nnlEjs/yN+hekHn4WlkGtx5q/Lbkb4kBQNImFqw= 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=n4SJWhtA; arc=none smtp.client-ip=209.85.128.45 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="n4SJWhtA" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4887f49ec5aso10372535e9.1 for ; Thu, 09 Apr 2026 04:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775734130; x=1776338930; 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=D2BUFDAL9oSVMfLEfPisTlW9oC5QFI4D3xBlET5WyxE=; b=n4SJWhtAFmepUHifQV6KsKqIAZwYAGcRnzzhpLRAM9zoQWzq8Rf+fmYi37WVT0aYv2 M4P9iVDLWlRRB9IBpJ2QoVVPHfSuBjsoHwcyaDUpD81imhWeLauLzvCBX4Z9k4+7Swox nIXnIHX3f+iU+RXHQspfOexPnLR0U9aOAJbZdz4WKttrlong0V0QQ/18iTqK+dJ5sLNw UfQALi9O1kq3y5KOIZTpOV+54slfq14VKxAJEYUtzC43oJh43/rq7Ibdpm+NP/9IyfSS fDpo+lNj3DM4Dai4OJ/cJGSK70ZoY3QNCcRnOFG3eOfvSqjfA/iSmPzFMt9Xd2P2SNjM 7j5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775734130; x=1776338930; 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=D2BUFDAL9oSVMfLEfPisTlW9oC5QFI4D3xBlET5WyxE=; b=qtiMuwrPD931oniEb7Mpveqti1ukg6CiDmqmB91W+HeoP6klsvpP7KSjy0tB8aiEGf TLamOb07g9ZmyHOShlPE09jvkxZejiEam8/8fQXWqJxZ7r4CbaO1NivDoTx33vEhsNv0 4PVjRk4/fNkFdszBP2e+p5gQfF7UrypKxGptn7nRp7KbeFTR0ALPqR7TGyrwol+3yx9i jw6TxwXCi+a+PdQ6m33XxONntezY0a/4ZVo1veQhTVu1JVaT5TagsiAwWUk8WVQ6lSIJ SI05x9k/hlCMhgv6pwJ7dB6xaom4jn8OV9YFHz+Zv85xEV54jYiHx0LBXHnnwTs5VfD1 v92Q== X-Forwarded-Encrypted: i=1; AJvYcCV6OfL/6GNFLx2JpqyKjdMkVXfkHZGnnw5Jxa7rQCVX8GcV82ckjAJpPCd7jUxtlxHTLSTuuv2jo4cgM9w=@vger.kernel.org X-Gm-Message-State: AOJu0YxX6v4JPy/GVvFmK3ZqQS/PdMhoFhLahEVkC5mk9CfDbe31QCGs NF35kQqSuN248ZMLgjFuzNAyjp6BpC0cLSv0dgC7sPZtGaHyOpQ+6Jj3 X-Gm-Gg: AeBDiesRihPNfa8EcN+Gen8hu3pEqt5jnhPJCxBsAcZGEOGZVsH+h/pG9xgZEL8ZvLP a7O5BdQtl64kc43T+gldAVbmgwbRzIROklq/LMqQXGwc8icV950N6yZbSzkPlXzKzLzd00J3BDb wMdbTmsQxJv40My2gvbJwAEvJzi9/4shKsn4gvyQwwu7o9Koiw3kpayysIBSf2T7sGmdpLTXwof 1De+Gu3/TWw/kdZtYPJ5kiTJJ2A3QSiQ44oetcmDpPp/FLV1SZYfjD/FaHgrs3y8ulXjgB2viQJ mgSUeCaUdokwxkZNDoL3i6sCstuwWcoKDQ9Oq59+ejeoiOIOBkio8g3Aw8x75VB9onkM2oA6nen mrfdt5GepxImKW4JXNCJ26HZtdexGi79zH1uaiLm7Ve3UBE3u4yb59BBkp5mQcXqwSAwq98zG4i HScTNuel1HX2ud/ky4MGo/eOjlJyfXTCD5G6jqg6KgYG2Ch5ZPu0kFd0EjwM1S1XRd X-Received: by 2002:a05:600c:4188:b0:488:a2ac:a34c with SMTP id 5b1f17b1804b1-488a2aca466mr158005365e9.12.1775734129648; Thu, 09 Apr 2026 04:28:49 -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-488cd1a028esm21313545e9.35.2026.04.09.04.28.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); 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 , 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: <20260409122846.7d08d2b4@pumpkin> In-Reply-To: References: <20260408211407.2295175-1-andriy.shevchenko@linux.intel.com> <20260409082611.73fac9ab@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=UTF-8 Content-Transfer-Encoding: quoted-printable 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: =20 > > > Compiler is not happy about used stack frame: > > >=20 > > > 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=3Dframe-larger-than=3D] > > >=20 > > > Fix this by factoring out do_write_buffer_locked(). =20 > >=20 > > 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. =20 >=20 > The error occurs for an allmodconfig build on arm, which implies > CONFIG_KASAN_STACK=3Dy and thus increases stack usage vis-=C3=A0-vis a > "regular" build. >=20 > 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. >=20 > Possible solutions: >=20 > - Disable KASAN entirely for this file: > https://lore.kernel.org/all/adX3SHYgazijahbG@wunner.de/ >=20 > 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. >=20 > - Use heap instead of stack. >=20 > - 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 w= ord.) David >=20 > Thanks, >=20 > Lukas >=20