linux-kernel - Re: [PATCH] driver core: Ensure proper suspend/resume ordering

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: <CAJZ5v0ip4yOWxYXy6Qq8xViTYWvFvHOHcjjDAc-2Aj75rkfjcw@mail.gmail.com>
Date:	Tue, 15 Sep 2015 02:40:22 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Thierry Reding <thierry.reding@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] driver core: Ensure proper suspend/resume ordering

Hi Alan,

On Sat, Sep 12, 2015 at 7:40 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Sat, 12 Sep 2015, Rafael J. Wysocki wrote:
>
>> On Friday, September 11, 2015 03:01:14 PM Alan Stern wrote:
>
>> > There's also an issue about other types of dependencies.  For instance,
>> > it's conceivable that device B might be discovered and depend on device
>> > A, even before A has been bound to a driver.  (B might be discovered by
>> > A's subsystem rather than A's driver.)  In that case, moving A to the
>> > end of the list would cause B to come before A even though B depends on
>> > A.  Of course, deferred probing already has this problem.
>>
>> That may actually happen for PCIe ports and devices below them AFAICS.
>>
>> Devices below PCIe ports are discovered by the PCI subsystem and the PCIe
>> ports need not be probed before those devices are probed.
>
> Is it possible to change this?  Make it so that devices below PCIe
> ports are discovered by the port driver rather than by the PCI
> subsystem?  Or would that be far too difficult?

I don't think it would be really useful.

PCIe ports are PCI bridges from the resource allocation and basic
functionality perspective, so they are handled accordingly.

The PCIe port driver provides additional services (such as PME/hotplug
interrupt handling and advanced error reporting) that aren't necessary
for probing devices below the ports.

I guess the ordering of PCIe ports probing might be changed to happen
at the "right" time, but care needs to be taken in that case too.

>> > An easy way to check for this sort of thing would be to verify that a
>> > device about to be probed doesn't have any children.  This wouldn't
>> > catch all the potential dependencies, but it would be a reasonable
>> > start.
>>
>> That would address the PCIe ports issue.
>
> Well, it would _detect_ the PCIe ports issue.

That's what I meant. :-)

>  It might also detect other things.

Right.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/