Re: [PATCH 1/3] firmware: Avoid superfluous usermodehelper lock

[Takashi Iwai]

At Thu, 9 May 2013 16:43:28 +0800,
Ming Lei wrote:
> 
> On Thu, May 9, 2013 at 3:31 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> > At Thu, 9 May 2013 09:25:35 +0800,
> > Ming Lei wrote:
> >>
> >> On Thu, May 9, 2013 at 1:51 AM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> >> >> In other words, the first patch is no essential part of the fix.
> >> >> I can revisit the second patch without this one and resend if
> >> >> preferred.
> >> >
> >> > FWIW, below is the revised patch.
> >> > It's alone without the patch 1 in the previous series.
> >>
> >> The root cause is that your user space loader doesn't follow the
> >> current firmware loader interface.
> >
> > There is not necessarily a user space "loader".  It's declared as
> > non-hotplug, thus it can be a manual operation by human.
> >
> >> IMO, the patch is unnecessary since we already have the timeout
> >> abort(just need one patch to enable it for nowait api)
> >
> > Well, you cannot know any sane value for such human's operation.
> > If it's a system response, then we can assume something.  But the
> > invocation of request_firmware_nowait() with non-hotplug means that
> > you can never know the actual use case, thus you cannot know any sane
> 
> I think the use case should be driver specific, and the loading is triggered
> from user space in dell_rbu(write sysfs file to trigger BIOS update), so the
> user has been ready for loading the image.

Yes, it's ready, but it doesn't guarantee that it's done in which time
limit.  That's the uncertain point in such an interface.

If it were hotplug via udev, we can assume some sane time limit.
But in a scenario like the above, with the manual intervention, we
can't know what is the sane value in a single manner.

> For another usage(lattice-ecp3-config.c), it is merged recently and very
> specific(maybe only for personal use), and can be easily to change to
> trigger loading from user space like dell.
> 
> I think both the two usages choose FW_ACTION_NOHOTPLUG
> because they have out of tree firmware images.  So looks enabling
> timeout won't be a big deal for them.

Yeah, but it's a guess.

So, in these use cases, the practical impact would be small, I agree.
Changing this (adding a timeout unconditionally) eases the shutdown
stall.  But I still feel this is no essential fix, and in general,
changing the user-space behavior has to be done really carefully.

> > timeout, too.
> >
> > And secondly, I don't think it's good to rely on the timeout.  Why
> > does the system have to wait for minute for shutdown?  The system is
> 
> It won't if the user space follows the rules.

Well... what rule?  The kernel shutdown must be blocked when user
space doesn't write 0 or -1 to /sys/class/firmware/*/loading?
If you meant it, I would say that the rule is wrong.  There is no big
reason to block the *kernel* shutdown by such an action.

We're handling the moment where the system should be really shut down,
already after all user-space things are synced and killed.  For
example, would we delay the shutdown until all opened files are
closed even at this point?  The kernel doesn't do so.

> > in shutdown, and it's triggered by user.  It's more natural to abort
> > the pending f/w loading because you don't want to handle it any
> > longer after the system shuts down.
> 
> There is still risk to force killing the loader before shutdown or
> suspend.  Maybe some devices depend its firmware in shutdown
> or suspend callback to configure power setting.

The firmware loading is never guaranteed to succeed.  If the abort of
f/w loading at shutdown would cause any problem, it means that the
driver is fundamentally buggy, and we must fix it inevitably anyway.

Of course, the suspend is a bit different issue.  Maybe better to
retry the load after resume instead of forcibly aborting.
My point is that, if such critical kernel behavior like suspend or
shutdown rely on a timeout of user actions, it's badly designed.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/