Re: [PATCH] iio: trigger: cancel reenable_work before freeing trigger

On Thu,  6 Aug 2026 14:25:02 +0000
Fan Wu <[email protected]> wrote:

> iio_trigger_notify_done_atomic() defers ->reenable() into
> trig->reenable_work on the system workqueue, and the worker dereferences
> the owning trigger through container_of().  Nothing cancels this work
> before iio_trig_release() frees the trigger, so a worker armed by the
> last in-flight IRQ can outlive the free and touch freed memory.
> 
> Cancel it at the top of iio_trig_release(), which every free path
> reaches through the device core's final put_device().
> 
> Found by an in-house static analysis tool.
> 
> Fixes: 9020ef659885 ("iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046")
> Cc: [email protected]
> Cc: Jonathan Cameron <[email protected]>
> Assisted-by: Codex:gpt-5.6
> Signed-off-by: Fan Wu <[email protected]>
Logic seems correct to me.  Applied to the fixes-togreg branch of iio.git.

Note the only way we can see this in practice requires a race with a race handler
closing bit of code. Having said that, the inner one of those races handlers is
occasionally needed, so fair enough that we need to fix this.

Jonathan

> ---
>  drivers/iio/industrialio-trigger.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-trigger.c b/drivers/iio/industrialio-trigger.c
> index 54416a384232..68e92eac2b77 100644
> --- a/drivers/iio/industrialio-trigger.c
> +++ b/drivers/iio/industrialio-trigger.c
> @@ -509,6 +509,8 @@ static void iio_trig_release(struct device *device)
>  	struct iio_trigger *trig = to_iio_trigger(device);
>  	int i;
>  
> +	cancel_work_sync(&trig->reenable_work);
> +
>  	if (trig->subirq_base) {
>  		for (i = 0; i < CONFIG_IIO_CONSUMERS_PER_TRIGGER; i++) {
>  			irq_modify_status(trig->subirq_base + i,