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]

Message-ID: <20121214144134.GA1652@minipsycho.brq.redhat.com>
Date:	Fri, 14 Dec 2012 15:41:34 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Stephen Hemminger <shemminger@...tta.com>
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

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