linux-kernel - Re: [PATCH][next] iio: pressure: bmp280-core: Make read-only const array conversion_time

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] [day] [month] [year] [list]

Message-ID: <f799b77b-ff17-4379-9b95-ab7d8ab521dc@gmail.com>
Date: Tue, 23 Jul 2024 18:40:20 +0100
From: "Colin King (gmail)" <colin.i.king@...il.com>
To: Dan Carpenter <dan.carpenter@...aro.org>,
 Jonathan Cameron <jic23@...nel.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
 Vasileios Amoiridis <vassilisamir@...il.com>, linux-iio@...r.kernel.org,
 kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][next] iio: pressure: bmp280-core: Make read-only const
 array conversion_time_max static

On 23/07/2024 18:04, Dan Carpenter wrote:
> On Mon, Jul 22, 2024 at 09:01:11PM +0100, Jonathan Cameron wrote:
>> On Mon, 22 Jul 2024 16:17:38 +0100
>> Colin Ian King <colin.i.king@...il.com> wrote:
>>
>>> Don't populate the read-only array conversion_time_max on the stack at
>>> run time, instead make it static.
>>>
>>> Signed-off-by: Colin Ian King <colin.i.king@...il.com>
>>
>> I'm almost 100% the compiler can hoist this off the stack if it feels like
>> it but sure, it might not and adding the static keyword probably obliges
>> it to do so.
> 
> You would wish the compiler would do this correctly, but it doesn't.
> (Or it didn't the last time anyone checked).

 From what I understand, a const variable that's not static is either 
put in register or on the stack since it's implicitly an auto variable, 
hence it's populated with the initialization data at run time. Making it 
static will populate it at compile time. Assuming anything else is 
problematic.

Colin

> 
> regards,
> dan carpenter
>