linux-kernel - Re: [PATCH] ethtool: Report speed and duplex as unknown when device is runtime suspended

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] [day] [month] [year] [list]

Message-Id: <84A954EF-4DF6-4F1C-88CE-9B4C0D1ACE5B@canonical.com>
Date:   Fri, 27 Mar 2020 11:11:16 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>, kuba@...nel.org,
        alexander.duyck@...il.com,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Aaron Brown <aaron.f.brown@...el.com>,
        Michal Kubecek <mkubecek@...e.cz>,
        Andrew Lunn <andrew@...n.ch>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ethtool: Report speed and duplex as unknown when device
 is runtime suspended



> On Mar 27, 2020, at 10:56, Florian Fainelli <f.fainelli@...il.com> wrote:
> 
> 
> 
> On 3/26/2020 7:45 PM, Kai-Heng Feng wrote:
>> Device like igb gets runtime suspended when there's no link partner. We
>> can't get correct speed under that state:
>> $ cat /sys/class/net/enp3s0/speed
>> 1000
>> 
>> In addition to that, an error can also be spotted in dmesg:
>> [  385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost
>> 
>> Since device can only be runtime suspended when there's no link partner,
>> we can directly report the speed and duplex as unknown.
>> 
>> Cc: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
>> Cc: Aaron Brown <aaron.f.brown@...el.com>
>> Suggested-by: Alexander Duyck <alexander.duyck@...il.com>
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
> 
> I would push this to the responsibility of the various drivers instead
> of making this part of the standard ethtool implementation.

My original approach [1] is to ask device to runtime resume before calling __ethtool_get_link_ksettings().
Unfortunately it will cause a deadlock if the runtime resume routine wants to hold rtnl_lock.

However, it should be totally fine (and sometimes necessary) to be able to hold rtnl_lock in runtime resume routine as Alexander explained [2].
As suggested, this patch handles the situation directly in __ethtool_get_link_ksettings().

[1] https://lore.kernel.org/lkml/20200207101005.4454-2-kai.heng.feng@canonical.com/
[2] https://lkml.org/lkml/2020/3/26/989

Kai-Heng

> -- 
> Florian