Commit Graph

18 Commits

Author SHA1 Message Date
Adrian Bunk
e5f5e7339c build algorithms into the mac80211 module
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: Adrian Bunk <bunk@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-06-30 17:37:34 -04:00
Pavel Emelyanov
3282aea9ea mac80211: Do not report false error from mesh_path_add.
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: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21 21:47:44 -04:00
Pavel Emelyanov
8566dc3fca mac80211: Fix sleeping allocation under lock in mesh_path_node_copy.
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: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21 21:47:44 -04:00
Pavel Emelyanov
00242c40a1 mac80211: Report allocation failure from mesh_path_node_copy.
Now - return the -ENOMEM in case kmalloc fails.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21 21:47:43 -04:00
Pavel Emelyanov
4caf86c692 mac80211: Prepare mesh_table_grow to failing copy_node callback.
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: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21 21:47:42 -04:00
Pavel Emelyanov
5194ee82b4 mac80211: Fix one more call to synchronize_rcu in atomic context.
(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: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21 21:47:42 -04:00
Pavel Emelyanov
402d7752ed mac80211: Brush up error paths in mesh_path_add.
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: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21 21:47:41 -04:00
Pavel Emelyanov
6d6936e2ea Fix potential scheduling while atomic in mesh_path_add.
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: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-12 21:22:19 -04:00
Pavel Emelyanov
0eb03d5a14 Fix not checked kmalloc() result.
The new_node kmallocation is not checked for success, so add
this check.

BTW, it also happens under the read_lock.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-12 21:22:19 -04:00
Pavel Emelyanov
f84e71a94c Fix GFP_KERNEL allocation under read lock.
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: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-12 21:22:18 -04:00
Luis Carlos Cobo
2a8ca29a88 mac80211: fix mesh_path and sta_info get_by_idx functions
Skip properly entries whose dev does not match.

Signed-off-by: Luis Carlos Cobo <luisca@cozybit.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 16:40:54 -05:00
Luis Carlos Cobo
b4e08ea141 mac80211: add PLINK_ prefix and kernel doc to enum plink_state
Signed-off-by: Luis Carlos Cobo <luisca@cozybit.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 16:40:52 -05:00
Luis Carlos Cobo
cfa22c716f mac80211: always force mesh_path deletions
Postponing the deletion is not really useful anymore.

Signed-off-by: Luis Carlos Cobo <luisca@cozybit.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 16:40:51 -05:00
Luis Carlos Cobo
89a1ad6990 mac80211: delete mesh_path timer on mesh_path removal
This avoids dereferencing a no longer existing struct mesh_path.

Signed-off-by: Luis Carlos Cobo <luisca@cozybit.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 16:40:51 -05:00
Johannes Berg
7c8076bd8b mac80211: don't clear next_hop in path reclaim
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: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 15:30:47 -05:00
Johannes Berg
d0709a6518 mac80211: RCU-ify STA info structure access
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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 15:30:46 -05:00
Johannes Berg
c1edd987a4 mac80211: export mesh_plink_broken
This needs to be exported because rate control algorithms
can be modular.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 15:30:45 -05:00
Luis Carlos Cobo
eb2b9311fd mac80211: mesh path table implementation
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: Luis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-03-06 15:30:42 -05:00