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:	Thu, 09 Aug 2007 11:13:12 +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, Greg KH <greg@...ah.com>
Subject: Re: [PATCH] request_firmware: skip timeout if userspace was not 
	notified

On Tue, 07 Aug 2007, Kay Sievers wrote:
> Nope, you would just fulfill in a completely generic way all outstanding
> requests when you are ready. All requests are all nicely grouped and
> visible in sysfs. There would be no need of coding your own device
> specific rebind. No timeout is needed or wanted, all requests would stay
> until userspace has handled them successfully or canceled them.

If I'm not mistaken, as it is now, requests are not grouped in any way.
The only hint that a firmware loading request is in progress are a couple
of files in the device directory in sysfs. Should I run, at boot, through
all the device directories to check which firmware requests are pending?

Also, this could pose problems if two drivers can handle a device but
the first that gets to bind to it needs firmware and userspace doesn't
provide it or cancel the loading. The device will remain bound without
giving the other driver a chance to handle it.

Anyway, I think something must be done, either removing the timeout and
making all firmware requests asynchronous, or at least skipping the
delay when we're sure that it's useless.

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/