diff options
author | Johannes Berg <johannes@sipsolutions.net> | 2009-07-10 11:38:14 +0200 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2009-07-21 12:07:35 -0400 |
commit | e2e414d92397c366396d13f627a98a20be92e509 (patch) | |
tree | 0e30315aaf3c17b0f94187342733d2bace733c24 /mm/kmemleak-test.c | |
parent | 7b80ece41aea0b73283c6df5a8f25d40aa13135d (diff) | |
download | op-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