In preparation to enabling -Wvla, remove VLA. In this particular
case use macro ARRAY_SIZE so the length of array _result_ can be
computed at preprocessing time.
The use of stack Variable Length Arrays needs to be avoided, as they
can be a vector for stack exhaustion, which can be both a runtime bug
or a security flaw. Also, in general, as code evolves it is easy to
lose track of how big a VLA can get. Thus, we can end up having runtime
failures that are hard to debug.
Also, fixed as part of the directive to remove all VLAs from
the kernel: https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Gustavo A. R. Silva <[email protected]>
---
drivers/iio/potentiometer/ds1803.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/potentiometer/ds1803.c b/drivers/iio/potentiometer/ds1803.c
index 9b0ff4a..6bf12c9 100644
--- a/drivers/iio/potentiometer/ds1803.c
+++ b/drivers/iio/potentiometer/ds1803.c
@@ -64,7 +64,7 @@ static int ds1803_read_raw(struct iio_dev *indio_dev,
struct ds1803_data *data = iio_priv(indio_dev);
int pot = chan->channel;
int ret;
- u8 result[indio_dev->num_channels];
+ u8 result[ARRAY_SIZE(ds1803_channels)];
switch (mask) {
case IIO_CHAN_INFO_RAW:
--
2.7.4
Hi Gustavo,
On Tue, Mar 13, 2018 at 10:23:43AM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA. In this particular
> case use macro ARRAY_SIZE so the length of array _result_ can be
> computed at preprocessing time.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in general, as code evolves it is easy to
> lose track of how big a VLA can get. Thus, we can end up having runtime
> failures that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva <[email protected]>
> ---
It is already applied as I had sent the patch few days ago.
https://lkml.org/lkml/2018/3/10/164
I specifically CC'ed you and Kees to avoid the patch collisions.
--
Thanks
Himanshu Jha
On 03/13/2018 11:24 AM, Himanshu Jha wrote:
> Hi Gustavo,
>
> On Tue, Mar 13, 2018 at 10:23:43AM -0500, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wvla, remove VLA. In this particular
>> case use macro ARRAY_SIZE so the length of array _result_ can be
>> computed at preprocessing time.
>>
>> The use of stack Variable Length Arrays needs to be avoided, as they
>> can be a vector for stack exhaustion, which can be both a runtime bug
>> or a security flaw. Also, in general, as code evolves it is easy to
>> lose track of how big a VLA can get. Thus, we can end up having runtime
>> failures that are hard to debug.
>>
>> Also, fixed as part of the directive to remove all VLAs from
>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>
>> Signed-off-by: Gustavo A. R. Silva <[email protected]>
>> ---
>
> It is already applied as I had sent the patch few days ago.
> https://lkml.org/lkml/2018/3/10/164
>
> I specifically CC'ed you and Kees to avoid the patch collisions.
>
I see. Can you please update this spreadsheet:
https://docs.google.com/spreadsheets/d/1OcfyKK8pJ24esYhSEsW4Q2boZE7UTGbYsSEEtFXf7U0/edit
Thanks
--
Gustavo
On Tue, Mar 13, 2018 at 11:31:19AM -0500, Gustavo A. R. Silva wrote:
>
>
> On 03/13/2018 11:24 AM, Himanshu Jha wrote:
> >Hi Gustavo,
> >
> >On Tue, Mar 13, 2018 at 10:23:43AM -0500, Gustavo A. R. Silva wrote:
> >>In preparation to enabling -Wvla, remove VLA. In this particular
> >>case use macro ARRAY_SIZE so the length of array _result_ can be
> >>computed at preprocessing time.
> >>
> >>The use of stack Variable Length Arrays needs to be avoided, as they
> >>can be a vector for stack exhaustion, which can be both a runtime bug
> >>or a security flaw. Also, in general, as code evolves it is easy to
> >>lose track of how big a VLA can get. Thus, we can end up having runtime
> >>failures that are hard to debug.
> >>
> >>Also, fixed as part of the directive to remove all VLAs from
> >>the kernel: https://lkml.org/lkml/2018/3/7/621
> >>
> >>Signed-off-by: Gustavo A. R. Silva <[email protected]>
> >>---
> >
> >It is already applied as I had sent the patch few days ago.
> >https://lkml.org/lkml/2018/3/10/164
> >
> >I specifically CC'ed you and Kees to avoid the patch collisions.
> >
>
> I see. Can you please update this spreadsheet:
>
> https://docs.google.com/spreadsheets/d/1OcfyKK8pJ24esYhSEsW4Q2boZE7UTGbYsSEEtFXf7U0/edit
Updated!
Also,
drivers/iio/humidity/hts221_i2c.c:43:2: warning: ISO C90
forbids variable length array ‘send’ [-Wvla]
This was already removed in recent commit when regmap API was used.
"6217792 iio: humidity: hts221: add regmap API support"
For this I added a short note in the *Notes* column.
--
Thanks
Himanshu Jha
On 03/13/2018 11:59 AM, Himanshu Jha wrote:
> On Tue, Mar 13, 2018 at 11:31:19AM -0500, Gustavo A. R. Silva wrote:
>>
>>
>> On 03/13/2018 11:24 AM, Himanshu Jha wrote:
>>> Hi Gustavo,
>>>
>>> On Tue, Mar 13, 2018 at 10:23:43AM -0500, Gustavo A. R. Silva wrote:
>>>> In preparation to enabling -Wvla, remove VLA. In this particular
>>>> case use macro ARRAY_SIZE so the length of array _result_ can be
>>>> computed at preprocessing time.
>>>>
>>>> The use of stack Variable Length Arrays needs to be avoided, as they
>>>> can be a vector for stack exhaustion, which can be both a runtime bug
>>>> or a security flaw. Also, in general, as code evolves it is easy to
>>>> lose track of how big a VLA can get. Thus, we can end up having runtime
>>>> failures that are hard to debug.
>>>>
>>>> Also, fixed as part of the directive to remove all VLAs from
>>>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>>>
>>>> Signed-off-by: Gustavo A. R. Silva <[email protected]>
>>>> ---
>>>
>>> It is already applied as I had sent the patch few days ago.
>>> https://lkml.org/lkml/2018/3/10/164
>>>
>>> I specifically CC'ed you and Kees to avoid the patch collisions.
>>>
>>
>> I see. Can you please update this spreadsheet:
>>
>> https://docs.google.com/spreadsheets/d/1OcfyKK8pJ24esYhSEsW4Q2boZE7UTGbYsSEEtFXf7U0/edit
>
> Updated!
>
> Also,
>
> drivers/iio/humidity/hts221_i2c.c:43:2: warning: ISO C90
> forbids variable length array ‘send’ [-Wvla]
>
> This was already removed in recent commit when regmap API was used.
>
> "6217792 iio: humidity: hts221: add regmap API support"
>
> For this I added a short note in the *Notes* column.
>
Awesome.
Thank you
--
Gustavo
On 03/13/2018 11:59 AM, Himanshu Jha wrote:
> On Tue, Mar 13, 2018 at 11:31:19AM -0500, Gustavo A. R. Silva wrote:
>>
>>
>> On 03/13/2018 11:24 AM, Himanshu Jha wrote:
>>> Hi Gustavo,
>>>
>>> On Tue, Mar 13, 2018 at 10:23:43AM -0500, Gustavo A. R. Silva wrote:
>>>> In preparation to enabling -Wvla, remove VLA. In this particular
>>>> case use macro ARRAY_SIZE so the length of array _result_ can be
>>>> computed at preprocessing time.
>>>>
>>>> The use of stack Variable Length Arrays needs to be avoided, as they
>>>> can be a vector for stack exhaustion, which can be both a runtime bug
>>>> or a security flaw. Also, in general, as code evolves it is easy to
>>>> lose track of how big a VLA can get. Thus, we can end up having runtime
>>>> failures that are hard to debug.
>>>>
>>>> Also, fixed as part of the directive to remove all VLAs from
>>>> the kernel: https://lkml.org/lkml/2018/3/7/621
>>>>
>>>> Signed-off-by: Gustavo A. R. Silva <[email protected]>
>>>> ---
>>>
>>> It is already applied as I had sent the patch few days ago.
>>> https://lkml.org/lkml/2018/3/10/164
>>>
>>> I specifically CC'ed you and Kees to avoid the patch collisions.
>>>
>>
>> I see. Can you please update this spreadsheet:
>>
>> https://docs.google.com/spreadsheets/d/1OcfyKK8pJ24esYhSEsW4Q2boZE7UTGbYsSEEtFXf7U0/edit
>
> Updated!
>
> Also,
>
> drivers/iio/humidity/hts221_i2c.c:43:2: warning: ISO C90
> forbids variable length array ‘send’ [-Wvla]
>
> This was already removed in recent commit when regmap API was used.
>
> "6217792 iio: humidity: hts221: add regmap API support"
>
> For this I added a short note in the *Notes* column.
>
Awesome.
Thank you
--
Gustavo