linux-kernel - Re: will these methods work with firmware loading?

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: <CAPXgP10qa_g6R=pOWd8JuXpw0wPdJ4rP7B_4YHDU91mhC0N6Vg@mail.gmail.com>
Date:	Mon, 20 Feb 2012 11:19:48 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Arend van Spriel <arend@...adcom.com>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	LKML <linux-kernel@...r.kernel.org>,
	driverdevel <devel@...verdev.osuosl.org>,
	wireless <linux-wireless@...r.kernel.org>,
	"linux-hotplug@...r.kernel.org" <linux-hotplug@...r.kernel.org>
Subject: Re: will these methods work with firmware loading?

On Mon, Feb 20, 2012 at 11:01, Arend van Spriel <arend@...adcom.com> wrote:
> On 02/19/2012 07:40 PM, Larry Finger wrote:

>> Similarly, if I were to create a work queue, init and schedule it from
>> module_init(), and then use synchronous loads to get the firmware from the
>> work
>> queue callback, would that get around the boot problem? I know it works as
>> I
>> have trial patches; however, my version of udev is not one affected. This
>> method
>> is very easy to implement, but again I would like confirmation from an
>> expert.

It sounds like it should work, because the modprobe event returns, not
waiting for the firmware request. Chaining one firmware request after
the other sounds not like a problem, as long as they are chained with
the return from the earlier request and not from inside the earlier
request, which would have duplicated device name issues in the kernel
too.

> What boot problem are you referring to?

The pci event calls modprobe, the module init for the pci driver
creates a child event of the pci device, this child event is queued in
udev to be started after the pci event has finished. The pci event
does not finish in time because the firmware request blocks itself.

The current udev logic limits the timeout to 30 sec, while the
firmware request is 60 sec, so it usually works with a logged error,
and a 30 second delay.

> The blocking modprobe?

Yes, blocking in the module init path, will deadlock udev. Linking
code into the kernel must not depend on device init or firmware
loading.

> For that
> problem I would say yes. Also here the problem of handling error flows
> exist. If the driver is kicked of during boot with a initramfs missing the
> firmware, should we retry until the real root is mounted?

I don't think so. Drivers are not supposed to know about bootup or
initramfs issues. If they want, they can disable the timeout, and wait
for userspace to handle the request any time later, but they should
not try to be smart here.

Currently, firmware requests are cancelled if the firmware isn't
found, but that's a userspace issue, and nothing the kernel should try
to work around.

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/