All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Manfred Spraul <manfred@dbl.q-ag.de>,
	linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net
Subject: Re: [Lse-tech] [RFC, PATCH] 2/5 rcu lock update: Use a sequence lock for starting batches
Date: Fri, 28 May 2004 09:28:19 -0700	[thread overview]
Message-ID: <20040528162818.GA1242@us.ibm.com> (raw)
In-Reply-To: <40B74533.1060608@colorfullife.com>

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

      reply	other threads:[~2004-05-28 16:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-25  5:35 [RFC, PATCH] 2/5 rcu lock update: Use a sequence lock for starting batches Manfred Spraul
2004-05-27 23:22 ` [Lse-tech] " Paul E. McKenney
2004-05-28 13:57   ` Manfred Spraul
2004-05-28 16:28     ` Paul E. McKenney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040528162818.GA1242@us.ibm.com \
    --to=paulmck@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=manfred@colorfullife.com \
    --cc=manfred@dbl.q-ag.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.