linux-kernel - Re: PM runtime_error handling missing in many drivers?

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, 26 Jul 2022 11:05:32 +0200
From:   Oliver Neukum <oneukum@...e.com>
To:     "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Vincent Whitchurch <vincent.whitchurch@...s.com>,
        Oliver Neukum <oneukum@...e.com>
Cc:     "jic23@...nel.org" <jic23@...nel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: PM runtime_error handling missing in many drivers?

On 08.07.22 22:10, Rafael J. Wysocki wrote:
> On 7/8/2022 1:03 PM, Vincent Whitchurch wrote:

>> Perhaps Rafael can shed some light on this.
> 
> The driver always knows more than the framework about the device's
> actual state.  The framework only knows that something failed, but it
> doesn't know what it was and what way it failed.

Hi,

thinking long and deeply about this I do not think that this seemingly
obvious assertion is actually correct.

> The idea was that drivers would clear these errors.

I am afraid that is a deeply hidden layering violation. Yes, a driver's
resume() method may have failed. In that case, if that is the same
driver, it will obviously already know about the failure.

PM operations, however, are operating on a tree. A driver requesting
a resume may get an error code. But it has no idea where this error
comes from. The generic code knows at least that.

Let's look at at a USB storage device. The request to resume comes
from sd.c. sd.c is certainly not equipped to handle a PCI error
condition that has prevented a USB host controller from resuming.

I am afraid this part of the API has issues. And they keep growing
the more we divorce the device driver from the bus driver, which
actually does the PM operation.

	Regards
		Oliver