Re: [PATCH] auxdisplay: seg-led-gpio: fix work initialization race and convert to devm_add_action_or_reset()

[Andy Shevchenko]

On Sun, Aug 02, 2026 at 04:30:16PM +0530, Surendra Singh wrote:

> I checked the other drivers in drivers/auxdisplay/ and found that
> drivers/auxdisplay/max6959.c has the exact same pattern:
> 
> 1. INIT_DELAYED_WORK(&priv->work, max6959_disp_update) is called inside
>    max6959_linedisp_get_map_type() (map query callback).
> 2. max6959_i2c_remove() calls cancel_delayed_work_sync(&priv->work)
>    before linedisp_unregister(&priv->linedisp).
> 
> I can prepare a 2-patch series fixing max6959.c as well.

Yes, please do. Or did I miss them?

> Furthermore, we could add devm_linedisp_register() to line-display.c
> to simplify linedisp teardown across all auxdisplay drivers.

That's what we all are waiting for to avoid some UAF types of bugs.

> On Sun, 2 Aug 2026 at 14:59, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > On Fri, Jul 24, 2026 at 5:55 AM <kr494167@xxxxxxxxx> wrote:

> > > INIT_DELAYED_WORK(&priv->work, seg_led_update) was previously called inside
> > > seg_led_linedisp_get_map_type(), which is invoked during/after
> > > linedisp_register(). Initializing a delayed_work structure inside a map
> > > query callback can re-initialize an active work item or race with
> > > seg_led_linedisp_update().
> > >
> > > In addition, seg_led_remove() called cancel_delayed_work_sync(&priv->work)
> > > before linedisp_unregister(&priv->linedisp), allowing sysfs updates to
> > > reschedule work after cancel_delayed_work_sync() completed.
> > >
> > > Fix these by moving INIT_DELAYED_WORK() to probe() and using
> > > devm_add_action_or_reset() for devm-managed cleanup. Registering
> > > seg_led_unregister_linedisp after seg_led_cancel_work ensures proper LIFO
> > > teardown order (sysfs interface unregistered first, followed by work
> > > cancellation), allowing seg_led_remove() to be removed entirely.
> >
> > I think we have more drivers than this one with the same issue, no? If
> > so, can we solve this once for all (the existing and possible future
> > ones)?

-- 
With Best Regards,
Andy Shevchenko