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: <CAJZ5v0iC-Lz59iu+5Ps-T9W5Ow__pm_0-txF2mDERypPFQYFsw@mail.gmail.com>
Date: Tue, 21 Oct 2025 14:44:59 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Farhan Ali <alifm@...ux.ibm.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linux PM <linux-pm@...r.kernel.org>, 
	Jonathan Cameron <jonathan.cameron@...wei.com>, Bjorn Helgaas <helgaas@...nel.org>, 
	Takashi Iwai <tiwai@...e.de>, LKML <linux-kernel@...r.kernel.org>, 
	Linux PCI <linux-pci@...r.kernel.org>, Alex Williamson <alex.williamson@...hat.com>, 
	Zhang Qilong <zhangqilong3@...wei.com>, Ulf Hansson <ulf.hansson@...aro.org>, 
	Frank Li <Frank.Li@....com>, Dhruva Gole <d-gole@...com>, 
	Niklas Schnelle <schnelle@...ux.ibm.com>
Subject: Re: [PATCH v4 2/3] PCI/sysfs: Use runtime PM guard macro for auto-cleanup

On Tue, Oct 21, 2025 at 12:07 AM Farhan Ali <alifm@...ux.ibm.com> wrote:
>
>
> On 9/26/2025 9:24 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > Use the newly introduced pm_runtime_active_try guard to simplify
> > the code and add the proper error handling for PM runtime resume
> > errors.
> >
> > Based on an earlier patch from Takashi Iwai <tiwai@...e.de> [1].
> >
> > Link: https://patch.msgid.link/20250919163147.4743-3-tiwai@suse.de [1]
> > Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> >
> > v3 -> v4:
> >     * Use ACQUIRE()/ACQUIRE_ERR() (Jonathan)
> >     * Adjust subject and changelog
> >     * Take patch ownership (it's all different now)
> >     * Pick up Bjorn's ACK from v3 (Bjorn, please let me know if that's not OK)
> >
> > v2 -> v3: No changes
> >
> > v1 -> v2:
> >     * Adjust the name of the class to handle the disabled runtime PM case
> >       transparently (like the original code).
> >
> > ---
> >   drivers/pci/pci-sysfs.c |    5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -1475,8 +1475,9 @@ static ssize_t reset_method_store(struct
> >               return count;
> >       }
> >
> > -     pm_runtime_get_sync(dev);
> > -     struct device *pmdev __free(pm_runtime_put) = dev;
> > +     ACQUIRE(pm_runtime_active_try, pm)(dev);
> > +     if (ACQUIRE_ERR(pm_runtime_active_try, &pm))
> > +             return -ENXIO;
> >
> >       if (sysfs_streq(buf, "default")) {
> >               pci_init_reset_methods(pdev);
> >
> >
> Hi Rafael,
>
> This patch breaks updating the 'reset_method' sysfs file on s390. If we
> try to update the reset_method, we are hitting the ENXIO error. eg:
>
> echo 'bus' > /sys/bus/pci/devices/0007\:00\:10.1/reset_method
> -bash: echo: write error: No such device or address
>
> I don't think s390 does anything different in this path, so this could
> also impact other platforms? Changing this to something like this fixes it
>
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 9d6f74bd95f8..d7fc0dc81c30 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1517,8 +1517,8 @@ static ssize_t reset_method_store(struct device *dev,
>                  return count;
>          }
>
> -       ACQUIRE(pm_runtime_active_try, pm)(dev);
> -       if (ACQUIRE_ERR(pm_runtime_active_try, &pm))
> +       ACQUIRE(pm_runtime_active, pm)(dev);
> +       if (ACQUIRE_ERR(pm_runtime_active, &pm))
>                  return -ENXIO;
>
> This changes the logic to what it was previously which used
> pm_runtime_get_sync and pm_runtime_put. But I am not familiar with the
> PM runtime code, so not sure what would be the right fix here.

Can you please check if this helps:

https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ