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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YvtzJw3jmocM0JFi@sirena.org.uk>
Date:   Tue, 16 Aug 2022 11:36:23 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        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@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>,
        linux-amlogic@...ts.infradead.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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-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@...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@...r.kernel.org
Subject: Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable

On Tue, Aug 16, 2022 at 07:56:06AM +0300, Matti Vaittinen wrote:
> On 8/16/22 01:55, Mark Brown wrote:
> > On Tue, Aug 16, 2022 at 12:17:17AM +0300, Laurent Pinchart wrote:

> > > 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.

> I think this is going a bit "off-topic" but I'd like to understand what is
> behind this statement? From device-writer's perspective - I don't know much
> better alternatives to free up the memory. I don't see how freeing stuff at
> .remove would be any better? As far as I understand - if someone is using
> driver's resources after the device has gone and the driver is detached,
> then there is not much the driver could do to free-up the stuff be it devm
> or not? This sounds like fundamentally different problem (to me).

If a driver has done something like create a file that's accessible to
userspace then that file may be held open by userspace even after the
device goes away, the driver that created the file needs to ensure that
any storage that's used by the file remains allocated until the file is
also freed (typically this is data specific to the file rather than the
full device data).  Similar situations can exist elsewhere, that's just
the common case.  There'll be a deletion callback on whatever other
object causes the problem, the allocation needs to be reference counted
against both the the device and whatever other users there might be.

> > That's a different conversation, and a totally
> > valid one especially when you start looking at things like implementing
> > userspace APIs which need to cope with hardware going away while still
> > visible to userspace.

> This is interesting. It's not easy for me to spot how devm changes things
> here? If we consider some removable device - then I guess also the .remove()
> is ran only after HW has already gone? Yes, devm might make the time window
> when userspace can see hardware that has gone longer but does it bring any
> new problem there? It seems to me devm can make hitting the spot more likely
> - but I don't think it brings completely new issues? (Well, I may be wrong
> here - wouldn't be the first time :])

See above, something can still know the device was there even after it's
gone.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)