[net] 8021q: fix a memory leak for VLAN 0 device

Message ID 20180109214041.26842-1-xiyou.wangcong@gmail.com
State Accepted
Delegated to: David Miller
Headers show
Series
  • [net] 8021q: fix a memory leak for VLAN 0 device
Related show

Commit Message

Cong Wang Jan. 9, 2018, 9:40 p.m.
A vlan device with vid 0 is allow to creat by not able to be fully
cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.

Also, VLAN 0 is probably not a valid number and it is kinda
"reserved" for HW accelerating devices, but it is probably too
late to reject it from creation even if makes sense. Instead,
just remove the check in unregister_vlan_dev().

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
 net/8021q/vlan.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

Comments

Nikolay Aleksandrov Jan. 9, 2018, 10:30 p.m. | #1
On 09/01/18 23:40, Cong Wang wrote:
> A vlan device with vid 0 is allow to creat by not able to be fully
> cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.
> 
> Also, VLAN 0 is probably not a valid number and it is kinda
> "reserved" for HW accelerating devices, but it is probably too
> late to reject it from creation even if makes sense. Instead,
> just remove the check in unregister_vlan_dev().
> 
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
>  net/8021q/vlan.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index 8dfdd94e430f..bad01b14a4ad 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -111,12 +111,7 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
>  		vlan_gvrp_uninit_applicant(real_dev);
>  	}
>  
> -	/* Take it out of our own structures, but be sure to interlock with
> -	 * HW accelerating devices or SW vlan input packet processing if
> -	 * VLAN is not 0 (leave it there for 802.1p).
> -	 */
> -	if (vlan_id)
> -		vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
> +	vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
>  
>  	/* Get rid of the vlan's reference to real_dev */
>  	dev_put(real_dev);
> 

Just for reference - this is identical to the first part of:
https://patchwork.ozlabs.org/patch/252891/

I knew this looked familiar. :-)
Cong Wang Jan. 9, 2018, 10:47 p.m. | #2
On Tue, Jan 9, 2018 at 2:30 PM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
>
> Just for reference - this is identical to the first part of:
> https://patchwork.ozlabs.org/patch/252891/
>
> I knew this looked familiar. :-)
>

Yeah, except bonding is not even involved. Unless I misread,
DaveM rejected it because of bond, which I never touch here.

The refcnt is paired in vlan_vid_{add,del}, and the calls are
paired in register/unreigster and NETDEV_UP/NETDEV_DOWN
after this patch.
Nikolay Aleksandrov Jan. 9, 2018, 10:53 p.m. | #3
On 01/10/2018 12:47 AM, Cong Wang wrote:
> On Tue, Jan 9, 2018 at 2:30 PM, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>>
>> Just for reference - this is identical to the first part of:
>> https://patchwork.ozlabs.org/patch/252891/
>>
>> I knew this looked familiar. :-)
>>
> 
> Yeah, except bonding is not even involved. Unless I misread,
> DaveM rejected it because of bond, which I never touch here.
> 
> The refcnt is paired in vlan_vid_{add,del}, and the calls are
> paired in register/unreigster and NETDEV_UP/NETDEV_DOWN
> after this patch.
> 

You should read all of my replies to Dave, specifically the last one where I
describe exactly a memory leak, and IIRC the rejection was not because of the
bonding part but exactly because of this change - the removal of the vlan_id
conditional.
I'm not arguing about this patch now, I've said what I had to say back then,
I just gave it as a reference in case there's still relevant information in
there.

Thanks,
 Nik
Cong Wang Jan. 9, 2018, 11:06 p.m. | #4
On Tue, Jan 9, 2018 at 2:53 PM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> On 01/10/2018 12:47 AM, Cong Wang wrote:
>> On Tue, Jan 9, 2018 at 2:30 PM, Nikolay Aleksandrov
>> <nikolay@cumulusnetworks.com> wrote:
>>>
>>> Just for reference - this is identical to the first part of:
>>> https://patchwork.ozlabs.org/patch/252891/
>>>
>>> I knew this looked familiar. :-)
>>>
>>
>> Yeah, except bonding is not even involved. Unless I misread,
>> DaveM rejected it because of bond, which I never touch here.
>>
>> The refcnt is paired in vlan_vid_{add,del}, and the calls are
>> paired in register/unreigster and NETDEV_UP/NETDEV_DOWN
>> after this patch.
>>
>
> You should read all of my replies to Dave, specifically the last one where I
> describe exactly a memory leak, and IIRC the rejection was not because of the
> bonding part but exactly because of this change - the removal of the vlan_id
> conditional.

Quote:
"If you have the 8021q module available, and you bring a device up, it gets
VLAN 0 by default, and if necessary programmed into the HW filters of the
device."

This is exactly a complain about your bonding check added for NETDEVUP,
which is clearly not here.

> I'm not arguing about this patch now, I've said what I had to say back then,
> I just gave it as a reference in case there's still relevant information in
> there.

Me neither, I just want to point it out memory leak is real
and not even related to bond.
Nikolay Aleksandrov Jan. 9, 2018, 11:13 p.m. | #5
On 01/10/2018 01:06 AM, Cong Wang wrote:
> On Tue, Jan 9, 2018 at 2:53 PM, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>> On 01/10/2018 12:47 AM, Cong Wang wrote:
>>> On Tue, Jan 9, 2018 at 2:30 PM, Nikolay Aleksandrov
>>> <nikolay@cumulusnetworks.com> wrote:
[snip]>> I'm not arguing about this patch now, I've said what I had to say back then,
>> I just gave it as a reference in case there's still relevant information in
>> there.
> 
> Me neither, I just want to point it out memory leak is real
> and not even related to bond.
> 

haha I know, all of my examples in there didn't have bond involved at all.
Again - IMO the patch is correct!
David Miller Jan. 10, 2018, 8:31 p.m. | #6
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue,  9 Jan 2018 13:40:41 -0800

> A vlan device with vid 0 is allow to creat by not able to be fully
> cleaned up by unregister_vlan_dev() which checks for vlan_id!=0.
> 
> Also, VLAN 0 is probably not a valid number and it is kinda
> "reserved" for HW accelerating devices, but it is probably too
> late to reject it from creation even if makes sense. Instead,
> just remove the check in unregister_vlan_dev().
> 
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>

Applied and queued up for -stable, thanks.

Patch

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 8dfdd94e430f..bad01b14a4ad 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -111,12 +111,7 @@  void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
 		vlan_gvrp_uninit_applicant(real_dev);
 	}
 
-	/* Take it out of our own structures, but be sure to interlock with
-	 * HW accelerating devices or SW vlan input packet processing if
-	 * VLAN is not 0 (leave it there for 802.1p).
-	 */
-	if (vlan_id)
-		vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
+	vlan_vid_del(real_dev, vlan->vlan_proto, vlan_id);
 
 	/* Get rid of the vlan's reference to real_dev */
 	dev_put(real_dev);