As a part of patch series about wrong trigger register() and get()
calls order in the some IIO drivers trigger initialization path:
https://lore.kernel.org/all/[email protected]/
runtime WARN() is added to alarm IIO driver authors who make such
a mistake.
When IIO driver allocates a new IIO trigger, it should register it before
calling the get() operation. In other words, each IIO driver must abide by
IIO trigger alloc()/register()/get() calls order.
Signed-off-by: Dmitry Rokosov <[email protected]>
---
drivers/iio/industrialio-trigger.c | 2 ++
include/linux/iio/trigger.h | 5 +++++
2 files changed, 7 insertions(+)
diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
index f504ed351b3e..d6277e72d515 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -581,6 +581,8 @@ struct iio_trigger *viio_trigger_alloc(struct device *parent,
if (trig->name == NULL)
goto free_descs;
+ INIT_LIST_HEAD(&trig->list);
+
trig->subirq_chip.name = trig->name;
trig->subirq_chip.irq_mask = &iio_trig_subirqmask;
trig->subirq_chip.irq_unmask = &iio_trig_subirqunmask;
diff --git a/include/linux/iio/trigger.h b/include/linux/iio/trigger.h
index 4c69b144677b..2d71cb331f1c 100644
--- a/include/linux/iio/trigger.h
+++ b/include/linux/iio/trigger.h
@@ -93,6 +93,11 @@ static inline void iio_trigger_put(struct iio_trigger *trig)
static inline struct iio_trigger *iio_trigger_get(struct iio_trigger *trig)
{
get_device(&trig->dev);
+
+ WARN(list_empty(&trig->list),
+ "Getting non-registered iio trigger %s is prohibited\n",
+ trig->name);
+
__module_get(trig->owner);
return trig;
--
2.36.0
On Mon, Jun 6, 2022 at 1:23 PM Dmitry Rokosov <[email protected]> wrote:
>
> As a part of patch series about wrong trigger register() and get()
> calls order in the some IIO drivers trigger initialization path:
>
> https://lore.kernel.org/all/[email protected]/
>
> runtime WARN() is added to alarm IIO driver authors who make such
> a mistake.
>
> When IIO driver allocates a new IIO trigger, it should register it before
an IIO
> calling the get() operation. In other words, each IIO driver must abide by
> IIO trigger alloc()/register()/get() calls order.
I believe triggers usually acquired at ->probe() time, means that in
case if the following code (however, I believe it will be quite rare)
goes into deferred probe cycle the WARN will be repeated. Perhaps
WARN_ONCE() ?
--
With Best Regards,
Andy Shevchenko
Hello Andy,
Thank you for the quick reply.
On Mon, Jun 06, 2022 at 02:42:18PM +0200, Andy Shevchenko wrote:
> On Mon, Jun 6, 2022 at 1:23 PM Dmitry Rokosov <[email protected]> wrote:
> >
> > As a part of patch series about wrong trigger register() and get()
> > calls order in the some IIO drivers trigger initialization path:
> >
> > https://lore.kernel.org/all/[email protected]/
> >
> > runtime WARN() is added to alarm IIO driver authors who make such
> > a mistake.
> >
> > When IIO driver allocates a new IIO trigger, it should register it before
>
> an IIO
>
> > calling the get() operation. In other words, each IIO driver must abide by
> > IIO trigger alloc()/register()/get() calls order.
>
> I believe triggers usually acquired at ->probe() time, means that in
> case if the following code (however, I believe it will be quite rare)
> goes into deferred probe cycle the WARN will be repeated. Perhaps
> WARN_ONCE() ?
You are totally right. I've tested deferred probing using -EPROBE_DEFER
injection to probe() code path and WARN() was called each time. I'll fix
it in the v3 as you suggested.
--
Thank you,
Dmitry