netdev - Re: PIM-SM namespace changes

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: <4A366FB0.40608@openvz.org>
Date:	Mon, 15 Jun 2009 19:58:40 +0400
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	David Miller <davem@...emloft.net>
CC:	thomas.goff@...ing.com, netdev@...r.kernel.org
Subject: Re: PIM-SM namespace changes

David Miller wrote:
> From: Tom Goff <thomas.goff@...ing.com>
> Date: Tue, 19 May 2009 17:43:44 -0700
> 
>> For protocol registration I see three basic approaches for using PIM
>> with namespaces:
>>
>>   - unconditionally add PIM when multicast routing is initialized
>>     (maybe only ifdef CONFIG_NET_NS, otherwise preserve the current
>>     behavior)
>>
>>   - keep a count of the number of namespaces that have enabled PIM and
>>     add/delete PIM when transitioning from/to zero
>>
>>   - make all or some protocol registration per network namespace
>>
>> There are obviously tradeoffs and I would appreciate any
>> comments/suggestions on alternatives that allow namespace use of
>> dynamically enabled protocols.
> 
> Ok, I'm willing to accept your current approach for now, let's
> see what falls out of this.  Patch applied, thanks.
> 
> Doing the enabling per-namespace is complexity for an unknown
> gain.  I don't even know what the benefit could be for how we
> behaved previously.
> 
> Anyone know?

Well, maybe I do :)

I haven't thought much about per-namespace protocols, but I think, that
it makes sense to enable/disable at least virtual devices (tunnels and
vlans currently) per-namespace.

Not every namespace really needs this big amount of functionality and
saving sizeof(struct net_device) + private - the fallback devices each
tunnel creates, and this is somewhat around 4Kb each - sounds good.

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

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