[PATCH 0/2] staging: vchiq_arm: Fix drv_mgmt leak

[PATCH 0/2] staging: vchiq_arm: Fix drv_mgmt leak

[Umang Jain]

1/2 is a drive by fix.
2/2 uses devres resouce management helper devm_kzalloc() to auto-free
struct vchiq_drv_mgmt on error and .remove() paths.

It might be good to aware the devres issue and following talk might
give reviewers a helpful context:

- https://lpc.events/event/16/contributions/1227/
- https://archive.fosdem.org/2023/schedule/event/devm_kzalloc/

I am not totally sure if these problems, causes a blockers for these
patches. There are a couple of memory management issues I've spotted
which can be fixed? by devres (similar to this series) but probably I
will wait for initial feedback on this series.

Umang Jain (2):
  staging: vchiq_arm: Drop blank lines
  staging: vchiq_arm: Use devm_kzalloc for mgmt

 .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c  | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

-- 
2.45.2

[PATCH 1/2] staging: vchiq_arm: Drop blank lines

[Umang Jain]

Drop unnecessary blank lines from vchiq_arm.c.

Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 ---
 1 file changed, 3 deletions(-)

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 27ceaac8f6cc..e780ed714a14 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -309,9 +309,6 @@ static struct vchiq_arm_state *vchiq_platform_get_arm_state(struct vchiq_state *
 	return (struct vchiq_arm_state *)state->platform_state;
 }
 
-
-
-
 void vchiq_dump_platform_state(struct seq_file *f)
 {
 	seq_puts(f, "  Platform: 2835 (VC master)\n");
-- 
2.45.2

Re: [PATCH 1/2] staging: vchiq_arm: Drop blank lines

[Stefan Wahren]

Hi Umang,

Am 13.10.24 um 10:45 schrieb Umang Jain:
> Drop unnecessary blank lines from vchiq_arm.c.
>
> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Danilo was a little bit faster [1], so I think you shouldn't care about
this.

Regards

[1] -
https://lore.kernel.org/linux-staging/20241012233931.30720-1-dpereira@lkcamp.dev/T/#u
> ---
>   drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 ---
>   1 file changed, 3 deletions(-)
>
> 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 27ceaac8f6cc..e780ed714a14 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -309,9 +309,6 @@ static struct vchiq_arm_state *vchiq_platform_get_arm_state(struct vchiq_state *
>   	return (struct vchiq_arm_state *)state->platform_state;
>   }
>
> -
> -
> -
>   void vchiq_dump_platform_state(struct seq_file *f)
>   {
>   	seq_puts(f, "  Platform: 2835 (VC master)\n");

[PATCH 2/2] staging: vchiq_arm: Use devm_kzalloc for mgmt

[Umang Jain]

Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

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 e780ed714a14..334fb7037766 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1345,7 +1345,7 @@ static int vchiq_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	mgmt = kzalloc(sizeof(*mgmt), GFP_KERNEL);
+	mgmt = devm_kzalloc(&pdev->dev, sizeof(*mgmt), GFP_KERNEL);
 	if (!mgmt)
 		return -ENOMEM;
 
@@ -1403,8 +1403,6 @@ static void vchiq_remove(struct platform_device *pdev)
 
 	arm_state = vchiq_platform_get_arm_state(&mgmt->state);
 	kthread_stop(arm_state->ka_thread);
-
-	kfree(mgmt);
 }
 
 static struct platform_driver vchiq_driver = {
-- 
2.45.2

Re: [PATCH 2/2] staging: vchiq_arm: Use devm_kzalloc for mgmt

[Stefan Wahren]

Hi Umang,

Am 13.10.24 um 10:45 schrieb Umang Jain:
> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
except of the missing commit message, this patch looks good to me. I
understand the concerns about devm_kzalloc, but I think this doesn't
apply in this case.

Since this should be treated as RFC, is it already tested?

Regards
> ---
>   drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> 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 e780ed714a14..334fb7037766 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -1345,7 +1345,7 @@ static int vchiq_probe(struct platform_device *pdev)
>   		return -ENOENT;
>   	}
>
> -	mgmt = kzalloc(sizeof(*mgmt), GFP_KERNEL);
> +	mgmt = devm_kzalloc(&pdev->dev, sizeof(*mgmt), GFP_KERNEL);
>   	if (!mgmt)
>   		return -ENOMEM;
>
> @@ -1403,8 +1403,6 @@ static void vchiq_remove(struct platform_device *pdev)
>
>   	arm_state = vchiq_platform_get_arm_state(&mgmt->state);
>   	kthread_stop(arm_state->ka_thread);
> -
> -	kfree(mgmt);
>   }
>
>   static struct platform_driver vchiq_driver = {

Re: [PATCH 2/2] staging: vchiq_arm: Use devm_kzalloc for mgmt

[Umang Jain]

On 13/10/24 2:43 pm, Stefan Wahren wrote:
> Hi Umang,
>
> Am 13.10.24 um 10:45 schrieb Umang Jain:
>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> except of the missing commit message, this patch looks good to me. I
> understand the concerns about devm_kzalloc, but I think this doesn't
> apply in this case.

That's what I was wondering as well, since I tried module unloading and 
with the cdev also goes away? So shouldn't be conern, right ?

>
> Since this should be treated as RFC, is it already tested?

yes, it was tested
>
> Regards
>> ---
>>   drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> 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 e780ed714a14..334fb7037766 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> @@ -1345,7 +1345,7 @@ static int vchiq_probe(struct platform_device 
>> *pdev)
>>           return -ENOENT;
>>       }
>>
>> -    mgmt = kzalloc(sizeof(*mgmt), GFP_KERNEL);
>> +    mgmt = devm_kzalloc(&pdev->dev, sizeof(*mgmt), GFP_KERNEL);
>>       if (!mgmt)
>>           return -ENOMEM;
>>
>> @@ -1403,8 +1403,6 @@ static void vchiq_remove(struct platform_device 
>> *pdev)
>>
>>       arm_state = vchiq_platform_get_arm_state(&mgmt->state);
>>       kthread_stop(arm_state->ka_thread);
>> -
>> -    kfree(mgmt);
>>   }
>>
>>   static struct platform_driver vchiq_driver = {
>

Re: [PATCH 2/2] staging: vchiq_arm: Use devm_kzalloc for mgmt

[Stefan Wahren]

Am 13.10.24 um 12:36 schrieb Umang Jain:
>
>
> On 13/10/24 2:43 pm, Stefan Wahren wrote:
>> Hi Umang,
>>
>> Am 13.10.24 um 10:45 schrieb Umang Jain:
>>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
>> except of the missing commit message, this patch looks good to me. I
>> understand the concerns about devm_kzalloc, but I think this doesn't
>> apply in this case.
>
> That's what I was wondering as well, since I tried module unloading
> and with the cdev also goes away? So shouldn't be conern, right ?
AFAIU the problem would be if you bind the resources to the cdev, but
this isn't the case here. Btw I missed to mention that this is
considered as a fix and deserves a Fixes tag.
>
>>
>> Since this should be treated as RFC, is it already tested?
>
> yes, it was tested
>>
>> Regards
>>> ---
>>> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +---
>>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> 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 e780ed714a14..334fb7037766 100644
>>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>>> @@ -1345,7 +1345,7 @@ static int vchiq_probe(struct platform_device
>>> *pdev)
>>>           return -ENOENT;
>>>       }
>>>
>>> -    mgmt = kzalloc(sizeof(*mgmt), GFP_KERNEL);
>>> +    mgmt = devm_kzalloc(&pdev->dev, sizeof(*mgmt), GFP_KERNEL);
>>>       if (!mgmt)
>>>           return -ENOMEM;
>>>
>>> @@ -1403,8 +1403,6 @@ static void vchiq_remove(struct
>>> platform_device *pdev)
>>>
>>>       arm_state = vchiq_platform_get_arm_state(&mgmt->state);
>>>       kthread_stop(arm_state->ka_thread);
>>> -
>>> -    kfree(mgmt);
>>>   }
>>>
>>>   static struct platform_driver vchiq_driver = {
>>
>

Re: [PATCH 0/2] staging: vchiq_arm: Fix drv_mgmt leak

[Umang Jain]

Hi,

[Treat this series as RFC]

On 13/10/24 2:15 pm, Umang Jain wrote:
> 1/2 is a drive by fix.
> 2/2 uses devres resouce management helper devm_kzalloc() to auto-free
> struct vchiq_drv_mgmt on error and .remove() paths.
>
> It might be good to aware the devres issue and following talk might
> give reviewers a helpful context:
>
> - https://lpc.events/event/16/contributions/1227/
> - https://archive.fosdem.org/2023/schedule/event/devm_kzalloc/
>
> I am not totally sure if these problems, causes a blockers for these
> patches. There are a couple of memory management issues I've spotted
> which can be fixed? by devres (similar to this series) but probably I
> will wait for initial feedback on this series.

Was supposed to mark this as RFC for discussion and yes, I have realised 
I've not written a commit message for 2/2.
>
> Umang Jain (2):
>    staging: vchiq_arm: Drop blank lines
>    staging: vchiq_arm: Use devm_kzalloc for mgmt
>
>   .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c  | 7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
>