From: Jonathan Cameron <jic23@kernel.org>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
"Nuno Sá" <nuno.sa@analog.com>, dl-linux-imx <linux-imx@nxp.com>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
"linux-arm Mailing List" <linux-arm-kernel@lists.infradead.org>,
chrome-platform@lists.linux.dev,
"Lad Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 20/34] iio: inkern: only relase the device node when done with it
Date: Sat, 18 Jun 2022 15:13:58 +0100 [thread overview]
Message-ID: <20220618151358.44b78c11@jic23-huawei> (raw)
In-Reply-To: <5e81f73b996de80445c2e905c44ebb18c63a739b.camel@gmail.com>
On Mon, 13 Jun 2022 09:20:26 +0200
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Sat, 2022-06-11 at 15:59 +0100, Jonathan Cameron wrote:
> >
> > +Cc Mark Brown for a query on ordering in device tree based SPI
> > setup.
> >
> > On Fri, 10 Jun 2022 22:08:41 +0200
> > Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > > On Fri, 2022-06-10 at 16:56 +0200, Andy Shevchenko wrote:
> > > > On Fri, Jun 10, 2022 at 10:48 AM Nuno Sá <nuno.sa@analog.com>
> > > > wrote:
> > > > >
> > > > > 'of_node_put()' can potentially release the memory pointed to
> > > > > by
> > > > > 'iiospec.np' which would leave us with an invalid pointer (and
> > > > > we
> > > > > would
> > > > > still pass it in 'of_xlate()'). As such, we can only release
> > > > > the
> > > > > node
> > > > > after we are done with it.
> > > >
> > > > The question you should answer in the commit message is the
> > > > following:
> > > > "Can an OF node, attached to a struct device, be gone before the
> > > > device itself?" If it so, then patch is good, otherwise there is
> > > > no
> > > > point in this patch in the first place.
> > > >
> > >
> > > Yeah, I might be wrong but from a quick look... yes, I think the
> > > node
> > > can be gone before the device. Take a look on the spi or i2c
> > > of_notify
> > > handling and you can see that the nodes are get/put on the
> > > add/remove
> > > notifcation. Meaning that the node lifespan is not really attached
> > > to
> > > the device lifespan. If it was, I would expect to see of_node_put()
> > > on
> > > the device release() function...
> >
> > I had a look at spi_of_notify() and indeed via
> > spi_unregister_device()
> > the node is put just before device_del() so I agree that at first
> > glance
> > it seems like there may be a race there against the useage here.
> > Mark (+CC) out of interest why are the node gets before the
> > device_add()
> > in spi_add_device() called from of_register_spi_device() but the
> > matching
> > node puts before the device_del() in spi_unregister_device()?
> > Seems like inconsistent ordering...
> >
> > Which is not to say we shouldn't fix the IIO usage as this patch
> > does!
> >
>
> Just to add something that came to my attention. In the IIO case, it
> does not even matter if the parent device has the OF node lifetime
> "linked" to it (as it actually happens for platform devices). The
> reason is that iio_dev only has a weak reference to it's parent and (I
> think) the parent can actually go away while the iio_dev is still
> around (eg: someone has an open fd to the iio_dev cdev).
>
> > >
> > > Again, I might be wrong and I admit I was not sure about including
> > > this
> > > patch because it's a very unlikely scenario even though I think, in
> > > theory, a possible one.
> >
> > The patch is currently valid even if it's not a 'real' bug.
> > Given we are doing a put on that device_node, it makes sense for that
> > to occur after the local use has finished - we shouldn't be relying
> > on
> > what happens to be the case for lifetimes today.
> >
> > Now, I did wonder if any drivers actually use it in their xlate
> > callbacks.
> > One does for an error print, so this is potentially real (if very
> > unlikely!)
> >
> > This isn't a 'fix' I'd expect to rush in, or necessarily backport to
> > stable
> > but I think it's a valid fix.
> >
>
> Should I drop the fixes tag?
>
Nope, Tag still relevant and may be useful to someone down the
line!
Jonathan
> - Nuno Sá
>
>
>
>
next prev parent reply other threads:[~2022-06-18 14:04 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 8:45 [PATCH 00/34] make iio inkern interface firmware agnostic Nuno Sá
2022-06-10 8:45 ` [PATCH 01/34] iio: adc: ad7606: explicitly add proper header files Nuno Sá
2022-06-11 13:59 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 02/34] iio: adc: ad7606_par: " Nuno Sá
2022-06-11 14:00 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 03/34] iio: adc: berlin2-adc: " Nuno Sá
2022-06-11 14:02 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 04/34] iio: adc: imx7d_adc: " Nuno Sá
2022-06-11 14:04 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 05/34] iio: adc: imx8qxp-adc: " Nuno Sá
2022-06-11 14:05 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 06/34] iio: adc: ingenic-adc: " Nuno Sá
2022-06-10 14:45 ` Andy Shevchenko
2022-06-10 19:49 ` Nuno Sá
2022-06-11 14:07 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 07/34] iio: adc: mp2629_adc: " Nuno Sá
2022-06-11 14:08 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 08/34] iio: adc: mt6360-adc: " Nuno Sá
2022-06-11 14:09 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 09/34] iio: adc: npcm_adc: " Nuno Sá
2022-06-11 14:12 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 10/34] iio: adc: rzg2l_adc: " Nuno Sá
2022-06-11 14:13 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 11/34] iio: common: cros_ec_lid_angle: " Nuno Sá
2022-06-11 14:14 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 12/34] iio: common: cros_ec_sensors: " Nuno Sá
2022-06-11 14:16 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 13/34] iio: dac: stm32-dac: " Nuno Sá
2022-06-11 14:17 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 14/34] iio: dac: vf610_dac: " Nuno Sá
2022-06-11 14:19 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 15/34] iio: humidity: hts221_buffer: " Nuno Sá
2022-06-10 14:47 ` Andy Shevchenko
2022-06-11 14:22 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 16/34] iio: light: cros_ec_light_prox: " Nuno Sá
2022-06-11 14:23 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 17/34] iio: pressure: cros_ec_baro: " Nuno Sá
2022-06-10 8:45 ` [PATCH 18/34] iio: trigger: stm32-lptimer-trigger: " Nuno Sá
2022-06-10 8:45 ` [PATCH 19/34] iio: core: drop of.h from iio.h Nuno Sá
2022-06-11 14:30 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 20/34] iio: inkern: only relase the device node when done with it Nuno Sá
2022-06-10 14:56 ` Andy Shevchenko
2022-06-10 20:08 ` Nuno Sá
2022-06-11 14:59 ` Jonathan Cameron
2022-06-13 7:20 ` Nuno Sá
2022-06-18 14:03 ` Jonathan Cameron
2022-06-18 14:13 ` Jonathan Cameron [this message]
2022-06-18 17:30 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 21/34] iio: inkern: fix return value in devm_of_iio_channel_get_by_name() Nuno Sá
2022-06-10 14:56 ` Andy Shevchenko
2022-06-10 8:45 ` [PATCH 22/34] iio: inkern: only return error codes in iio_channel_get_*() APIs Nuno Sá
2022-06-10 15:05 ` Andy Shevchenko
2022-06-10 19:48 ` Nuno Sá
2022-06-11 15:17 ` Jonathan Cameron
2022-06-13 7:06 ` Nuno Sá
2022-06-18 14:06 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 23/34] iio: inkern: split of_iio_channel_get_by_name() Nuno Sá
2022-06-10 15:07 ` Andy Shevchenko
2022-06-10 8:45 ` [PATCH 24/34] iio: inkern: move to fwnode properties Nuno Sá
2022-06-10 15:19 ` Andy Shevchenko
2022-06-10 20:01 ` Nuno Sá
2022-06-11 15:30 ` Jonathan Cameron
2022-06-11 15:32 ` Jonathan Cameron
2022-06-13 7:13 ` Nuno Sá
2022-06-18 14:09 ` Jonathan Cameron
2022-06-10 8:45 ` [PATCH 25/34] thermal: qcom: qcom-spmi-adc-tm5: convert to IIO fwnode API Nuno Sá
2022-06-10 15:20 ` Andy Shevchenko
2022-06-10 19:42 ` Nuno Sá
2022-06-10 8:45 ` [PATCH 26/34] iio: adc: ingenic-adc: convert to IIO fwnode interface Nuno Sá
2022-06-10 8:45 ` [PATCH 27/34] iio: adc: ab8500-gpadc: convert to device properties Nuno Sá
2022-06-15 14:26 ` Linus Walleij
2022-06-10 8:45 ` [PATCH 28/34] iio: adc: at91-sama5d2_adc: " Nuno Sá
2022-06-10 8:45 ` [PATCH 29/34] iio: adc: qcom-pm8xxx-xoadc: " Nuno Sá
2022-06-15 14:27 ` Linus Walleij
2022-06-10 8:45 ` [PATCH 30/34] iio: adc: qcom-spmi-vadc: " Nuno Sá
2022-06-16 13:15 ` Linus Walleij
2022-06-10 8:45 ` [PATCH 31/34] iio: adc: qcom-spmi-adc5: " Nuno Sá
2022-06-16 13:16 ` Linus Walleij
2022-06-10 8:45 ` [PATCH 32/34] iio: adc: stm32-adc: " Nuno Sá
2022-06-11 15:47 ` Jonathan Cameron
2022-06-17 15:58 ` Fabrice Gasnier
2022-06-10 8:45 ` [PATCH 33/34] iio: inkern: remove OF dependencies Nuno Sá
2022-06-10 8:45 ` [PATCH 34/34] iio: inkern: fix coding style warnings Nuno Sá
2022-06-10 15:53 ` Joe Simmons-Talbott
2022-06-10 19:51 ` Nuno Sá
2022-06-12 17:39 ` Geert Uytterhoeven
2022-06-13 7:23 ` Nuno Sá
2022-06-10 14:48 ` [PATCH 00/34] make iio inkern interface firmware agnostic Andy Shevchenko
2022-06-10 15:28 ` Andy Shevchenko
2022-06-11 15:50 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220618151358.44b78c11@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy.shevchenko@gmail.com \
--cc=chrome-platform@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-mips@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=noname.nuno@gmail.com \
--cc=nuno.sa@analog.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox