linux-kernel - Re: [PATCH v1 2/3] PCI/sysfs: Use PM runtime class macro for auto cleanup in reset_method

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: <68d6d7dbd18b4_10520100c8@dwillia2-mobl4.notmuch>
Date: Fri, 26 Sep 2025 11:13:47 -0700
From: <dan.j.williams@...el.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Jonathan Cameron
	<jonathan.cameron@...wei.com>
CC: "Rafael J. Wysocki" <rafael@...nel.org>, Linux PM
	<linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Linux PCI
	<linux-pci@...r.kernel.org>, Alex Williamson <alex.williamson@...hat.com>,
	Bjorn Helgaas <helgaas@...nel.org>, Takashi Iwai <tiwai@...e.de>, "Zhang
 Qilong" <zhangqilong3@...wei.com>, Ulf Hansson <ulf.hansson@...aro.org>, "Dan
 Williams" <dan.j.williams@...el.com>
Subject: Re: [PATCH v1 2/3] PCI/sysfs: Use PM runtime class macro for auto
 cleanup in reset_method_store()

Rafael J. Wysocki wrote:
> On Fri, Sep 26, 2025 at 3:49 PM Jonathan Cameron
> <jonathan.cameron@...wei.com> wrote:
> >
> > On Fri, 19 Sep 2025 18:38:42 +0200
> > "Rafael J. Wysocki" <rafael@...nel.org> wrote:
> >
> > > From: Takashi Iwai <tiwai@...e.de>
> > >
> > > The newly introduced class macro can simplify the code.
> > >
> > > Also, add the proper error handling for the PM runtime get.
> > >
> > > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> > > [ rjw: Adjust subject and error handling ]
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > ---
> > >  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;
> > > +     CLASS(pm_runtime_resume_and_get, pmdev)(dev);
> > > +     if (IS_ERR(pmdev))
> > > +             return -ENXIO;
> > Hi Rafael,
> >
> > Why this approach rather than treating runtime pm state like a conditional
> > lock (we use it much like one) and using ACQUIRE() / ACQUIRE_ERR()?
> 
> Mostly because devices are not locks.
> 
> > Ultimately that's a wrapper around the same infrastructure but
> > perhaps neater as it removes need to have that explicit magic pmdev.
> 
> You'll need to have a magic pmdev or similar regardless IIUC.
> 
> Say there is
> 
> DEFINE_GUARD(pm_runtime_active, struct device *,
> pm_runtime_get_sync(_T), pm_runtime_put(_T))
> DEFINE_GUARD_COND(pm_runtime_active, _try, pm_runtime_resume_and_get(_T))
> 
> so the user of this will do
> 
> ACQUIRE(pm_runtime_active_try, pm)(dev);
> if (ACQUIRE_ERR(pm_runtime_active_try, &pm))
>         return -ENXIO;

FWIW this looks better to me than the open-coded CLASS(). The pattern,
admittedly coding-style bending, we are using in drivers/cxl/ for
compactness and error code fidelity is:

   ACQUIRE(pm_runtime_active_try, pm)(dev);
   if ((ret = ACQUIRE_ERR(pm_runtime_active_try, &pm)))
           return ret;

> and there's a "magic" pm though pm is not a struct device pointer.
> 
> Maybe it's nicer.  I guess people may be more used to dealing with int
> error variables.
> 
> Let me try this and see how far I can get with this.
> 
> > +CC Dan as he can probably remember the discussions around ACQUIRE()
> > vs the way you have here better than I can.

Yes, effectively a new open-coded CLASS() prompted the ACQUIRE()
proposal [1]. This pm-active-state reference management indeed looks
more like a guard() of the active state than an object constructor
auto-unwind-on-error case.

[1]: http://lore.kernel.org/20250507072145.3614298-1-dan.j.williams@intel.com