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: <46BCD7AA.5080407@urjc.es>
Date:	Fri, 10 Aug 2007 23:24:58 +0200
From:	Javier Pello <javier.pello@...c.es>
To:	Kay Sievers <kay.sievers@...y.org>
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 09 Aug 2007, Kay Sievers wrote:

> On Thu, 2007-08-09 at 11:36 +0200, Javier Pello wrote:
> 
> > 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.

If I see it correctly, your point is that the firmware loader is
totally broken and needs replacing. That's fine, and I won't say
otherwise. But it doesn't seem that such replacement is under way
and, in the meanwhile, we are stuck with what we have. I'm not
defending the current loader but, while we have it, we might as
well not have it freeze the whole kernel for a minute waiting
for something that won't happen.

> 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.

Note that the problem is not getting the driver to work---I can
do that pretty easily. The problem is that there's a number of
drivers that, just because they require firmware, will hang the
kernel on boot if built in unless an initramfs is carefully
prepared. An allyesconfig kernel could freeze for 10 minutes
during boot just because it came across 10 devices requiring
firmware, even if you don't intend to use them.

> You just picked a set of options that doesn't work nicely
> together.

I agree. That's why I sent the patch, to make it work better.

> No distro setup has this problem, that's probably why nobody
> really cared and it didn't get fixed so far.

I agree again. But the fact that it didn't get fixed so far
doesn't mean that it can never get fixed, does it?

Also, note that I'm not proposing massive changes, or changes
that will break things for other people (not intentionally,
anyway), or that will add complexity and unmaintainability
to the kernel. They try to do a reasonable thing and are
small and to the point.

Javier

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