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

[Manfred Spraul <manfred@colorfullife.com>]

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