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
| ||
|
Date: Mon, 27 Aug 2012 02:04:00 +1000 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: Alan Cox <alan@...rguk.ukuu.org.uk> Cc: Ming Lei <tom.leiming@...il.com>, Kay Sievers <kay@...y.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Johannes Berg <johannes@...solutions.net>, Larry Finger <Larry.Finger@...inger.net>, Linus Torvalds <torvalds@...ux-foundation.org>, systemd-devel@...ts.freedesktop.org Subject: Re: udev 182: response timeout for request_firmware in module_probe path On Thu, 2012-08-23 at 17:46 +0100, Alan Cox wrote: > > IMO, the driver probing path is allowed to sleep, so looks request > firmware > > should be allowed inside .probe(). > > I'm not convinced about that. It can sleep but its holding various > locks > in most cases, and it looks like that can end up in a complete heap. > > By all means *request* the firmware asynchronously in the probe, but > there needs to be a seperate method somewhere after the probe to > finish > the job once the firmware appears. Not necessarily enough in the general case, for example some stacks will cause a driver open to be call back from somewhere within the register_foo() the driver did to register itself with it's subsystem inside probe. For example register_framebuffer(), register_netdev(), ... This is clearly a udev bug :-) Cheers, Ben. -- 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/
Powered by blists - more mailing lists