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:	Tue, 15 Feb 2011 15:58:52 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	Ivan Vecera <ivecera@...hat.com>, netdev@...r.kernel.org,
	davem@...emloft.net, aabdulla@...dia.com,
	Ben Hutchings <ben@...adent.org.uk>
Subject: Re: [PATCH] drivers/net: Call netif_carrier_off at the end of the
 probe

On Tue, 2011-02-15 at 16:22 +0100, Francois Romieu wrote:
> Ivan Vecera <ivecera@...hat.com> :
> > Without calling of netif_carrier_off at the end of the probe the operstate
> > is unknown when the device is initially opened. By default the carrier is
> > on so when the device is opened and netif_carrier_on is called the link
> > watch event is not fired and operstate remains zero (unknown).
> 
> Stated this way it sounds like a core dev layer issue.

Due to hardware limitations, some network drivers cannot report the
carrier state and they never call netif_carrier_{on,off}().  Therefore
the initial operstate of 'unknown' is correct.

> I am not completely sure after reading some history. Namely:
> - (37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71 ?)
> - c276e098d3ee33059b4a1c747354226cec58487c 
> - 22604c866889c4b2e12b73cbf1683bda1b72a313
> - b47300168e770b60ab96c8924854c3b0eb4260eb
> 
> I am confused.

Drivers that can report carrier state should do so initially some time
between registering a device and bringing it up (either in the bus probe
function or the ndo_open function).  It generally seems to be safe to
assume that the link is down initially, and then to rely on
notifications from the hardware.  However, that does depend on the
behaviour of the hardware.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ