summaryrefslogtreecommitdiffstats
path: root/mm/kmemleak-test.c
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 /mm/kmemleak-test.c
parent7b80ece41aea0b73283c6df5a8f25d40aa13135d (diff)
downloadop-kernel-dev-e2e414d92397c366396d13f627a98a20be92e509.zip
op-kernel-dev-e2e414d92397c366396d13f627a98a20be92e509.tar.gz
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 'mm/kmemleak-test.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud