Re: [PATCH] drivers/base: use a worker for sysfs unbind
From: Rafael J. Wysocki
Date: Thu Dec 13 2018 - 06:05:50 EST
On Thu, Dec 13, 2018 at 11:23 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> On Thu, Dec 13, 2018 at 10:58 AM Daniel Vetter <daniel@xxxxxxxx> wrote:
> > - Most of these issues are never visible in normal usage, since normally
> > driver bind/unbind is done from a kthread or model_load/unload, neither
> > of which is running in the context of that kernfs mutex kernfs_fop_write
> > holds. That's why I think the task work is the best solution, since it
> > changes the locking context of the unbind sysfs to match the locking
> > context of module unload and hotunplug.
> I think that using a task work here makes sense. There is a drawback,
> which is that the original sysfs write will not wait for the driver to
> actually be released before returning to user space AFAICS, but that
> probably isn't a big deal.
> Also please note that the patch changes the code flow slightly,
> because passing a non-NULL parent pointer to
> device_release_driver_internal() potentially has side effects, but
> that should not be a big deal either.
> > Unfortunately that trick doesn't work for the bind sysfs file, since that way we can't thread the errno value back to userspace.
> Right. That is unless we wait for the operation to complete and check
> the error left behind by it. That should be doable, but somewhat
That said I'm not really sure if propagating the error to user space
in this case should be expected. The interface could be defined as
asynchronous to begin with a separate way for user space to check the
status if necessary. Changing that now may not be practical, though.