Re: [PATCH] watchdog: pretimeout: Add "dump" pretimeout governor

On Tue, Jul 07, 2026 at 08:02:24AM +0000, [email protected] wrote:
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 08cb8612d41fe..7b291ea8b0f01 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> 
> [ ... ]
> 
> > @@ -93,10 +93,19 @@ config WATCHDOG_PRETIMEOUT_GOV_SEL
> >  
> >  if WATCHDOG_PRETIMEOUT_GOV
> >  
> > +config WATCHDOG_PRETIMEOUT_GOV_DUMP
> > +	tristate "Dump watchdog pretimeout governor"
> 
> [Severity: Low]
> Will this fail to build if compiled as a module?
> 
> When CONFIG_WATCHDOG_PRETIMEOUT_GOV_DUMP=m, trigger_all_cpu_backtrace() can
> rely on unexported architecture-specific functions (such as
> arch_trigger_cpumask_backtrace() on x86, ARM, and ARM64), which causes a
> modpost build failure.

Use a bool instead in v2 [1].

[1] https://lore.kernel.org/all/[email protected]

> > diff --git a/drivers/watchdog/pretimeout_dump.c b/drivers/watchdog/pretimeout_dump.c
> > new file mode 100644
> > index 0000000000000..c5d3dac2606c4
> > --- /dev/null
> > +++ b/drivers/watchdog/pretimeout_dump.c
> 
> [ ... ]
> 
> > +static void __exit watchdog_gov_dump_unregister(void)
> > +{
> > +	watchdog_unregister_governor(&watchdog_gov_dump);
> > +}
> 
> [Severity: High]
> This is a pre-existing issue, but does unregistering the default watchdog
> pretimeout governor leave dangling pointers?
> 
> If this module is set as the default governor and then unloaded,
> watchdog_unregister_governor() attempts to reset the active governors:
> 
>     list_for_each_entry(p, &pretimeout_list, entry)
>         if (p->wdd->gov == gov)
>             p->wdd->gov = default_gov;
> 
> If the unregistered governor is the default governor, default_gov equals
> gov. This leaves p->wdd->gov pointing to the unloaded module's struct.
> 
> Could this lead to a use-after-free upon the next pretimeout event or sysfs
> read?

Proposed a fix in [2].

[2] https://lore.kernel.org/all/[email protected]