linux-kernel - Re: [PATCH] firmware loader: don't cancel _nowait requests when helper is not yet available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPXgP11ZKT-ZNBLdPQWotFayz9m7pKcNHDBPWxcp_2-ja+SAcQ@mail.gmail.com>
Date:	Wed, 14 Mar 2012 02:43:05 +0100
From:	Kay Sievers <kay@...y.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Greg KH <gregkh@...uxfoundation.org>,
	Christian Lamparter <chunkeey@...glemail.com>,
	linux-kernel@...r.kernel.org,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	alan@...rguk.ukuu.org.uk,
	Linux PM mailing list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] firmware loader: don't cancel _nowait requests when
 helper is not yet available

On Wed, Mar 14, 2012 at 01:54, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Mar 13, 2012 at 5:14 PM, Kay Sievers <kay@...y.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/