On 10/01, Paul E. McKenney wrote: > > On Sun, Sep 29, 2013 at 03:56:46PM +0200, Oleg Nesterov wrote: > > On 09/27, Oleg Nesterov wrote: > > > > > > I tried hard to find any hole in this version but failed, I believe it > > > is correct. > > > > And I still believe it is. But now I am starting to think that we > > don't need cpuhp_seq. (and imo cpuhp_waitcount, but this is minor). > > Here is one scenario that I believe requires cpuhp_seq: > > 1. Task 0 on CPU 0 increments its counter on entry. > > 2. Task 1 on CPU 1 starts summing the counters and gets to > CPU 4. The sum thus far is 1 (Task 0). > > 3. Task 2 on CPU 2 increments its counter on entry. > Upon completing its entry code, it re-enables preemption.
afaics at this stage it should notice state = BLOCK and decrement the same counter on the same CPU before it does preempt_enable(). Because: > > 2. It is the reader which tries to take this lock and > > noticed state == BLOCK. We could miss the result of > > its inc(), but we do not care, this reader is going > > to block. > > > > _If_ the reader could migrate between inc/dec, then > > yes, we have a problem. Because that dec() could make > > the result of per_cpu_sum() = 0. IOW, we could miss > > inc() but notice dec(). But given that it does this > > on the same CPU this is not possible. > > > > So why do we need cpuhp_seq? > > Good question, I will look again. Thanks! much appreciated. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
