[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221009183854.690e2780@jic23-huawei>
Date: Sun, 9 Oct 2022 18:38:54 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Claudiu.Beznea@...rochip.com, matti.vaittinen@...rohmeurope.com,
lars@...afoo.de, Michael.Hennerich@...log.com,
cosmin.tanislav@...log.com, Eugen.Hristev@...rochip.com,
Nicolas.Ferre@...rochip.com, alexandre.belloni@...tlin.com,
bleung@...omium.org, groeck@...omium.org,
alexandru.ardelean@...log.com, nathan@...nel.org,
miquel.raynal@...tlin.com, linmq006@...il.com,
u.kleine-koenig@...gutronix.de, paul@...pouillou.net,
mihail.chindris@...log.com, gwendal@...omium.org,
andriy.shevchenko@...ux.intel.com, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
chrome-platform@...ts.linux.dev
Subject: Re: [RFT PATCH v3 10/10] iio: Don't silently expect attribute types
On Thu, 6 Oct 2022 15:53:52 +0300
Matti Vaittinen <mazziesaccount@...il.com> wrote:
> Hi Claudiu,
>
> On 10/6/22 11:35, Claudiu.Beznea@...rochip.com wrote:
> > On 03.10.2022 11:13, Matti Vaittinen wrote:
> >> The iio_triggered_buffer_setup_ext() and the
> >> devm_iio_kfifo_buffer_setup_ext() were changed by
> >> commit 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr")
> >> to silently expect that all attributes given in buffer_attrs array are
> >> device-attributes. This expectation was not forced by the API - and some
> >> drivers did register attributes created by IIO_CONST_ATTR().
> >>
> >> When using IIO_CONST_ATTRs the added attribute "wrapping" does not copy
> >> the pointer to stored string constant and when the sysfs file is read the
> >> kernel will access to invalid location.
> >>
> >> Change the function signatures to expect an array of iio_dev_attrs to
> >> avoid similar errors in the future.
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
> >
> > Tested-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
> >
> > on SAMA5D2
> >
>
> Thanks a ton for the testing! I do _really_ appreciate it :) I am now
> slightly more confident regarding the fix here - and a lot more
> confident that we do have an actual bug (as you explained in the reply
> to the first RFT) :)
You analysis was sound, so I've long been convinced ;)
Anyhow, one more coming through...
AD4130 v9 patch had same issue and so will also need updating with this
patch if it lands before yours.
Other than that static macro being ugly (which I can't improve on!)
all looks good to me, but I'll let it sit a while longer. If nothing
else I want to rebase the fixes-togreg tree on rc1 before putting the first
part of this series on top of it then letting them soak in next for
a few days,
Thanks,
Jonathan
>
> Yours
> -- Matti
>
Powered by blists - more mailing lists