netdev - Re: RFC: dsa slave open handling

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: <20110307193853.GA16649@mail.wantstofly.org>
Date:	Mon, 7 Mar 2011 20:38:53 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Peter Korsgaard <jacmet@...site.dk>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: RFC: dsa slave open handling

On Mon, Mar 07, 2011 at 08:35:47PM +0100, Peter Korsgaard wrote:

>  >> Currently the state of the dsa master device and slave devices are not
>  >> synchronized which leads to various issues. With dsa, the master device
>  >> needs to be running before you can use the slave devices, but it
>  >> shouldn't be used directly for I/O.
> 
>  Lennert> I think this should not be handled any differently than VLAN
>  Lennert> interfaces, where eth0 needs to be up before you can exchange
>  Lennert> packets over eth0.123.
> 
>  Lennert> IOW, if you want to do DHCP over wan (a DSA-tunneled interface
>  Lennert> over eth0), then just use an initramfs that sets eth0 up and
>  Lennert> then runs a DHCP client on wan.
> 
> True. There are a few differences between vlans and dsa devices though,
> which might make us want to handle them differently:
> 
> - VLANs are configured at runtime from userspace, DSA devices are
>   configured directly in kernel code (E.G platform devices) - So by
>   definition you cannot use the autconfig / nfsroot stuff on VLANs as
>   they are not created before userspace runs, but DSA devices are
>   basically indistinguishable from "real" devices from the POV of
>   userspace.

Sure.  That doesn't change the argument, though.  In fact, in most
situations, you'll e.g. want to bridge the lan[1-4] interfaces
together, and if you then want to DHCP over that bridge, you cannot
explain that to the kernel autoconfigurator either.


> - VLANs relation to their upstream ethernet device is clearly visible
>   (E.G through brctl), whereas the details about what interface a DSA
>   switch is connected to isn't.

commit c084080151e1de92159f8437fde34b6e5bebe35e
Author: Lennert Buytenhek <buytenh@...tstofly.org>
Date:   Fri Mar 20 09:49:49 2009 +0000

    dsa: set ->iflink on slave interfaces to the ifindex of the parent
    
    ..so that we can parse the DSA topology from 'ip link' output:
    
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    4: lan1@...0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    5: lan2@...0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    6: lan3@...0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    7: lan4@...0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    
    Signed-off-by: Lennert Buytenhek <buytenh@...vell.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>


cheers,
Lennert
--
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