netdev - Re: [PATCH net-next v2 4/4] bonding: allow carrier and link status to determine link state

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: <20180516.131005.1506778995198859622.davem@davemloft.net>
Date:   Wed, 16 May 2018 13:10:05 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     dbanerje@...mai.com
Cc:     jay.vosburgh@...onical.com, netdev@...r.kernel.org,
        vfalico@...il.com, andy@...yhouse.net
Subject: Re: [PATCH net-next v2 4/4] bonding: allow carrier and link status
 to determine link state

From: "Banerjee, Debabrata" <dbanerje@...mai.com>
Date: Wed, 16 May 2018 16:54:40 +0000

> See output of /proc/net/bonding/bond0 below, same content as the
> prior email. bnx2x driver, on ith1: "MII Status: up" is directly
> from netif_carrier_ok(bond->dev) , but speed and duplex are unknown,
> which come from the same call as would be used from
> bond_mii_monitor(), __ethtool_get_link_ksettings(slave_dev,
> &ecmd). Yes it's possible this is because of bugs in the drivers
> themselves, but without being able to readily reproduce the state
> below we can't debug it, nor do we know which combination of
> hardware and drivers are reliable at any given point in time. We can
> say though that if this had been set to "both", ith1 would have been
> correctly removed from the bond. That said if this is still
> controversial I can resubmit the series without this patch.

Looking at the bnx2x driver, it's management of link state is very
convoluted.

The link parameters and the "link_up" state is maintained separately
from the values that are snapshot when the carrier is enabled.

I don't think we should reward drivers for behaving this way.

If the carrier is up, you should be able to provide the link speed and
duplex values immediately not some indeterminate amount of time later.