linux-kernel - Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VefRphjAhSmrUVC8aaAhrwMD+9Jr=OROFU-0JuNhuFYDw@mail.gmail.com>
Date:   Tue, 16 Aug 2022 11:42:20 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Stephen Boyd <sboyd@...nel.org>, Mark Brown <broonie@...nel.org>,
        Matti Vaittinen <mazziesaccount@...il.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Kevin Hilman <khilman@...libre.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Daniel Vetter <daniel@...ll.ch>,
        linux-amlogic <linux-amlogic@...ts.infradead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Documentation List <linux-doc@...r.kernel.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Michael Hennerich <Michael.Hennerich@...log.com>,
        Miaoqian Lin <linmq006@...il.com>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Alexandru Tachici <alexandru.tachici@...log.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Jonathan Corbet <corbet@....net>,
        Guenter Roeck <linux@...ck-us.net>,
        Jonas Karlman <jonas@...boo.se>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Michael Turq uette <mturquette@...libre.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Jean Delvare <jdelvare@...e.com>,
        Alexandru Ardelean <aardelean@...iqon.com>,
        linux-hwmon@...r.kernel.org, linux-clk <linux-clk@...r.kernel.org>,
        Nuno Sá <nuno.sa@...log.com>,
        Robert Foss <robert.foss@...aro.org>,
        Aswath Govindraju <a-govindraju@...com>,
        David Airlie <airlied@...ux.ie>,
        linux-iio <linux-iio@...r.kernel.org>
Subject: Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable

On Tue, Aug 16, 2022 at 8:37 AM Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:
> On Mon, Aug 15, 2022 at 01:58:55PM -0700, Stephen Boyd wrote:
> > Quoting Laurent Pinchart (2022-08-15 11:52:36)
> > > On Mon, Aug 15, 2022 at 05:33:06PM +0100, Mark Brown wrote:

...

> > > we'll run into trouble. Supplying active high input signals
> > > to a device that is not powered can lead to latch-up, which tends to
> > > only manifest after a statistically significant number of occurrences of
> > > the condition, and can slowly damage the hardware over time. This is a
> > > real concern as it will typically not be caught during early
> > > development. I think we would still be better off with requiring drivers
> > > to manually handle powering off the device until we provide a mechanism
> > > that can do so safely in an automated way.
> >
> > Can you describe the error scenario further? I think it's driver author
> > error that would lead to getting and enabling the regulator after
> > getting and enabling a clk that drives out a clock signal on some pins
> > that aren't powered yet. I'm not sure that's all that much easier to do
> > with these sorts of devm APIs, but if it is then I'm concerned.
>
> You will very quickly see drivers doing this (either directly or
> indirectly):
>
> probe()
> {
>         devm_clk_get_enabled();
>         devm_regulator_get_enable();
> }

And how is it devm specific? If the author puts the same without devm
the ordering would be wrong, correct? devm allows us to focus on
ordering in a *single* place, which is a win. You seem to be proposing
to make a high burden on a driver's author to focus on ordering in the
*three* places. I disagree with that. Yet the driver author has to
understand many issues with any tool they use. So the root cause of
your whining is rather on the edge of documentation and education.
(Yes, I have heard about issues with object lifetime in v4l2
subdevices regarding to devm, but it seems irrelevant to devm
mechanism itself.)

> Without a devres-based get+enable API drivers can get the resources they
> need in any order, possibly moving some of those resource acquisition
> operations to different functions, and then have a clear block of code
> that enables the resources in the right order. These devres helpers give
> a false sense of security to driver authors and they will end up
> introducing problems, the same way that devm_kzalloc() makes it
> outrageously easy to crash the kernel by disconnecting a device that is
> in use.



-- 
With Best Regards,
Andy Shevchenko