linux-kernel - Re: [PATCH] iio: proximity: sx9500: use stack allocated buffer for scan data

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 for Android: free password hash cracker in your pocket

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

Message-ID: <c4d143f1-0649-4f64-ac71-419a4b2b0fca@baylibre.com>
Date: Sun, 13 Jul 2025 11:47:56 -0500
From: David Lechner <dlechner@...libre.com>
To: Jonathan Cameron <jic23@...nel.org>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: proximity: sx9500: use stack allocated buffer for
 scan data

On 7/13/25 8:58 AM, Jonathan Cameron wrote:
> On Sun, 13 Jul 2025 14:55:33 +0100
> Jonathan Cameron <jic23@...nel.org> wrote:
> 
>> On Fri, 11 Jul 2025 19:42:25 +0300
>> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
>>
>>> On Fri, Jul 11, 2025 at 10:47:57AM -0500, David Lechner wrote:  
>>>> Use IIO_DECLARE_BUFFER_WITH_TS() to declare a stack allocated buffer
>>>> in sx9500_trigger_handler(). Since the scan buffer isn't used outside
>>>> of this function, it doesn't need to be in struct sx9500_data.
>>>>
>>>> By always allocating enough space for the maximum number of channels,
>>>> we can avoid having to reallocate the buffer each time buffered reads
>>>> are enabled.    
>>>
>>> Ag ood one!
>>>
>>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
>>>   
>>
>> Applied.
>>
> 
> Actually on second thoughts - why not a more descriptive structure?
> There are only a max of 4 channels and so the timestamp is always
> in the same location.
> 
> Dropped for now.
> 
> Jonathan

I didn't do that on this one since a variable number of scan
elements are used. But if you prefer structs for anything up
to 8 bytes, we can go with that.