mlme.c
	l.757 ieee80211_dynamic_ps_enable_work(11)
	variable dereferenced before check 'sdata'

mesh_pathtbl.c
	l.650 mesh_path_del(20) double lock 'bottom_half'
	l.663 mesh_path_del(33) double unlock 'bottom_half'

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

After commit 1928ecab620907a0953f811316d05f367f3f4dba (mac80211: fix and
simplify mesh locking) mesh table allocation is performed with the
pathtbl_resize_lock taken.  Under those conditions one should not sleep.
This patch makes the allocations GFP_ATOMIC to prevent that.

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Conflicts:
	drivers/net/wireless/iwlwifi/iwl-agn-tx.c
	net/mac80211/sta_info.h

This adds proper RCU annotations to the mesh path
table code, and fixes a number of bugs in the code
that I found while checking the sparse warnings I
got as a result of the annotations.

Some things like the changes in mesh_path_add() or
mesh_pathtbl_init() only serve to shut up sparse,
but other changes like the changes surrounding the
for_each_mesh_entry() macro fix real RCU bugs in
the code.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The locking in mesh_{mpath,mpp}_table_grow not only
has an rcu_read_unlock() missing, it's also racy
(though really only technically since it's invoked
from a single function only) since it obtains the
new size of the table without any locking, so two
invocations of the function could attempt the same
resize.

Additionally, it uses synchronize_rcu() which is
rather expensive and can be avoided trivially here.

Modify the functions to only use the table lock
and use call_rcu() instead of synchronize_rcu().

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Mesh paths are deleted via mesh_path_del() which properly
deactivates the timer associated to a mesh path.  But if paths were
deleted by mesh_table_free(..., true) timers would not be deactivated.
This fixes this case.

Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

There's no need to have table functions in one
file and all users in another, move the functions
to the right file and make them static. Also move
a static variable to the beginning of the file to
make it easier to find.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The mesh and mpp path tables are accessed from softirq and workqueue
context so non-irq locking cannot be used.  Or at least that's what
PROVE_RCU seems to tell us here:

[  431.240946] =================================
[  431.241061] [ INFO: inconsistent lock state ]
[  431.241061] 2.6.39-rc3-wl+ #354
[  431.241061] ---------------------------------
[  431.241061] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[  431.241061] kworker/u:1/1423 [HC0[0]:SC0[0]:HE1:SE1] takes:
[  431.241061]  (&(&newtbl->hashwlock[i])->rlock){+.?...}, at:
[<c14671bf>] mesh_path_add+0x167/0x257

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Not sure if I'm chasing a ghost here, seems like the
mesh_path->size_order needs to be inside an RCU-read section to prevent
that value from changing between table allocation and copying.  We have
observed crashes that might be caused by this.

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>