netdev - Re: netif_device_present() and Runtime PM / PCI D3

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]

Date:   Tue, 2 Jun 2020 07:58:58 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: netif_device_present() and Runtime PM / PCI D3

On 31.05.2020 17:05, Andrew Lunn wrote:
> On Sun, May 31, 2020 at 02:07:46PM +0200, Heiner Kallweit wrote:
>> I just wonder about the semantics of netif_device_present().
>> If a device is in PCI D3 (e.g. being runtime-suspended), then it's
>> not accessible. So is it present or not?
>> The description of the function just mentions the obvious case that
>> the device has been removed from the system.
> 
> Hi Heiner
> 
> Looking at the code, there is no directly link to runtime suspend.  If
> the drivers suspend code has detached the device then it won't be
> present, but that tends to be not runtime PM, but WOL etc.
> 
Thanks, Andrew. To rephrase the question, should a driver always mark
the device as not present when it's not accessible, e.g. in PCI D3?
I think there are good reasons for it.

>> Related is the following regarding ethtool:
>> dev_ethtool() returns an error if device isn't marked as present.
>> If device is runtime-suspended and in PCI D3, then the driver
>> may still be able to provide quite some (cached) info about the
>> device. Same applies for settings: Even if device is sleeping,
>> the driver may store new settings and apply them once the device
>> is awake again.
> 
> I think playing with cached state of a device is going to be a sources
> of hard to find bugs. I would want to see a compelling use case for
> this.
> 
One example I'm aware of: r8169 allows to change WoL settings even if
device is in D3 (runtime-suspended after removing cable). Driver
stores new settings and updates device once it's resuming.

> 	Andrew
> 
Heiner