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:   Tue, 26 May 2020 13:14:06 +0800 (GMT+08:00)
From:   dinghao.liu@....edu.cn
To:     "Linus Walleij" <linus.walleij@...aro.org>
Cc:     "Kangjie Lu" <kjlu@....edu>, "Jonathan Cameron" <jic23@...nel.org>,
        "Hartmut Knaack" <knaack.h@....de>,
        "Lars-Peter Clausen" <lars@...afoo.de>,
        "Peter Meerwald-Stadler" <pmeerw@...erw.net>,
        linux-iio <linux-iio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH] iio: magnetometer: ak8974: Fix runtime PM imbalance
 on error

Hi, Linus

> On Sun, May 24, 2020 at 4:51 AM Dinghao Liu <dinghao.liu@....edu.cn> wrote:
> 
> > When devm_regmap_init_i2c() returns an error code, a pairing
> > runtime PM usage counter decrement is needed to keep the
> > counter balanced. For error paths after ak8974_set_power(),
> > ak8974_detect() and ak8974_reset(), things are the same.
> >
> > However, When iio_triggered_buffer_setup() returns an error
> > code, we don't need such a decrement because there is already
> > one before this call. Things are the same for other error paths
> > after it.
> >
> > Signed-off-by: Dinghao Liu <dinghao.liu@....edu.cn>
> 
> >         ak8974->map = devm_regmap_init_i2c(i2c, &ak8974_regmap_config);
> >         if (IS_ERR(ak8974->map)) {
> >                 dev_err(&i2c->dev, "failed to allocate register map\n");
> > +               pm_runtime_put_noidle(&i2c->dev);
> > +               pm_runtime_disable(&i2c->dev);
> >                 return PTR_ERR(ak8974->map);
> 
> This is correct.
> 
> >         ret = ak8974_set_power(ak8974, AK8974_PWR_ON);
> >         if (ret) {
> >                 dev_err(&i2c->dev, "could not power on\n");
> > +               pm_runtime_put_noidle(&i2c->dev);
> > +               pm_runtime_disable(&i2c->dev);
> >                 goto power_off;
> 
> What about just changing this to goto disable_pm;
>
> >         ret = ak8974_detect(ak8974);
> >         if (ret) {
> >                 dev_err(&i2c->dev, "neither AK8974 nor AMI30x found\n");
> > +               pm_runtime_put_noidle(&i2c->dev);
> > +               pm_runtime_disable(&i2c->dev);
> >                 goto power_off;
> 
> goto disable_pm;
> 
> > @@ -786,6 +792,8 @@ static int ak8974_probe(struct i2c_client *i2c,
> >         ret = ak8974_reset(ak8974);
> >         if (ret) {
> >                 dev_err(&i2c->dev, "AK8974 reset failed\n");
> > +               pm_runtime_put_noidle(&i2c->dev);
> > +               pm_runtime_disable(&i2c->dev);
> 
> goto disable_pm;
> 
> >  disable_pm:
> > -       pm_runtime_put_noidle(&i2c->dev);
> >         pm_runtime_disable(&i2c->dev);
> >         ak8974_set_power(ak8974, AK8974_PWR_OFF);
> 
> Keep the top pm_runtime_put_noidle().

I found that there was already a pm_runtime_put() before 
iio_triggered_buffer_setup() (just after pm_runtime_use_autosuspend).
So if we keep the pm_runtime_put_noidle() here, we will have
two pmusage counter decrement. Do you think this is a bug?

Regards,
Dinghao

> 
> The ak8974_set_power() call is fine, the power on call does not
> need to happen in balance. Sure it will attempt to write a register
> but so will the power on call.
> 
> Yours,
> Linus Walleij

Powered by blists - more mailing lists