Re: [PATCH] fuse: fix 'inval_wq' parameter setting during module initialisation

[Luis Henriques <luis@igalia.com>]

On Fri, Nov 06, 2026 at 12:33:50PM +0100, Miklos Szeredi wrote:
> On Mon, 19 Oct 2026 at 14:52, Luis Henriques <luis@igalia.com> wrote:
> 
> > @@ -62,11 +61,14 @@ static int inval_wq_set(const char *val, const struct kernel_param *kp)
> >
> >         *((unsigned int *)kp->arg) = num;
> >
> > -       if (num && !old)
> > -               schedule_delayed_work(&dentry_tree_work,
> > -                                     secs_to_jiffies(num));
> > -       else if (!num && old)
> > -               cancel_delayed_work_sync(&dentry_tree_work);
> > +       /* Only start/stop workqueue if we're past module initialisation */
> > +       if (!module_is_coming(kp->mod)) {
> 
> See sashiko review:

*sigh*
I keep forgetting to check sashiko website.  Sorry about that :-/

> - kp->mod might be NULL which will Oops module_is_coming()

Hmm... I guess this should be fixable by adding a '!kp->mod' to the
condition:

	if (!kp->mod || !module_is_coming(kp->mod)) ...

> - it's still racy against fuse_dentry_tree_init

This one is a bit trickier indeed.  I could try to play a bit with the
modules notifiers (register_module_notifier).  But I haven't used that
before, so not sure it can be used, for example, kicking off the worker
later when the module has been initialised.

> 
> My question is: does the inval_wq_set() even need to work before the
> module is initialized?  Can't it just return an error and it wouldn't
> need to deal with the race.

That's probably the simplest option, but that would prevent us from, for
example, setting inval_wq as a kernel parameter, right?  Or doing:

  # modprobe fuse inval_wq=10

Do you think that's acceptable?

Cheers,
--
Luis