The old infrastructure was:
- the default algorithm is built into mac80211
- other algorithms get into their own modules

The implementation of this complicated scheme was horrible
(just look at net/mac80211/Makefile), and anyone adding a new
algorithm would most likely not get it right at his first attempt.

This patch therefore builds all enabled algorithms into the mac80211
module.

The user interface for the rate control algorithms changes as follows:
- first the user can choose which algorithms to enable (currently only
  MAC80211_RC_PID is available)
- if more than one algorithm is enabled (currently not possible since
  only one algorithm is present) the user then chooses the default one

Note:
- MAC80211_RC_PID is always enables for CONFIG_EMBEDDED=n

Technical changes:
- all selected algorithms get into the mac80211 module
- net/mac80211/Makefile can now become much less complicated
- support for rc80211_pid_algo.c being modular is no longer required
- this includes unexporting mesh_plink_broken
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In case the hash grow failed, it is not fair to return error -
the new node _was_ _actually_ added in this case.

Besides, after my previous patch, this grow is more likely
to fail on large hashes.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The mesh_path_node_copy() can be called like this:
mesh_path_add
 `- write_lock(&pathtbl_resize_lock); /* ! */
 `- mesh_table_grow
     `- ->copy_node
           `- mesh_path_node_copy

thus, the GFP_KERNEL is not suitable here.

The acceptable fix, I suppose, is make this allocation GPF_ATOMIC -
the mpath_node being allocated is 4 pointers, i.e. this allocation
is small enough to survive even under a moderate memory pressure.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now - return the -ENOMEM in case kmalloc fails.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The mesh_path_node_copy() performs kmalloc() and thus - may fail
(well, it does not now, but I'm fixing this right now). Its caller -
the mesh_table_grow() - isn't prepared for such a trick yet.

This preparation is just flush the new hash and make copy_node()
return an int value.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

(This set applies OK without the previous one of 4 patches,
 but with some fuzz in the 7th one)

The mesh_path_node_free() does so under hashwlock.

But, this one is called
1. from mesh_path_add() after an old hash is hidden and
   synchronize_rcu() is calld
2. mesh_pathtbl_unregister(), when the module is being
   unloaded and no devices exist to mess with this hash.

So, it seems to me, that simply removing the call is OK.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are already tree paths, that do incremental rollbacks, so
merge them together, rename labels and format the code to look a
bit nicer.

(I do not mind dropping/delaying this patch however).
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Calling synchronize_rcu() under write-lock-ed pathtbl_resize_lock may
result in this warning (and other side effects).

It looks safe just dropping this lock before calling synchronize_rcu.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The new_node kmallocation is not checked for success, so add
this check.

BTW, it also happens under the read_lock.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The mesh_path_add() read-locks the pathtbl_resize_lock and calls
kmalloc with GFP_KERNEL mask.

Fix it and move the endadd2 label lower. It should be _before_ the
if() beyond, but it makes no sense for it being there, so I move it
right after this if().
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Skip properly entries whose dev does not match.
Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Postponing the deletion is not really useful anymore.
Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This avoids dereferencing a no longer existing struct mesh_path.
Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Luis pointed out that this path is going to be freed right
away anyway so there's no point in assigning next_hop.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: Luis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes access to the STA hash table/list use RCU to protect
against freeing of items. However, it's not a true RCU, the
copy step is missing: whenever somebody changes a STA item it
is simply updated. This is an existing race condition that is
now somewhat understandable.

This patch also fixes the race key freeing vs. STA destruction
by making sure that sta_info_destroy() is always called under
RTNL and frees the key.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This needs to be exported because rate control algorithms
can be modular.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The mesh path table associates destinations with the next hop to reach them. The
table is a hash of linked lists protected by rcu mechanisms. Every mesh path
contains a lock to protect the mesh path state.

Each outgoing mesh frame requires a look up into this table. Therefore, the
table it has been designed so it is not necessary to hold any lock to find the
appropriate next hop.

If the path is determined to be active within a rcu context we can safely
dereference mpath->next_hop->addr, since it holds a reference to the sta
next_hop. After a mesh path has been set active for the first time it next_hop
must always point to a valid sta.  If this is not possible the mpath must be
deleted or replaced in a RCU safe fashion.
Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>