lkml.org 
[lkml]   [2018]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/3] rhashtable: further improve stability of rhashtable_walk
From
Date
On Fri, 2018-07-06 at 19:55 +1000, NeilBrown wrote:
> On Fri, Jul 06 2018, Paolo Abeni wrote:
>
> > Note: the code under test is a pending new patch I'm holding due to the
> > above issue, I can send it as RFC to share the code if you think it may
> > help.
>
> I'd suggest post it. I may not get a chance to look at it, but if you
> don't post it, then I definitely won't :-)

Oks, thanks, I just spammed the list (and you ;)

> > > @@ -867,15 +866,39 @@ void *rhashtable_walk_next(struct rhashtable_iter *iter)
> > > bool rhlist = ht->rhlist;
> > >
> > > if (p) {
> > > - if (!rhlist || !(list = rcu_dereference(list->next))) {
> > > - p = rcu_dereference(p->next);
> > > - list = container_of(p, struct rhlist_head, rhead);
> > > - }
> > > - if (!rht_is_a_nulls(p)) {
> > > - iter->skip++;
> > > - iter->p = p;
> > > - iter->list = list;
> > > - return rht_obj(ht, rhlist ? &list->rhead : p);
> > > + if (!rhlist && iter->p_is_unsafe) {
> > > + /*
> > > + * First time next() was called after start().
> > > + * Need to find location of 'p' in the list.
> > > + */
> > > + struct rhash_head *p;
> > > +
> > > + iter->skip = 0;
> > > + rht_for_each_rcu(p, iter->walker.tbl, iter->slot) {
> > > + iter->skip++;
> > > + if (p <= iter->p)
> > > + continue;
> >
> > Out of sheer ignorance, I really don't understand the goal of the above
> > conditional ?!?
>
> I hoped the patch description would cover that:
> With this patch:
> - a new object is always inserted after the last object with a
> smaller address, or at the start. This preserves the property,
> important when allowing objects to be removed and re-added, that
> an object is never inserted *after* a position that it previously
> held in the list.
>
> The items in each table slot are stored in order of the address of the
> item. So to find the first item in a slot that was not before the
> previously returned item (iter->p), we step forward while this item is
> <= that one.
>
> Does that help at all?

Yes, it's very clear. Before I dumbly skipped some slices of the patch.

Thanks,

Paolo

\
 
 \ /
  Last update: 2018-07-06 12:13    [W:0.073 / U:1.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site