• Johannes Berg's avatar
    mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
    Johannes Berg authored
    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.
    Reported-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    Tested-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    34a3740d
chan.c 18.6 KB