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
--
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
