linux-kernel - Re: [PATCH] fbtft: reduce stack usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aEgIX221QIt5k0zY@smile.fi.intel.com>
Date: Tue, 10 Jun 2025 13:26:39 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Riyan Dhiman <riyandhiman14@...il.com>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Paolo Perego <pperego@...e.de>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Matthew Wilcox (Oracle)" <willy@...radead.org>,
	Jeff Johnson <jeff.johnson@....qualcomm.com>,
	dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
	linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fbtft: reduce stack usage

On Tue, Jun 10, 2025 at 11:24:38AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
> 
> The use of vararg function pointers combined with a huge number of
> arguments causes some configurations to exceed the stack size warning
> limit:
> 
> drivers/staging/fbtft/fbtft-core.c:863:12: error: stack frame size (1512) exceeds limit (1280) in 'fbtft_init_display_from_property' [-Werror,-Wframe-larger-than]
> 
> drivers/staging/fbtft/fb_ssd1331.c:131:30: error: stack frame size (1392) exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]
>                   ^
> drivers/staging/fbtft/fb_ssd1351.c:120:30: error: stack frame size (1392) exceeds limit (1280) in 'set_gamma' [-Werror,-Wframe-larger-than]
> 
> Move the varargs handling into a separate noinline function so each
> individual function stays below the limit. A better approach might be to
> replace the varargs function with one that takes an array of arguments,
> but that would be a much larger rework of the other callers.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>

...

> +static noinline_for_stack void fbtft_write_register_64(struct fbtft_par *par,
> +							int i, int buf[64])

Perhaps int i, int buf[64] should be u32?

> +{
> +	par->fbtftops.write_register(par, i,
> +		buf[0], buf[1], buf[2], buf[3],
> +		buf[4], buf[5], buf[6], buf[7],
> +		buf[8], buf[9], buf[10], buf[11],
> +		buf[12], buf[13], buf[14], buf[15],
> +		buf[16], buf[17], buf[18], buf[19],
> +		buf[20], buf[21], buf[22], buf[23],
> +		buf[24], buf[25], buf[26], buf[27],
> +		buf[28], buf[29], buf[30], buf[31],
> +		buf[32], buf[33], buf[34], buf[35],
> +		buf[36], buf[37], buf[38], buf[39],
> +		buf[40], buf[41], buf[42], buf[43],
> +		buf[44], buf[45], buf[46], buf[47],
> +		buf[48], buf[49], buf[50], buf[51],
> +		buf[52], buf[53], buf[54], buf[55],
> +		buf[56], buf[57], buf[58], buf[59],
> +		buf[60], buf[61], buf[62], buf[63]);
> +}

Wondering if we may reuse this in other cases (by providing the additional
length parameter). But it may be done later on.

-- 
With Best Regards,
Andy Shevchenko