On Wed, 2013-12-18 at 20:45 +0100, Johannes Berg wrote: > From: Johannes Berg <johannes.berg@xxxxxxxxx> > > The scan code creates an iflist_mtx -> mtx locking dependency, > and a few other places, notably radar detection, were creating > the opposite dependency, causing lockdep to complain. As scan > and radar detection are mutually exclusive, the deadlock can't > really happen in practice, but it's still bad form. > > A similar issue exists in the monitor mode code, but this is > only used by channel-context drivers right now and those have > to have hardware scan, so that also can't happen. > > Still, fix these issues by making some of the channel context > code require the mtx to be held rather than acquiring it, thus > allowing the monitor/radar callers to keep the iflist_mtx->mtx > lock ordering. > > While at it, also fix access to the local->scanning variable > in the radar code, and document that radar_detect_enabled is > now properly protected by the mtx. > > All this would now introduce an ABBA deadlock between the DFS > work cancelling and local->mtx, so change the locking there a > bit to not need to use cancel_delayed_work_sync() but be able > to just use cancel_delayed_work(). The work is also safely > stopped/removed when the interface is stopped, so no extra > changes are needed. Applied. johannes -- 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
