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

[Manfred Spraul]

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.
>  
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/