Re: [Lse-tech] [RFC, PATCH] 2/5 rcu lock update: Use a sequence lock for starting batches

From: Paul E. McKenney
Date: Fri May 28 2004 - 11:33:36 EST


On Fri, May 28, 2004 at 03:57:07PM +0200, Manfred Spraul wrote:
> Paul E. McKenney wrote:
>
> >Hello, Manfred,
> >
> >I am still digging through these, and things look quite good in general,
> >but I have a question on your second patch.

Sorry for the bother, will keep looking, hopefully with more accurate
comments in the future. :-/

Thanx, Paul

> Let's assume that
>
> batch.completed = 5;
> batch.cur = 5;
> batch.next_pending = 0;
>
> >Given the following sequence of events:
> >
> >1. CPU 0 executes the
> >
> > rcu_ctrlblk.batch.next_pending = 1;
> >
> >
> batch.next_pending = 1.
>
> > at the beginning of rcu_start_batch().
> >
> >2. CPU 1 executes the read_seqcount code sequence in
> > rcu_process_callbacks(), setting RCU_batch(cpu) to
> > the next batch number, and setting next_pending to 1.
> >
> >
> RCU_batch(1) is now 6.
> next_pending is 1, rcu_process_callbacks continues without calling
> rcu_start_batch().
>
> >3. CPU 0 executes the remainder of rcu_start_batch(),
> > setting rcu_ctrlblk.batch.next_pending to 0 and
> > incrementing rcu_ctrlblk.batch.cur.
> >
> >
> batch.cur = 6.
>
> >4. CPU 1's state is now as if the grace period had already
> > completed for the callbacks that were just moved to
> > RCU_curlist(), which would be very bad.
> >
> >
> AFAICS: No. RCU_batch(1) is 6 and rcu_ctrlblk.batch.completed is still
> 5. The test for grace period completed is
>
> > if (!list_empty(&RCU_curlist(cpu)) &&
> >
> >!rcu_batch_before(rcu_ctrlblk.batch.completed,RCU_batch(cpu))) {
> > __list_splice(&RCU_curlist(cpu), &list);
> > INIT_LIST_HEAD(&RCU_curlist(cpu));
> > }
>
> 5 is before 6, thus the callbacks won't be processed.
>
> The only write operation to rcu_ctrlblk.batch.completed is in cpu_quiet,
> after checking that the cpu bitmap is empty and under
> spin_lock(rcu_ctrlblk.state.mutex).
>
> Thanks for looking at my patches,
>
> --
> Manfred
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/