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]
Date:	Tue, 18 Dec 2012 10:31:41 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	bhutchings@...arflare.com, mirqus@...il.com,
	greearb@...delatech.com, fbl@...hat.com
Subject: Re: [patch net-next 0/4] net: allow to change carrier from userspace

Tue, Dec 18, 2012 at 07:49:57AM CET, shemminger@...tta.com wrote:
>On Sun, 16 Dec 2012 11:54:51 +0100
>Jiri Pirko <jiri@...nulli.us> wrote:
>
>> 
>> I see that the patchset is in state "Rejected" in patchwork.
>> Stephen convinced me for a moment that the problem can be handled by operstate.
>> As it turned out (in last 3-4 emails in thread) operstate use would not
>> be an option.
>> 
>> So how should I proceed? Should I repost the patchset? Anyone has any other
>> comments?
>> 
>> thanks.
>
>Don't take my comments so far as negative. Devices to need to be more controllable
>from userspace. But I have concerns about introducing a new way to change state causing
>more races.  For example, changing carrier state should cause netlink events to fire and
>these should post to routing daemons etc. Also, what happens if some confused developer
>mixes operstate and direct carrier control.

I do not think that the race you are describing is of any concern. The
same can happen now for any device. My patchset only adds a possibility
for "soft devices" to change the carrier as well.

Developer will not be likely confused. As the possibility of carrier
change from userspace will be limited to small set of devices, for other
devices the attempt will lead to -EOPNOTSUPP (in contrast with operstate
which is available for all devices).

I can add a comments/notes to code and operstates.txt stating the
purpose of this iface.

>
>The root cause of all this confusion is that their are three ways of expressing
>the same state, and they are controlled through different paths:
>  a. Old BSD style flag bit IFF_RUNNING
>  b. LINK_STATE bit in kernel (netif_carrier_ok)
>  c. RFC2863 operational state

I do not think so. Yes, for a) and c), these are strictly connected,
expressing the same thing. But b) is not the same. It's on lower level
than a) and c). What b) can be compared to is IFF_LOWER_UP.

>
>The operstate stuff is the most complete, but is the weakest in implementation:
>  a. kernel drivers check netif_carrier_ok when they should be using netif_dormant
>     (bridge is one example). But what will break if this changes?
I agree, that should be changed.

>  b. lower device state is not tracked correctly by tunnels and a few other layered devices
>  c. dormant from kernel space was never used by much.
>
>The good news is that the old BSD style IFF_RUNNING bit is the most commonly
>used bit by applications and it works correctly in either carrier or operstate mode.

That is indeed a good thing.

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

Powered by blists - more mailing lists