lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <F832C073-F038-40ED-B739-40799F3B859C@cmss.chinamobile.com>
Date:   Fri, 19 Jul 2019 09:43:47 +0800
From:   Haishuang Yan <yanhaishuang@...s.chinamobile.com>
To:     Gregory Rose <gvrose8192@...il.com>
Cc:     Pravin B Shelar <pshelar@....org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] openvswitch: Fix a possible memory leak on dst_cache


> On 2019年7月19日, at 上午6:12, Gregory Rose <gvrose8192@...il.com> wrote:
> 
> On 7/18/2019 9:07 AM, Haishuang Yan wrote:
>> dst_cache should be destroyed when fail to add flow actions.
>> 
>> Fixes: d71785ffc7e7 ("net: add dst_cache to ovs vxlan lwtunnel")
>> Signed-off-by: Haishuang Yan <yanhaishuang@...s.chinamobile.com>
>> ---
>>  net/openvswitch/flow_netlink.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
>> index d7559c6..1fd1cdd 100644
>> --- a/net/openvswitch/flow_netlink.c
>> +++ b/net/openvswitch/flow_netlink.c
>> @@ -2608,6 +2608,7 @@ static int validate_and_copy_set_tun(const struct nlattr *attr,
>>  			 sizeof(*ovs_tun), log);
>>  	if (IS_ERR(a)) {
>>  		dst_release((struct dst_entry *)tun_dst);
>> +		dst_cache_destroy(&tun_dst->u.tun_info.dst_cache);
>>  		return PTR_ERR(a);
>>  	}
>>  
> 
> Nack.
> 
> dst_release will decrement the ref count and will call_rcu(&dst->rcu_head, dst_destroy_rcu) if the ref count is zero.  No other net drivers call dst_destroy SFAICT.
> 
> Haishuang,
> 
> are you trying to fix some specific problem here?
> 
> Thanks,
> 
> - Greg
> 
> 

Greg,

You’re right, dst_cache would be freed in metadata_dst_free:

  125
  126         if (dst->flags & DST_METADATA)
  127                 metadata_dst_free((struct metadata_dst *)dst);
  128         else
  129                 kmem_cache_free(dst->ops->kmem_cachep, dst);
  130

I thought I encountered a memory leak, but it seems not an issue, thanks for you explanation.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ