On 01/09/2014 10:24 AM, Stanislaw Gruszka wrote:
On Tue, Jan 07, 2014 at 12:28:26PM -0600, Larry Finger wrote:rtnl_mutex --> misc_mtx --> rfkill_global_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rfkill_global_mutex); lock(misc_mtx); lock(rfkill_global_mutex); lock(rtnl_mutex); *** DEADLOCK ***There are 3 mutexes dependency. The deadlock can happen if on another cpu, let say CPU2, there will be sequence: lock(rtnl_mutex); lock(misc_mtx); Then on deadlock scenario: CPU0 waits for rtnl_mutex to unlock, keep rfkill_global_mutex locked CPU1 waits for rfkill_global_mutex to unlock, keep misc_mtx locked CPU2 waits for misc_mtx to unlock, keep rtnl_mutex locked. This dependency can be broken by moving b43_rng_init() outside from rtnl_mutex scope, like on below patch. IIUC b43 random number generator works only if we already started network connection, but this should not be a problem, as b43_rng_read() do not return any data if device is not prepared. You could also remove whole b43 rnd. Everyone know, that HW vendors are influenced by NSA and they random generators do not provide truly random numbers (just kidding ;-)
Well, I have no idea to what extent NSA affects the RNGs in computers; however, I do like having that additional source of entropy. :)
Your analysis was spot on, and I will be submitting a patch shortly with you as author. I'll give the reporter on b.k.o a chance to test it, but it removed the splat here.
Thanks, Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
