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: <1186491472.3611.33.camel@lov.localdomain>
Date:	Tue, 07 Aug 2007 14:57:52 +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, Greg KH <greg@...ah.com>
Subject: Re: [PATCH] request_firmware: skip timeout if userspace was not 
	notified


On Tue, 2007-08-07 at 14:47 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Cornelia Huck wrote:
> 
> > On Tue, 7 Aug 2007 13:46:55 +0200,
> > "Kay Sievers" <kay.sievers@...y.org> wrote:
> > > How do you check if events have been "handled"? None of the recent
> > > distros uses /sbin/hotplug anymore. Netlink events are broadcasted,
> > > but no failure in delivery doesn't mean anything like "handled", or
> > > delivered to the right instance. Even if you check that the netlink
> > > socket has listeners, that wouldn't be sufficient to tell that is
> > > handled.
> > 
> > You can't check if it's been handled, yes; but you can certainly check
> > if you delivered it. I guess Javier wants to exclude the cases where
> > userspace didn't have any chance to handle it.
> 
> That's right. There's no way to know if userspace does handle the event
> after reception, and that's why we have a timeout (so we don't wait
> forever), but we can be sure that userspace won't handle an event that
> wasn't received. We want to be conservative here: if there is any
> chance that the event was received, we set the timeout and wait.
> 
> > Javier: Do you have an idea how common the case "we broadcasted, but
> > nobody listened so we got a timeout" is? If the usual reason for the
> > timeout is that firmware was requested before a listener showed up,
> > I'm not sure whether that check is worth it...
> 
> I don't know how common this is in general, but in my box it happens
> (or rather happened, until I patched it) once per boot. I've got a
> device that requires some firmware during initialisation. I always
> build the driver into the kernel (I don't like modules for things
> that are permanently attached to the computer), and that means that
> it tries to initialise before the rootfs is mounted (there's no
> initramfs). Before the patch, the kernel would hang for a minute
> in request_firmware during each boot, which was rather annoying,
> and that is the reason why I decided to fix it.

If you don't have modules and the initial request fails, how do you load
the firmware later?

The real fix would be to change the driver not to block in the firmware
request and use async version of firmware loading. The whole firmware
class with its silly timeout is just a piece of crap, that needs to be
replaced.

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/