linux-kernel - Re: [PATCH] request_firmware: skip timeout if userspace was not notified

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: <1186660716.21247.94.camel@lov.localdomain>
Date:	Thu, 09 Aug 2007 13:58:36 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Javier Pello <javier.pello@...c.es>
Cc:	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-kernel@...r.kernel.org, GregKH <greg@...ah.com>
Subject: Re: [PATCH] request_firmware: skip timeout if userspace was not 
	notified

On Thu, 2007-08-09 at 11:36 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Cornelia Huck wrote:
> 
> > So it is indeed that this driver wants to fail its probe if it
> > cannot get the firmware.
> 
> That's right. The driver unbinds itself from the device if it doesn't
> get the firmware.
> 
> > A possibilty to achieve a similar effect would be to use
> > request_firmware_nowait() and to call device_release_driver() from
> > the callback if no firmware is loaded. (This would imply a split of
> > that driver's probe function into two stages.)
> 
> The comments in the source code say that request_firmware_nowait()
> is an "asynchronous version of request_firmware() for contexts where
> it is not possible to sleep". So a driver's decision to call one of
> them is not based on whether it wants to wait or not, but whether it
> _can_ wait.
> 
> Of course, it can be decided that we never want to wait, but then
> the best course of action would be to make request_firmware itself
> behave as request_firmware_nowait (no need to change drivers).
> 
> Anyway, my point is that it is useless to have the kernel block for
> a minute at boot waiting for something that cannot happen, and that
> it should be avoided (even if my proposed solution is not the way
> to go).

That's true. And it sounds all reasonable from your point of view, and
the firmware loader needs fixing, and the silly blocking request needs
to be removed from the kernel, that's known for a very long time now,
but nobody did the work so far.

But in this specific case, it is more the combination of your options,
what causes this problem to appear. You don't have an initramfs, you
don't use modules, but you are linking a driver into the kernel image
which depends on a conceptually broken blocking userspace transaction to
initialize.
This combination of options just doesn't make sense. Either use
initramfs, or use a kernel module for the driver that needs userspace to
initialize, or patch the driver not to block in the request, or patch
the driver to optionally include the firmware in the driver.

You just picked a set of options that doesn't work nicely together. No
distro setup has this problem, that's probably why nobody really cared
and it didn't get fixed so far.

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/