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]

Date:	Tue, 07 Aug 2007 14:47:02 +0200
From:	Javier Pello <javier.pello@...c.es>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
CC:	Kay Sievers <kay.sievers@...y.org>, linux-kernel@...r.kernel.org,
	Greg KH <greg@...ah.com>
Subject: Re: [PATCH] request_firmware: skip timeout if userspace was not 
	notified

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.

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/