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: <088dc0a1-fc54-478c-b253-4ed5dd6d6bae@app.fastmail.com>
Date: Tue, 10 Jun 2025 12:35:14 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>,
 "Arnd Bergmann" <arnd@...nel.org>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 "Riyan Dhiman" <riyandhiman14@...il.com>,
 "Thomas Zimmermann" <tzimmermann@...e.de>, "Paolo Perego" <pperego@...e.de>,
 "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
 "Matthew Wilcox" <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 12:26, Andy Shevchenko wrote:
> On Tue, Jun 10, 2025 at 11:24:38AM +0200, Arnd Bergmann wrote:
>> 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>
>
> ...

Thanks

>> +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?

Right, I can send an updated patch, or this could be fixed up when applying
the patch

>> +{
>> +	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.

I tried this and that quickly became a mess. It is probably a good
idea to rework the code to completely avoid the varargs function
pointer and instead take an array here, but this is not something
I could easily do myself as that takes more time and needs better
testing.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ