On Mon, Feb 16, 2009 at 1:22 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2009-02-16 at 01:17 -0800, Luis R. Rodriguez wrote: > >> >> > So before you documented that cfg80211_mutex is used to protect this >> >> > variable, but it's not used here. >> >> >> >> This is only used during initialization, have any better ideas? >> > >> > If regulatory is initialised before netlink that is probably fine, is >> > it? >> >> Yeah I was hoping that would be the case but then I realized that we >> also end up creating a udev event to call crda and we need nl80211 >> initialized in order to process these hints so technically we have a >> race between regulatory_init() finishing and nl80211_init() get done >> before we can let nl80211 process the first CORE call to crda so it >> may be dropped -- unless we are sure udev will do some sort of >> retries. >> >> An alternative is to add the regulatory_request() for core to the >> queue and then call a reg_post_init() on core.c that would just >> schedule the reg workqueue after nl80211_init(). >> >> Thoughts? > > Can't you just do the proper locking and initialise regulatory after > nl80211? Yes if we figure out a way to not do a mutex_lock() from the module's init, we cannot call a mutex_lock() from cfg80211_init(). I think sending core's request to the workqueue is one way -- we'd then have to schedule the queue towards the end of regulatory_init(). Luis -- 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
