netdev - Re: [PATCH] macvlan: Don't propagate IFF_ALLMULTI changes on down interfaces.

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: <20140512.141554.1557022486435680828.davem@davemloft.net>
Date:	Mon, 12 May 2014 14:15:54 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	pch@...bogen.com
Cc:	kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: [PATCH] macvlan: Don't propagate IFF_ALLMULTI changes on down
 interfaces.

From: Peter Christensen <pch@...bogen.com>
Date: Mon, 12 May 2014 09:59:53 +0200

> On Fri, 09 May 2014 16:02:25 -0400 (EDT)
> David Miller <davem@...emloft.net> wrote:
> 
>> From: Peter Christensen <pch@...bogen.com>
>> Date: Thu,  8 May 2014 11:15:37 +0200
>> 
>> > Clearing the IFF_ALLMULTI flag on a down interface could cause an
>> > allmulti overflow on the underlying interface.
>> > 
>> > Attempting the set IFF_ALLMULTI on the underlying interface would
>> > cause an error and the log message:
>> > 
>> > "allmulti touches root, set allmulti failed."
>> > 
>> > Signed-off-by: Peter Christensen <pch@...bogen.com>
>> 
>> Hmmm, but won't we lose this event once the interface is brought
>> back up?
> 
> No, macvlan_open and macvlan_stop already takes care of that (which is
> part of the reason the allmulti counter overflowed). Either
> macvlan_open and macvlan_close shouldn't touch the flag on the
> underlying interface, or
> macvlan_change_rx_flags shouldn't touch the underlying interface if the
> MACVLAN interface is down.
> 
> I though that it was probably better to make MACVLAN as non-intrusive
> to the underlying interface when the MACVLAN interface is down, so I
> opted for this solution.
> 
> Apparently the 802.1Q VLAN driver behaves
> exactly like that, and back in 2011 it got a patch similar to this one
> (commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7).

Thanks for the detailed explanation, applied and queued up for -stable, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html