Re: [PATCH] firmware loader: don't cancel _nowait requests whenhelper is not yet available

[Kay Sievers]

On Wed, Mar 14, 2012 at 01:54, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Mar 13, 2012 at 5:14 PM, Kay Sievers <kay@xxxxxxxx> wrote:
>>
>> Yeah it's certainly useful to disable the exec() during suspend calls,
>> much more than using the exec() inhibit flag for the firmware loader
>> to throw a warning about suspend issues.
>
> Kay, just stop confusing the issue already.
>
> It has *nothing* to do with exec. It has *nothing* to do with
> /sbin/hotplug. Stop repeating that stupid mantra. It's totally and
> utterly irrelevant.
>
> You can't load firmware while the system is suspended. End of story.
> You can't load it using /sbin/hotplug, you can't load it with dbus,
> you cannot load it FULL STOP.
>
> The filesystem you'd want to load it from may simply not be ready yet.
>
> This has nothing to do with exec or anything else. It's very simple:
> you cannot load firmware while the system isn't yet fully up.
> Seriously.
>
> You need to wait to load the firmware until everything is all done,
> and things work.
>
> Or you should - preferably - just have preloaded the damn thing.

usermodehelper_is_disabled() is a flag from kmod which is all about
exec(). That flag should not be used to decide if a firmware request
can be issued by a driver and queued up or not. There is no
usermodehelper involved at all in loading firmware today, hence we
should not use that flag.

Firmware requests are asynchronous like all other driver-core uevents
too, and they can be queued at any time. firmware is not special here.
The kernel has no real business in warning about that, or refusing a
request, just the same way it has no business to tell that other
events are queued but not directly delivered to userspace at that very
moment.

The firmware requests will travel into userspace just fine when stuff is ready.

Kay
--
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/