netdev - Re: [PATCH net-next] net: ipconfig: allow IP-Config over DSA devices

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: <CAGVrzcbu6vCKDdDuz+aPCxFGL3rhSREugb17Y_sAzSLmg9Jvaw@mail.gmail.com>
Date:	Thu, 5 Jun 2014 10:47:15 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev <netdev@...r.kernel.org>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	Jiří Pírko <jiri@...nulli.us>
Subject: Re: [PATCH net-next] net: ipconfig: allow IP-Config over DSA devices

2014-06-05 0:01 GMT-07:00 David Miller <davem@...emloft.net>:
> From: Florian Fainelli <f.fainelli@...il.com>
> Date: Fri, 30 May 2014 11:08:45 -0700
>
>> Let me know your thoughts. If you feel like something like:
>> netdev_is_upper_dev() or something like that is better.
>
> I'm not happy with this change for several reasons.
>
> First, I don't like the idea that ipconfig works for some stacked
> devices and not for others.

Right, although as I described DSA devices are likely to be the only
real kernel-only created devices here, other stacked devices such as
bonds, vlans and tunnels for instance do require either kernel
modifications to be created by the kernel, or user-space.

>  I'd rather that we simply accept that
> direct devices are the only thing supported.

Would you be willing to revise this position if we can come up with a
generic infrastructure for telling whether a network device depends on
another one and its master device needs to be opened first? Should we
instead force the slave devices in net/dsa/slave.c to open its master
device if it is not UP?

>
> Secondly, the logic in that ipconfig loop is so confusing.  I can't
> even figure out what that dsa pointer test is trying to really
> accomplish in the second hunk of your patch.
>
> I'd like to defer this for now, sorry.

Thanks for your comments.
-- 
Florian
--
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