Re: [PATCH v2 6/8] mac80211: Consolidate {mesh,mpp}_path_flush into one function

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2011-08-29 at 11:36 -0700, Javier Cardona wrote:

> >> -     read_lock_bh(&pathtbl_resize_lock);
> >> -     tbl = rcu_dereference_protected(mpp_paths,
> >> -                                     lockdep_is_held(pathtbl_resize_lock));
> >> +     WARN_ON(!rcu_read_lock_held());
> >>       for_each_mesh_entry(tbl, p, node, i) {
> >>               mpath = node->mpath;
> >> +             if (mpath->sdata != sdata)
> >> +                     continue;
> >>               spin_lock_bh(&tbl->hashwlock[i]);
> >>               __mesh_path_del(tbl, node);
> >>               spin_unlock_bh(&tbl->hashwlock[i]);
> >>       }
> >> -     read_unlock_bh(&pathtbl_resize_lock);
> >>  }
> >
> > So what protects against the table being grown at the same time? A copy
> > will be made, but here you'll be iterating the old table -- which won't
> > crash or anything but is semantically incorrect.
> 
> You are right.  And I believe it actually may crash, given that the
> nodes we wanted to delete will still exist in the new table.  I'll
> re-spin right away.

Yes, it will crash just as before -- I was referring to this function
only. Due to RCU, this function will always have a valid "node" pointer,
but of course deleting that might not delete it from the right table...

johannes