On Thu, 2011-10-06 at 14:54 -0700, Javier Cardona wrote:
> Mesh paths should only exist over established peer links.
>
> Signed-off-by: Javier Cardona <javier@xxxxxxxxxxx>
> ---
> net/mac80211/mesh_hwmp.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
> index 6df7913..174040a 100644
> --- a/net/mac80211/mesh_hwmp.c
> +++ b/net/mac80211/mesh_hwmp.c
> @@ -789,11 +789,20 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data *sdata,
> struct ieee802_11_elems elems;
> size_t baselen;
> u32 last_hop_metric;
> + struct sta_info *sta;
>
> /* need action_code */
> if (len < IEEE80211_MIN_ACTION_SIZE + 1)
> return;
>
> + rcu_read_lock();
> + sta = sta_info_get(sdata, mgmt->sa);
> + if (!sta || sta->plink_state != NL80211_PLINK_ESTAB) {
> + rcu_read_unlock();
> + return;
> + }
> + rcu_read_unlock();
> +
No real objections to this patch as I'm sure this is how it works, but I
do wonder ... if a mesh path (mesh_path_add right?) can only exist with
a nexthop peer, how is all this correct when their lifetime isn't tied
together? Yes, mesh_path is flushed when sta_info dies, but there can be
mesh_path w/o a next_hop. How can that be correct?
Or put another way: what guarantees that the sta you find above will be
assigned next_hop for the path? Couldn't it have been deleted by that
time since you don't hang on to the pointer here?
Or am I completely misunderstanding this?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
