linux-kernel - Re: [git patches] net driver fixes

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 Sep 2007 12:19:32 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Dan Williams <dcbw@...hat.com>
cc:	Jeff Garzik <jeff@...zik.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	netdev@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git patches] net driver fixes 

Dan Williams <dcbw@...hat.com> wrote:
[...]
>I admit that I probably don't understand the system architecture of
>where ehea would be used, but would this
>cause /sys/class/net/ethX/carrier to be TRUE even if the device has no
>carrier?  That seems quite wrong IMHO.  When does ehea not have a
>carrier?  And in that case, does sysfs say 1 or 0 for the carrier?

	I don't work on ehea, but I'm generally familiar with it, and
particularly with this patch.

	The usual environment for ehea devices is on large systems
subdivided into multiple logical partitions.  One ehea device serves
many partitions.  By having ehea always report "link up" to the logical
ports (the ports seen by the partitions), the partitions can communicate
amongst themselves even if the external ports (the ports that go to the
switch or whatever) have no link.  

	The ehea device, more or less, acts as a switch connecting the
partitions together.  This switch type of functionality is not dependent
upon the link state of the external ports (any more than the
functionality of any switch is dependent upon whether or not it is
connected to a gateway).

	This, if I'm not mistaken, is the way ehea has always operated
until this particular patch was added.

	This patch (to optionally pass carrier state to the logical
ports) was added largely for bonding, so that the bonding driver can
detect link failures on the external ports (when so desired).  The
default behavior remains the original behavior, i.e., do not pass
external port link state to the logical ports.

	Anyway, to answer your question, the carrier state reported for
the ehea interface on the partition will always be true.  Think of it as
reporting the link state from the logical interface to the "switch" that
connects the partitions; that link exists only within the ehea device
itself, and really can't fail unless the ehea device itself fails.

	With the new option enabled, then ehea is more or less mimicing
a trunk failover type of function, and passing the carrier state of the
"external switch port" to the internal port.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/