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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Mar 2012 17:33:45 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: "Rafael J. Wysocki" <rjw@...k.pl> Cc: Christian Lamparter <chunkeey@...glemail.com>, "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>, linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org, alan@...rguk.ukuu.org.uk, Linux PM mailing list <linux-pm@...r.kernel.org> Subject: Re: [RFC] firmware loader: retry _nowait requests when userhelper is not yet available On Fri, Mar 16, 2012 at 5:23 PM, Rafael J. Wysocki <rjw@...k.pl> wrote: > > OK, but that asynchronous thread needs to know whether or not the system is up. Sure. > It can use the usermodehelper_is_disabled() check, but that needs to be done > under read_lock_usermodehelper() and it can't release the lock before > calling _request_firmware(), or all that thing would be racy. Well, I think that it would actually be a good idea to perhaps split up that existing _request_firmware() a bit. In fact, it might be good to split up that whole "fw_create_instance()" too - and re-organize the code a bit so that you end up creating the "firmware_priv" thing first. So maybe we could have a helper function that does that first part of fw_create_instance() (the part that allocates it and does the __module_get() part and other really basic initialization), and that can be called unconditionally by the request_firmware_nowait() code early. That early part probably should *not* create the device attribute files etc (although who knows - maybe sysfs is ok at this point). So I think we really could re-organize the code to do a sane job - and move just the actual udev setup etc to the final part that needs to be delayed. Hmm? I haven't looked very deeply into it, but my *gut* feel is that it should be doable pretty cleanly. But yeah, it would be more than a little one-liner. I think it might be worth it, though. Clearly separating out the three stages: "setup" -> "wait for system to be ready" -> "do the actual load". Then, the regular request_firmware() function would do exactly the same things, except it would never do the "wait for system to be ready" part: it would just fail with the warning if it wasn't already ready. So they'd still share all the basic core code, it would just be a slightly different organization from what it is now. Linus -- 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