netdev - Re: [PATCH RFC] netns: keep vlan slaves on master netns move

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: <m1fwwvqhob.fsf@fess.ebiederm.org>
Date:	Mon, 27 Sep 2010 09:23:32 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Daniel Lezcano <daniel.lezcano@...e.fr>,
	David Lamparter <equinox@...c24.net>
Subject: Re: [PATCH RFC] netns: keep vlan slaves on master netns move

Patrick McHardy <kaber@...sh.net> writes:

> Am 15.09.2010 04:10, schrieb Eric W. Biederman:
>> 
>> Reviewed-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> 
>> My inclination is that the best way to handle this is to would be to
>> push the device deletion for vlan and macvlan devices into the device
>> core, where we could get the advantage of batched deletions.
>
> We've added batched deletion to both about a year ago, what exactly
> is the problem?

My problem is that while the both have dellink implemented we
don't really batch their deletes as best we can.

For macvlan when the underlying device is unregistered we delete
each macvlan device one by one.

For vlans we do batch the deletes, but not in the same batch as
the underlying device.

>>  Right
>> now vlan and macvlan devices are the only devices I know of that cause
>> other devices to be removed during unregister, so removing that
>> specialness seems reasonable.
>
> Actually all devices can cause this when used as a lower device by
> vlan or macvlan. Both vlan and macvlan are useless without a lower
> device, so I don't see why we shouldn't remove them when the lower
> device is unregistered.

I definitely think we should remove the devices when the lower device
is destroyed/removed.  However unregistered is a slightly different
concept, and arguably macvlan and vlan devices are much more intimately
connected to their underlying device than that.

What I meant is we should implement the deletion differently.  By doing
something like having a list of all derived devices for a device, that
we could walk and call dellink on from rollback_registered_many.  In
theory that could destroy a whole pile of macvlan and vlan devices with
various different stackings one on the other all in the same batch.

Eric
--
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