Re: [PATCH v2 1/1] mtd: cfi_cmdset_0001: Factor out do_write_buffer_locked() to reduce stack frame

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, Apr 08, 2026 at 05:34:02PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 08, 2026 at 03:40:30PM +0200, Lukas Wunner wrote:
> > On Wed, Apr 08, 2026 at 02:27:43PM +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 08, 2026 at 08:35:52AM +0200, Lukas Wunner wrote:
> > > > On Wed, Feb 04, 2026 at 02:25:27AM +0100, 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().
> > > > 
> > > > FWIW, the issue only occurs with CONFIG_KASAN_STACK=y, so an alternative
> > > > to refactoring the function is to disable KASAN for this particular file:
> > > 
> > > I would like to avoid such big hammers.
> > > 
> > > Somehow I lost the track of this patch, I need to find it locally and check
> > > the status, I will come up with updated one once I found the latest version.
> > 
> > I just wanted to highlight that it's a KASAN-specific issue that doesn't
> > show up unless CONFIG_KASAN_STACK=y.  I think it's worth mentioning that
> > in the commit message.
> 
> Sure, makes sense.

Sorry, I forgot this in v3. If you still think it's crucial to have, I will
wait for MTD maintainers and update later on, but please, comment on v3, so
I won't forget it again (as it was two email threads for v2 and I missed one
to check carefully for the requests).

> > I'm not saying disabling KASAN is the right approach here, but it's one
> > *possible* approach.  Ideally the number of variables on the stack should
> > be reduced.  Perhaps alocating them on the heap would be more appropriate
> > than refactoring the code, I don't know.
> 
> Thanks, Lukas, for reviewing and proposing alternatives!

FWIW, v3 just has been sent: 20260408211407.2295175-1-andriy.shevchenko@linux.intel.com

-- 
With Best Regards,
Andy Shevchenko