linux-kernel - RE: [PATCH] regulator: core: fix error path for regulator_set_voltage

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: <VI1PR10MB2352D4EA677EEEA246BAFC16FE470@VI1PR10MB2352.EURPRD10.PROD.OUTLOOK.COM>
Date:   Mon, 18 Mar 2019 16:11:58 +0000
From:   Steve Twiss <stwiss.opensource@...semi.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>
CC:     LKML <linux-kernel@...r.kernel.org>,
        Maciej Purski <m.purski@...subg.com>,
        Support Opensource <Support.Opensource@...semi.com>
Subject: RE: [PATCH] regulator: core: fix error path for
 regulator_set_voltage_unlocked

Hi Dmitry,

Thanks,

On 18 March 2019 16:03, Dmitry Osipenko wrote:

> Subject: Re: [PATCH] regulator: core: fix error path for
> regulator_set_voltage_unlocked
> 
> 18.03.2019 18:32, Steve Twiss пишет:
> > During several error paths in the function
> > regulator_set_voltage_unlocked() the value of 'ret' can take on negative
> > error values. However, in calls that go through the 'goto out' statement,
> > this return value is lost and return 0 is used instead, indicating a
> > 'pass'.
> >
> > There are several cases where this function should legitimately return a
> > fail instead of a pass: one such case includes constraints check during
> > voltage selection in the call to regulator_check_voltage(), which can
> > have -EINVAL for the case when an unsupported voltage is incorrectly
> > requested. In that case, -22 is expected as the return value, not 0.
> >
> > Fixes: 9243a195be7a ("regulator: core: Change voltage setting path")
> > Signed-off-by: Steve Twiss <stwiss.opensource@...semi.com>
> > ---
> >  drivers/regulator/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 68473d0..caf8743 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -3326,7 +3326,7 @@ static int regulator_set_voltage_unlocked(struct
> regulator *regulator,
> >  		goto out2;
> >
> >  out:
> > -	return 0;
> > +	return ret;
> >  out2:
> >  	voltage->min_uV = old_min_uV;
> >  	voltage->max_uV = old_max_uV;
> >
> 
> Looks like a good catch.
> 
> Probably will be a bit better to write this as:
> 
>         /* for not coupled regulators this will just set the voltage */
>         ret = regulator_balance_voltage(rdev, state);
> -       if (ret < 0)
> -               goto out2;
> -
> +       if (ret < 0) {
> +               voltage->min_uV = old_min_uV;
> +               voltage->max_uV = old_max_uV;
> +       }
>  out:
> -       return 0;
> -out2:
> -       voltage->min_uV = old_min_uV;
> -       voltage->max_uV = old_max_uV;
> -
>         return ret;
>  }

I've just had a very similar conversation with Adam Thomson who sits near me and also 
said the two gotos make it look confusing.

Honestly -- I wasn't convinced because it looked obvious to me, but you are the second
person to say it .. 
CC: Adam Thomson

So, ok. Agreed. :)
I'll make the change and resend.

Regards,
Steve