Re: [PATCH] mac80211: Fix regression that allowed mpaths between non-peers.

[Johannes Berg <johannes@sipsolutions.net>]

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@cozybit.com>
> ---
>  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