linux-kernel - Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force

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: <CAD=FV=UHiwjt2a8GFZKG3ZrRfjTgQDWD_mZu_qZP7Ve-HNTMYg@mail.gmail.com>
Date:   Tue, 20 Nov 2018 08:04:57 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Evan Green <evgreen@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>, digetx@...il.com,
        ryandcase@...omium.org, David Collins <collinsd@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()

Hi,

On Tue, Nov 20, 2018 at 7:55 AM Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Nov 19, 2018 at 04:26:54PM -0800, Douglas Anderson wrote:
> > In regulator_force_disable() there was a strange loop that looked like:
> >
> >   while (rdev->open_count--)
> >     regulator_disable(rdev->supply);
> >
> > I'm not totally sure what the goal was for this loop, but it seems
> > wrong to me.  If anything I think maybe we should have been looping
> > over our use_count, but even that might be a little strange.  For now
> > let's just remove the code and we can add something back in if someone
> > can explain what's expected.
>
> This should be using use_count, what that loop is doing is dropping all
> the enables that the regulator being force disabled had propagated up
> all the enables it passed up the chain of supplies.

OK, that makes much more sense then.  I can adjust it to do that.
I'll wait to see what happens with the rest of the patches in this
series and then post up a v2 of this one.  The number of disables
needed depends on how many of the patches in my series you like.  ;-)

In general it's hard for me to reason about how the system in general
should behave after regulator_force_disable() is called.  Is it
basically expected that the system will panic soon after?
Specifically other consumers of the same regulator will think it's on
but it won't actually be on.  What should happen if one of those other
consumers calls disable/enable?  Should the regulator turn back on?
...or is the regulator permanently off until the system reboots?

-Doug