Re: [PATCH RFC tip/core/rcu] SRCU rewrite

[Lance Roy <ldr709@gmail.com>]

On Thu, 17 Nov 2016 23:07:02 +0800
Lai Jiangshan <jiangshanlai@gmail.com> wrote:

> On Thu, Nov 17, 2016 at 10:31 PM, Boqun Feng <boqun.feng@gmail.com> wrote:
> > After reading the comment for a while, I actually got a question, maybe
> > I miss something ;-)
> >
> > Why "at most NR_CPUS worth of readers using the old index haven't
> > incremented the counters" could save us from overflow the counter?
> >
> > Please consider the following case in current implementation:
> >
> >
> > {sp->completed = 0} so idx = 1 in srcu_advance_batches(...)
> >
> > one thread A is currently in __srcu_read_lock() and using idx = 1 and
> > about to increase the percpu c[idx], and ULONG_MAX __srcu_read_lock()s
> > have been called and returned with idx = 1, please note I think this is
> > possible because I assume we may have some code like this:
> >
> >         unsigned long i = 0;
> >         for (; i < ULONG_MAX; i++)
> >                 srcu_read_lock(); // return the same idx 1;  
> 
> this is the wrong usage of the api.
> 
> 
> you might rewrite it as:
> 
>         unsigned long index[2] = {0, 0};
>         unsigned long i = 0;
>         for (;  index[1] < ULONG_MAX; i++)
>                  index[srcu_read_lock()]++;
Doesn't this still fail the API by not nesting correctly? If you don't keep
track of the order the indices were returned in then it seems like you would
exit the critical sections in the wrong order.

Thanks,
Lance