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: <20121217224957.70775f99@nehalam.linuxnetplumber.net>
Date:	Mon, 17 Dec 2012 22:49:57 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Jiri Pirko <jiri@...nulli.us>
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

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.

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

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