Commit graph

27 commits

Author SHA1 Message Date
Johannes Berg
f5ea9120be nl80211: add generation number to all dumps
In order for userspace to be able to figure out whether
it obtained a consistent snapshot of data or not when
using netlink dumps, we need to have a generation number
in each dump message that indicates whether the list has
changed or not -- its value is arbitrary.

This patch adds such a number to all dumps, this needs
some mac80211 involvement to keep track of a generation
number to start with when adding/removing mesh paths or
stations.

The wiphy and netdev lists can be fully handled within
cfg80211, of course, but generation numbers need to be
stored there as well.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-08-14 09:13:43 -04:00
Javier Cardona
249b405cf8 mac80211: Fix regression in mesh forwarding path.
The removal of the master netdev broke the mesh forwarding path.  This patch
fixes it by using the new internal 'pending' queue.

As a result of this change, mesh forwarding no longer does the inefficient
802.11 -> 802.3 -> 802.11 conversion that was done before.

[Changes since v1]
Suggested by Johannes:
 - Select queue before adding to mpath queue
 - ieee80211_add_pending_skb -> ieee80211_add_pending_skbs
 - Remove unnecessary header wme.h

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-24 15:05:31 -04:00
Javier Cardona
10c836d789 mac80211: Assign next hop address to pending mesh frames
Assign next hop address to pending mesh frames once the path is resolved.

Regression.  Frames transmitted when a mesh path was wating to be resolved were
being transmitted with an invalid Receiver Address.

[Changes since v1]

Suggested by Johannes:
 - Improved frame_queue traversal
 - Narower RCU scope

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-24 15:05:07 -04:00
Javier Cardona
35946a5710 mac80211: use correct address for mesh Path Error
For forwarded frames, we save the precursor address in addr1 in case it
needs to be used to send a Path Error.  mesh_path_discard_frame,
however, was using addr2 instead of addr1 to send Path Error frames, so
correct that and also make the comment regarding this more clear.

Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-21 12:07:40 -04:00
Johannes Berg
e2e414d923 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>
2009-07-21 12:07:35 -04:00
YanBo
79617deeeb mac80211: mesh portal functionality support
Currently the mesh code doesn't support bridging mesh point interfaces
with wired ethernet or AP to construct an MPP or MAP. This patch adds
code to support the "6 address frame format packet" functionality to
mesh point interfaces. Now the mesh network can be used as backhaul
for end to end communication.

Signed-off-by: Li YanBo <dreamfly281@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-24 16:18:02 -04:00
Johannes Berg
472dbc45dc mac80211: split off mesh handling entirely
This patch splits off mesh handling from the STA/IBSS.
Unfortunately it increases mesh code size a bit, but I
think it makes things clearer. The patch also reduces
per-interface run-time memory usage.

Also clean up a few places where ifdef is not required.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-15 16:48:20 -04:00
Jasper Bryant-Greene
f698d856f6 replace net_device arguments with ieee80211_{local,sub_if_data} as appropriate
This patch replaces net_device arguments to mac80211 internal functions
with ieee80211_{local,sub_if_data} as appropriate.

It also does the same for many 802.11s mesh functions, and changes the
mesh path table to be indexed on sub_if_data rather than net_device.

If the mesh part needs to be a separate patch let me know, but since
mesh uses a lot of mac80211 functions which were being converted anyway,
the changes go hand-in-hand somewhat.

This patch probably does not convert all the functions which could be
converted, but it is a large chunk and followup patches will be
provided.

Signed-off-by: Jasper Bryant-Greene <jasper@amiton.co.nz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-08-22 16:29:58 -04:00
Luis Carlos Cobo
e32f85f7b9 mac80211: fix use of skb->cb for mesh forwarding
Now we deal with mesh forwarding before the 802.11->802.3 conversion, thus
eliminating a few unnecessary steps. The next hop lookup is called from
ieee80211_master_start_xmit() instead of subif_start_xmit(). Until the next hop
is found, RA in the frame will be all zeroes for frames originating from the
device. For forwarded frames, RA will contain the TA of the received frame,
which will be necessary to send a path error if a next hop is not found.

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-08-07 09:49:04 -04:00
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