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  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 <>
To:	Dan Williams <>
cc:	Jeff Garzik <>,
	Andrew Morton <>,
	Linus Torvalds <>,, LKML <>
Subject: Re: [git patches] net driver fixes 

Dan Williams <> 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.


	-Jay Vosburgh, IBM Linux Technology Center,
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists