On Tue, Mar 06, 2007 at 10:23:44AM +0100, Eric Dumazet wrote: > On Tuesday 06 March 2007 10:11, Nick Piggin wrote: > > > Cool! I have some fixes for the rcu barrier issues, with some C-style > > comments and questions :) > > > > I was going to send you a fix first for the rcu barriers, then a > > second to convert the read-side to a barrier-less one that I described, > > however considering that your patch is a WIP in progress anyway, I > > won't worry too much about the normal protocol. > > > > I _think_ my reasoning regarding the rcu barriers and grace periods > > is correct. I'll keep thinking about it though. (Paul cc'ed). > > > > I'm not so familiar with this code, so I have sprinkled around a lot > > of comments that could be pure crap ;) They are mainly just to help > > you ensure that you cover all bases... compile tested only at this > > stage. > > I think we missed : > > +static void rt_hash_resize_work(struct work_struct *work) > > + > + *head = rth->u.dst.rt_next; > + > + hash = rt_hashfn(rt_hash, > + rth->fl.fl4_dst, > + rth->fl.fl4_src, > + iface); > + rth->u.dst.rt_next = rt_hash->table[hash].chain; > + rt_hash->table[hash].chain = rth; > > This really needs some ..._del_rcu()/..._add_rcu()_ ... primitives, no ? > Or else a reader might be very confused...
I'm not sure... this code really depends on the hash table management, rather than the management of the hash tables, if you understand me ;) >From what I can _see_, this is similar to how rt_intern_hash does it. I don't know exactly why rt_intern_hash can get away without using rcu_assign_pointer in some cases, however: Note that we don't need an rcu_assign_pointer for this, because the memory operations that initialized the entry have already been ordered when it was first inserted. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
