Re: [PATCH v2 3/3] mac80211: Unify mesh and mpp path removal function

[Bob Copeland <me@bobcopeland.com>]

On Fri, Jan 29, 2016 at 11:08:58AM +0100, Henning Rogge wrote:
> mpp_path_del() and mesh_path_del() are mostly the same function.
> Move common code into a new static function.
> 
> Signed-off-by: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
> ---
>  net/mac80211/mesh_pathtbl.c | 110 ++++++++++++++++++++++----------------------
>  1 file changed, 55 insertions(+), 55 deletions(-)
> 
> diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
> index 33bb1f25..86316ee 100644
> --- a/net/mac80211/mesh_pathtbl.c
> +++ b/net/mac80211/mesh_pathtbl.c
> @@ -55,16 +55,20 @@ int mpp_paths_generation;
>  static DEFINE_RWLOCK(pathtbl_resize_lock);
>  
>  
> +static inline struct mesh_table *resize_dereference_paths(struct mesh_table *table)

0-day caught this -- the parameter should be "struct mesh_table __rcu *table"

You can install sparse, set CONFIG_SPARSE_RCU_POINTER=y and then check it
with something like:

        make C=2 M=net/mac80211

The code is ok but the annotation catches cases where a dereference
would happen without the right lock -- in this case pathtable resize
lock is held.

> +{
> +  return rcu_dereference_protected(table,
> +    lockdep_is_held(&pathtbl_resize_lock));
> +}
> +

Besides that though, something is wrong with whitespace throughout
the patch, looks like lots of 2-space indents instead of tabs.

Approach looks fine though.  I might've moved the resize lock into
table_path_del, but it doesn't really matter as I plan to replace
with rhashtable anyway.

-- 
Bob Copeland %% http://bobcopeland.com/