linux-kernel - Re: [PATCH 1/4] PCI: Check PCI_PM_CTRL in pci_dev

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: Wed, 19 Jun 2024 13:44:31 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Markus Elfring <Markus.Elfring@....de>, linux-pci@...r.kernel.org,
 linux-usb@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Mathias Nyman <mathias.nyman@...el.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Daniel Drake <drake@...lessos.org>,
 Gary Li <Gary.Li@....com>, Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 1/4] PCI: Check PCI_PM_CTRL in pci_dev_wait()

On 6/19/2024 13:33, Markus Elfring wrote:
>> A device that has gone through a reset may return a value in PCI_COMMAND
>> but that doesn't mean it's finished transitioning to D0.  On devices that
>> support power management explicitly check PCI_PM_CTRL to ensure the
>> transition happened.  Devicees that don't support power management will
> 
>                          Devices?

Yes, thanks.  I'll fix that up for the next version once we have some 
alignment on the functionality outlined in these patches.

> 
> 
>> continue to use PCI_COMMAND.
> 
> Would the tag “Fixes” be relevant for such a change description?
> 
> Regards,
> Markus

I did trace back the history of the wait function and it goes back to 
4.6.  In my mind yes; it is a fix, but I don't think it should go that 
far back automatically.  I think we should prioritize getting it fixed 
for 6.11 or 6.12 and then can revisit how far back to do a stable backport.

For example AMD Rembrandt (where this race condition was found) isn't 
enabled until 5.17 or 5.18 IIRC.

The backports would have a dependency on 08e3ed12ca861 (from 6.5-rc1) 
and bae26849372b8 (from 5.5-rc1) and 821cdad5c46ca (from 4.14) and 
5adecf817dd63 (from 4.6-rc1).