summaryrefslogtreecommitdiff
path: root/net/rfkill
diff options
context:
space:
mode:
authorJohannes Berg <johannes@sipsolutions.net>2009-07-10 11:38:14 +0200
committerJohn W. Linville <linville@tuxdriver.com>2009-07-21 12:07:35 -0400
commite2e414d92397c366396d13f627a98a20be92e509 (patch)
tree0e30315aaf3c17b0f94187342733d2bace733c24 /net/rfkill
parent7b80ece41aea0b73283c6df5a8f25d40aa13135d (diff)
downloadlinux-rpi3-e2e414d92397c366396d13f627a98a20be92e509.tar.gz
linux-rpi3-e2e414d92397c366396d13f627a98a20be92e509.tar.bz2
linux-rpi3-e2e414d92397c366396d13f627a98a20be92e509.zip
mac80211: disable mesh
My kvm instance was complaining a lot about sleeping in atomic contexts in the mesh code, and it turns out that both mesh_path_add() and mpp_path_add() need to be able to sleep (they even use synchronize_rcu()!). I put in a might_sleep() to annotate that, but I see no way, at least right now, of actually making sure those functions are only called from process context since they are both called during TX and RX and the mesh code itself even calls them with rcu_read_lock() "held". Therefore, let's disable it completely for now. It's possible that I'm only seeing this because the hwsim's beaconing is broken and thus the peers aren't discovered right away, but it is possible that this happens even if beaconing is working, for a peer that doesn't exist or so. It should be possible to solve this by deferring the freeing of the tables to call_rcu() instead of using synchronize_rcu(), and also using atomic allocations, but maybe it makes more sense to rework the code to not call these from atomic contexts and defer more of the work to the workqueue. Right now, I can't work on either of those solutions though. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'net/rfkill')
0 files changed, 0 insertions, 0 deletions