Johannes Berg wrote: > It seems the only reason lockdep doesn't warn is the detour to userspace > (modprobe) and the waiting for a userspace task (waiting isn't lockdep > annotated and I don't think it can be) > > It seems you cannot load a module while under _any_ lock, ever, since > userspace might turn around and do something that requires that lock? I > think we should probably add a warning to the code that waits for the > userspace task: > > debug_check_no_locks_held(current); > > Or not? Some purely internal locks _might_ be ok... but how could you > verify that? > > >> - ieee80211_wep_init(), which is called with rtnl_lock() held, is >> blocked in request_module() [waiting for modprobe to load a crypto module]. >> > > Right. > > >> - modprobe is blocked in a call to flush_workqueue(), caused by closing >> a TTY. >> > > Can you point out where? I can't find that. > I posted the calltraces earlier at <http://marc.info/?l=linux-wireless&m=124074566523506&w=2>. wait_for_completion flush_cpu_workqueue ? wq_barrier_func flush_workqueue flush_scheduled_work tty_ldisc_release ? tty_fasyc tty_release_dev ? free_pgtables tty_release __fput filp_close sys_close syscall_call >> - worker_thread is blocked because the workqueue item linkwatch_event() >> is blocked on rtnl_lock. >> > > This I know about. > > >> I've hacked up a test patch to move wep_init() outside of rtnl_lock, and >> it solved the problem. My one caveat is that it would probably be >> cleaner to move it after rtnl_unlock(), instead of before rtnl_lock(). >> I just wasn't 100% sure if that would be safe. Here's the patch: >> > > That doesn't seem relevant, this just does some initialisation. However, > you definitely missed adding a call to wep_free(). > Hah, I should have realized something was wrong when I noticed I was removing more lines that I added. The crypto init does cause the module load: wait_for_completion call_usermodehelper_exec __request_module crypto_larval_lookup ? extract_entropy crypto_alg_mod_lookup crypto_alloc_base ieee80211_wep_init ieee80211_register_hw ? ath5k_hw_set_bss ath5k+pci_probe local_pci_probe pci_device_probe driver_probe_device __driver_attach bus_for_each_dev driver_attach ? __driver_attach buad_add_driver driver_register ? ktime_get_ts __pci_register_driver init_ath5k_pci _stext ? init_ath5k_pci ? proc_create_data ? register_ieq_proc kernel_init Thanks Alan -- 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
