* [PATCH v2] net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
@ 2023-02-09 9:32 Hangyu Hua
2023-02-09 10:58 ` [ovs-dev] " Simon Horman
0 siblings, 1 reply; 4+ messages in thread
From: Hangyu Hua @ 2023-02-09 9:32 UTC (permalink / raw)
To: pshelar, davem, edumazet, kuba, pabeni, xiangxia.m.yue, echaudro
Cc: netdev, dev, linux-kernel, Hangyu Hua
old_meter needs to be free after it is detached regardless of whether
the new meter is successfully attached.
Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
---
v2: use goto label and free old_meter outside of ovs lock.
net/openvswitch/meter.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/openvswitch/meter.c b/net/openvswitch/meter.c
index 6e38f68f88c2..9b680f0894f1 100644
--- a/net/openvswitch/meter.c
+++ b/net/openvswitch/meter.c
@@ -417,6 +417,7 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
int err;
u32 meter_id;
bool failed;
+ bool locked = true;
if (!a[OVS_METER_ATTR_ID])
return -EINVAL;
@@ -448,11 +449,13 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
goto exit_unlock;
err = attach_meter(meter_tbl, meter);
- if (err)
- goto exit_unlock;
ovs_unlock();
+ if (err) {
+ locked = false;
+ goto exit_free_old_meter;
+ }
/* Build response with the meter_id and stats from
* the old meter, if any.
*/
@@ -472,8 +475,11 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
genlmsg_end(reply, ovs_reply_header);
return genlmsg_reply(reply, info);
+exit_free_old_meter:
+ ovs_meter_free(old_meter);
exit_unlock:
- ovs_unlock();
+ if (locked)
+ ovs_unlock();
nlmsg_free(reply);
exit_free_meter:
kfree(meter);
--
2.34.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [ovs-dev] [PATCH v2] net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
2023-02-09 9:32 [PATCH v2] net: openvswitch: fix possible memory leak in ovs_meter_cmd_set() Hangyu Hua
@ 2023-02-09 10:58 ` Simon Horman
2023-02-09 13:42 ` Eelco Chaudron
0 siblings, 1 reply; 4+ messages in thread
From: Simon Horman @ 2023-02-09 10:58 UTC (permalink / raw)
To: Hangyu Hua
Cc: pshelar, davem, edumazet, kuba, pabeni, xiangxia.m.yue, echaudro,
dev, netdev, linux-kernel
On Thu, Feb 09, 2023 at 05:32:40PM +0800, Hangyu Hua wrote:
> old_meter needs to be free after it is detached regardless of whether
> the new meter is successfully attached.
>
> Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number")
> Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
> ---
>
> v2: use goto label and free old_meter outside of ovs lock.
>
> net/openvswitch/meter.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/net/openvswitch/meter.c b/net/openvswitch/meter.c
> index 6e38f68f88c2..9b680f0894f1 100644
> --- a/net/openvswitch/meter.c
> +++ b/net/openvswitch/meter.c
> @@ -417,6 +417,7 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
> int err;
> u32 meter_id;
> bool failed;
> + bool locked = true;
>
> if (!a[OVS_METER_ATTR_ID])
> return -EINVAL;
> @@ -448,11 +449,13 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
> goto exit_unlock;
>
> err = attach_meter(meter_tbl, meter);
> - if (err)
> - goto exit_unlock;
>
> ovs_unlock();
>
> + if (err) {
> + locked = false;
> + goto exit_free_old_meter;
> + }
> /* Build response with the meter_id and stats from
> * the old meter, if any.
> */
> @@ -472,8 +475,11 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
> genlmsg_end(reply, ovs_reply_header);
> return genlmsg_reply(reply, info);
>
> +exit_free_old_meter:
> + ovs_meter_free(old_meter);
> exit_unlock:
> - ovs_unlock();
> + if (locked)
> + ovs_unlock();
I see where you are going here, but is the complexity of the
locked variable worth the benefit of freeing old_meter outside
the lock?
> nlmsg_free(reply);
> exit_free_meter:
> kfree(meter);
> --
> 2.34.1
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ovs-dev] [PATCH v2] net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
2023-02-09 10:58 ` [ovs-dev] " Simon Horman
@ 2023-02-09 13:42 ` Eelco Chaudron
2023-02-10 1:52 ` Hangyu Hua
0 siblings, 1 reply; 4+ messages in thread
From: Eelco Chaudron @ 2023-02-09 13:42 UTC (permalink / raw)
To: Simon Horman
Cc: Hangyu Hua, pshelar, davem, edumazet, kuba, pabeni,
xiangxia.m.yue, dev, netdev, linux-kernel
On 9 Feb 2023, at 11:58, Simon Horman wrote:
> On Thu, Feb 09, 2023 at 05:32:40PM +0800, Hangyu Hua wrote:
>> old_meter needs to be free after it is detached regardless of whether
>> the new meter is successfully attached.
>>
>> Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number")
>> Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
>> ---
>>
>> v2: use goto label and free old_meter outside of ovs lock.
>>
>> net/openvswitch/meter.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/openvswitch/meter.c b/net/openvswitch/meter.c
>> index 6e38f68f88c2..9b680f0894f1 100644
>> --- a/net/openvswitch/meter.c
>> +++ b/net/openvswitch/meter.c
>> @@ -417,6 +417,7 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>> int err;
>> u32 meter_id;
>> bool failed;
>> + bool locked = true;
>>
>> if (!a[OVS_METER_ATTR_ID])
>> return -EINVAL;
>> @@ -448,11 +449,13 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>> goto exit_unlock;
>>
>> err = attach_meter(meter_tbl, meter);
>> - if (err)
>> - goto exit_unlock;
>>
>> ovs_unlock();
>>
>> + if (err) {
>> + locked = false;
>> + goto exit_free_old_meter;
>> + }
>> /* Build response with the meter_id and stats from
>> * the old meter, if any.
>> */
>> @@ -472,8 +475,11 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>> genlmsg_end(reply, ovs_reply_header);
>> return genlmsg_reply(reply, info);
>>
>> +exit_free_old_meter:
>> + ovs_meter_free(old_meter);
>> exit_unlock:
>> - ovs_unlock();
>> + if (locked)
>> + ovs_unlock();
>
> I see where you are going here, but is the complexity of the
> locked variable worth the benefit of freeing old_meter outside
> the lock?
Looking at the error path, I would agree with Simon, and just add an “exit_free_old_meter” label as suggested in v1 and keep the lock in place to make the error path more straightforward.
//Eelco
>> nlmsg_free(reply);
>> exit_free_meter:
>> kfree(meter);
>> --
>> 2.34.1
>>
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ovs-dev] [PATCH v2] net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
2023-02-09 13:42 ` Eelco Chaudron
@ 2023-02-10 1:52 ` Hangyu Hua
0 siblings, 0 replies; 4+ messages in thread
From: Hangyu Hua @ 2023-02-10 1:52 UTC (permalink / raw)
To: Eelco Chaudron, Simon Horman
Cc: pshelar, davem, edumazet, kuba, pabeni, xiangxia.m.yue, dev,
netdev, linux-kernel
On 9/2/2023 21:42, Eelco Chaudron wrote:
>
>
> On 9 Feb 2023, at 11:58, Simon Horman wrote:
>
>> On Thu, Feb 09, 2023 at 05:32:40PM +0800, Hangyu Hua wrote:
>>> old_meter needs to be free after it is detached regardless of whether
>>> the new meter is successfully attached.
>>>
>>> Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number")
>>> Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
>>> ---
>>>
>>> v2: use goto label and free old_meter outside of ovs lock.
>>>
>>> net/openvswitch/meter.c | 12 +++++++++---
>>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/net/openvswitch/meter.c b/net/openvswitch/meter.c
>>> index 6e38f68f88c2..9b680f0894f1 100644
>>> --- a/net/openvswitch/meter.c
>>> +++ b/net/openvswitch/meter.c
>>> @@ -417,6 +417,7 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>>> int err;
>>> u32 meter_id;
>>> bool failed;
>>> + bool locked = true;
>>>
>>> if (!a[OVS_METER_ATTR_ID])
>>> return -EINVAL;
>>> @@ -448,11 +449,13 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>>> goto exit_unlock;
>>>
>>> err = attach_meter(meter_tbl, meter);
>>> - if (err)
>>> - goto exit_unlock;
>>>
>>> ovs_unlock();
>>>
>>> + if (err) {
>>> + locked = false;
>>> + goto exit_free_old_meter;
>>> + }
>>> /* Build response with the meter_id and stats from
>>> * the old meter, if any.
>>> */
>>> @@ -472,8 +475,11 @@ static int ovs_meter_cmd_set(struct sk_buff *skb, struct genl_info *info)
>>> genlmsg_end(reply, ovs_reply_header);
>>> return genlmsg_reply(reply, info);
>>>
>>> +exit_free_old_meter:
>>> + ovs_meter_free(old_meter);
>>> exit_unlock:
>>> - ovs_unlock();
>>> + if (locked)
>>> + ovs_unlock();
>>
>> I see where you are going here, but is the complexity of the
>> locked variable worth the benefit of freeing old_meter outside
>> the lock?
>
> Looking at the error path, I would agree with Simon, and just add an “exit_free_old_meter” label as suggested in v1 and keep the lock in place to make the error path more straightforward.
>
> //Eelco
I see. I will send a v3 later.
Thanks,
Hangyu
>
>>> nlmsg_free(reply);
>>> exit_free_meter:
>>> kfree(meter);
>>> --
>>> 2.34.1
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-02-10 1:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-09 9:32 [PATCH v2] net: openvswitch: fix possible memory leak in ovs_meter_cmd_set() Hangyu Hua
2023-02-09 10:58 ` [ovs-dev] " Simon Horman
2023-02-09 13:42 ` Eelco Chaudron
2023-02-10 1:52 ` Hangyu Hua
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).