2018-03-12 01:39:30

by Tobin C. Harding

[permalink] [raw]
Subject: [PATCH v2] staging: vchiq_arm: Clear VLA warning

The kernel would like to have all stack VLA usage removed[1]. The array
here is fixed (declared with a const variable) but it appears like a VLA
to the compiler. Also, currently we are putting 768 bytes on the
stack. This function is only called on the error path so performance is
not critical, let's just allocate the memory instead of using the
stack. This saves stack space and removes the VLA build warning.

kmalloc a buffer for dumping state instead of using the stack.

[1]: https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Tobin C. Harding <[email protected]>
---

v1 of this patch already merged into staging-testing branch of Greg's
staging tree. This patch depends on v1 being removed, can re-do this
one on top of tip of staging-testing if required.

v2:
- Use kmalloc() instead of the stack

Patch is untested.

drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index f5cefda49b22..408ea73f8da7 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -3455,11 +3455,15 @@ vchiq_dump_service_use_state(VCHIQ_STATE_T *state)
int fourcc;
int clientid;
int use_count;
- } service_data[local_max_services];
+ } *service_data;

if (!arm_state)
return;

+ service_data = kmalloc_array(local_max_services, sizeof(*service_data), GFP_KERNEL);
+ if (!service_data)
+ return;
+
read_lock_bh(&arm_state->susp_res_lock);
vc_suspend_state = arm_state->vc_suspend_state;
vc_resume_state = arm_state->vc_resume_state;
--
2.7.4



2018-03-12 05:47:25

by Tobin C. Harding

[permalink] [raw]
Subject: Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote:
> The kernel would like to have all stack VLA usage removed[1]. The array
> here is fixed (declared with a const variable) but it appears like a VLA
> to the compiler. Also, currently we are putting 768 bytes on the
> stack. This function is only called on the error path so performance is
> not critical, let's just allocate the memory instead of using the
> stack. This saves stack space and removes the VLA build warning.
>
> kmalloc a buffer for dumping state instead of using the stack.
>
> [1]: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Tobin C. Harding <[email protected]>
> ---

Drop this please, leaks memory.

thanks,
Tobin.

2018-03-12 05:59:40

by Stefan Wahren

[permalink] [raw]
Subject: Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

Hi Tobin,

> "Tobin C. Harding" <[email protected]> hat am 12. März 2018 um 06:46 geschrieben:
>
>
> On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote:
> > The kernel would like to have all stack VLA usage removed[1]. The array
> > here is fixed (declared with a const variable) but it appears like a VLA
> > to the compiler. Also, currently we are putting 768 bytes on the
> > stack. This function is only called on the error path so performance is
> > not critical, let's just allocate the memory instead of using the
> > stack. This saves stack space and removes the VLA build warning.
> >
> > kmalloc a buffer for dumping state instead of using the stack.
> >
> > [1]: https://lkml.org/lkml/2018/3/7/621
> >
> > Signed-off-by: Tobin C. Harding <[email protected]>
> > ---
>
> Drop this please, leaks memory.

except from the leak, did you test this patch on a RPi?

Thanks
Stefan

>
> thanks,
> Tobin.

2018-03-12 06:07:05

by Tobin C. Harding

[permalink] [raw]
Subject: Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

On Mon, Mar 12, 2018 at 06:58:04AM +0100, Stefan Wahren wrote:
> Hi Tobin,
>
> > "Tobin C. Harding" <[email protected]> hat am 12. M?rz 2018 um 06:46 geschrieben:
> >
> >
> > On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote:
> > > The kernel would like to have all stack VLA usage removed[1]. The array
> > > here is fixed (declared with a const variable) but it appears like a VLA
> > > to the compiler. Also, currently we are putting 768 bytes on the
> > > stack. This function is only called on the error path so performance is
> > > not critical, let's just allocate the memory instead of using the
> > > stack. This saves stack space and removes the VLA build warning.
> > >
> > > kmalloc a buffer for dumping state instead of using the stack.
> > >
> > > [1]: https://lkml.org/lkml/2018/3/7/621
> > >
> > > Signed-off-by: Tobin C. Harding <[email protected]>
> > > ---
> >
> > Drop this please, leaks memory.
>
> except from the leak, did you test this patch on a RPi?

No I didn't, but I can have a go at it. Will try before doing v3.

thanks,
Tobin.

2018-03-12 11:16:14

by Dan Carpenter

[permalink] [raw]
Subject: Re: [PATCH v2] staging: vchiq_arm: Clear VLA warning

On Mon, Mar 12, 2018 at 06:58:04AM +0100, Stefan Wahren wrote:
> Hi Tobin,
>
> > "Tobin C. Harding" <[email protected]> hat am 12. M?rz 2018 um 06:46 geschrieben:
> >
> >
> > On Mon, Mar 12, 2018 at 12:37:53PM +1100, Tobin C. Harding wrote:
> > > The kernel would like to have all stack VLA usage removed[1]. The array
> > > here is fixed (declared with a const variable) but it appears like a VLA
> > > to the compiler. Also, currently we are putting 768 bytes on the
> > > stack. This function is only called on the error path so performance is
> > > not critical, let's just allocate the memory instead of using the
> > > stack. This saves stack space and removes the VLA build warning.
> > >
> > > kmalloc a buffer for dumping state instead of using the stack.
> > >
> > > [1]: https://lkml.org/lkml/2018/3/7/621
> > >
> > > Signed-off-by: Tobin C. Harding <[email protected]>
> > > ---
> >
> > Drop this please, leaks memory.
>
> except from the leak, did you test this patch on a RPi?
>

Hm... Yeah. It looks like we're holding a mutex when we call
vchiq_check_service() from vchiq_queue_message().

regards,
dan carpenter