netdev - Re: [patch net-next 0/4] net: allow to change carrier from userspace

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Dec 2012 08:12:01 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Flavio Leitner <fbl@...hat.com>,
	John Fastabend <john.fastabend@...il.com>,
	netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	bhutchings@...arflare.com, mirqus@...il.com,
	greearb@...delatech.com
Subject: Re: [patch net-next 0/4] net: allow to change carrier from
 userspace

On Fri, 14 Dec 2012 15:41:34 +0100
Jiri Pirko <jiri@...nulli.us> wrote:

> Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@...tta.com wrote:
> >On Thu, 13 Dec 2012 16:17:33 -0200
> >Flavio Leitner <fbl@...hat.com> wrote:
> >
> >> On Thu, 13 Dec 2012 10:09:33 -0800
> >> Stephen Hemminger <shemminger@...tta.com> wrote:
> >> 
> >> > On Thu, 13 Dec 2012 15:54:23 -0200
> >> > Flavio Leitner <fbl@...hat.com> wrote:
> >> > 
> >> > > I am saying this because people are used to and there are scripts out
> >> > > there using something like:
> >> > > # ethtool <iface> | grep 'Link'
> >> > > to react an interface failure.
> >> > 
> >> > Then the script is broken. It is asking about hardware state.
> >> 
> >> I was talking about the team master interface, so it makes sense
> >> to check its 'hardware' state. Just think on 'bond0' interface
> >> with no slaves. It should report Link detected: no.
> >> 
> >> See bond_release(), what happens if bond->slave_cnt == 0, for instance.
> >> 
> >
> >I was thinking more that ethtool operation for reporting link on
> >the team device should use the proper check rather than just using netif_carrier_ok(),
> >the team ethtool operation for get_link should be check IFF_RUNNING flag
> >in dev->flags which is controlled by operstate transistions.
> 
> I admit I'm bit confused now.
> 
> For example in bridge code:
> in br_add_if() - netif_carrier_ok() is checked and by the value it is
> decided if br_stp_enable_port() is called or not. Wouldn't it make more
> sense to check IFF_RUNNING (or netif_oper_up()) here?
> 
> The reason I'm asing is that if team device is in bridge, carrier is
> always ON and I'm fiddling with IF_OPER_UP and IF_OPER_DORMANT from
> userspace, in current code, bridge wouldn't know the difference...
> 
> There are more exmaples of similar usage of netif_carrier_ok() in
> bridge (called on ports), bonding (called on slaves), team code (called on ports).

Yes the bridge should be fixed to work with user controlled devices.
--
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