Re: [PATCH] rpmsg: glink: Release driver_override

[Chris Lew <quic_clew@quicinc.com>]

On 1/18/2023 9:50 AM, Bjorn Andersson wrote:
> On Tue, Jan 17, 2023 at 05:01:01PM -0800, Chris Lew wrote:
>>
>>
>> On 1/9/2023 2:38 PM, Bjorn Andersson wrote:
>>> Upon termination of the rpmsg_device, driver_override needs to be freed
>>> to avoid leaking the potentially assigned string.
>>>
>>> Fixes: 42cd402b8fd4 ("rpmsg: Fix kfree() of static memory on setting driver_override")
>>> Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device")
>>> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
>>> ---
>>>    drivers/rpmsg/qcom_glink_native.c | 2 ++
>>>    1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
>>> index 8620eea1dc8a..046271e439c5 100644
>>> --- a/drivers/rpmsg/qcom_glink_native.c
>>> +++ b/drivers/rpmsg/qcom_glink_native.c
>>> @@ -1454,6 +1454,7 @@ static void qcom_glink_rpdev_release(struct device *dev)
>>>    {
>>>    	struct rpmsg_device *rpdev = to_rpmsg_device(dev);
>>> +	kfree(rpdev->driver_override);
>>
>> I see in Krzysztof's original patch to fix up the driver_override we do
>> kfree in other areas of rpmsg.
>>
> 
> Right, in the original patch what became driver_set_override() was open
> coded and hence there was a kfree().
> 
>> More of a just curious as to why don't we use the driver_set_override
>> function to clear the string? It's mentioned in the rpmsg header that the
>> helper should be used.
>>
>> --- include/linux/rpmsg.h
>>   * @driver_override: driver name to force a match; do not set directly,
>>   *                   because core frees it; use driver_set_override() to
>>   *                   set or clear it.
>>
> 
> Looking around the kernel, just calling kfree() in the release function
> seems to be how others are doing it as well. As such I presume that
> comment applies to the runtime state, rather than while we're cleaning
> things up.
> 
> Regards,
> Bjorn
> 

Got it - should be safe to follow how others are handling this in cleanup.

Reviewed-by: Chris Lew <quic_clew@quicinc.com>

>>>    	kfree(rpdev);
>>>    }
>>> @@ -1697,6 +1698,7 @@ static void qcom_glink_device_release(struct device *dev)
>>>    	/* Release qcom_glink_alloc_channel() reference */
>>>    	kref_put(&channel->refcount, qcom_glink_channel_release);
>>> +	kfree(rpdev->driver_override);
>>>    	kfree(rpdev);
>>>    }
>>>