linux-kernel - Re: [PATCH 0/2] PCI/PM: Elevate PM usage during reset probing

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: <20250423211055.GA455833@bhelgaas>
Date: Wed, 23 Apr 2025 16:10:55 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: bhelgaas@...gle.com, rafael@...nel.org, linux-pci@...r.kernel.org,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] PCI/PM: Elevate PM usage during reset probing

On Tue, Apr 22, 2025 at 05:05:30PM -0600, Alex Williamson wrote:
> I encountered a confusing scenario where a device reports NoSoftRst- and
> doesn't have any associated quirks to set PCI_DEV_FLAGS_NO_PM_RESET, but
> it refuses to probe for PM reset support using the sysfs reset_method
> attribute.  The reason turns out to be that we don't increment the usage
> count while probing, the driver has the device in D3, where this system
> seems to support D3cold, and the PM control register is read back as
> 0xffff.
> 
> The cleanup __free helper seems to be the cleanest solution here, versus
> refactoring to a common exit point or wrappers around reset_fn, but feel
> free to suggest otherwise.  I see a couple potential other use cases for
> this helper in the vfio code.
> 
> Please review.  Thanks,
> 
> Alex
> 
> Alex Williamson (2):
>   PM: runtime: Define pm_runtime_put cleanup helper
>   PCI: Increment PM usage counter when probing reset methods
> 
>  drivers/pci/pci-sysfs.c    | 3 +++
>  include/linux/pm_runtime.h | 2 ++
>  2 files changed, 5 insertions(+)

Applied to pci/pm for v6.16, thanks, Alex!