All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Junchang Wang <junchangwang@gmail.com>
Cc: perfbook@vger.kernel.org, akiyks@gmail.com
Subject: Re: Question about the detection of overflow in rcu_nest:rcu_read_lock()
Date: Sun, 28 Apr 2019 04:30:27 -0700	[thread overview]
Message-ID: <20190428113027.GK3923@linux.ibm.com> (raw)
In-Reply-To: <20190425092526.GA17338@PhD>

On Thu, Apr 25, 2019 at 05:25:28PM +0800, Junchang Wang wrote:
> Hi list,
> 
> I was reading rcu_nest.h and the code snippet (lines 59 - 63), which I believe
> is to detect the overflow of variable rcu_gp_ctr, confused me a lot. Can some
> of you shed light on that?

The "!= 0" and the end does look strange, no two ways about it!
Though this is a no-op, it should be fixed one way or another.

And I did write this some time ago, it appears...

> Specifically, what's the goal of line 60? Why should we compare the value of
> (rcu_gp_ctr - tmp) against "111 1111 0000 0000"? If I understand correctly,
> line 60 is to detect the scenario where rcu_gp_ctr has wrapped around and is
> currently smaller than variable tmp. If that is correct, should line 60 be the
> following?
> 
> 60             ((tmp - READ_ONCE(rcu_gp_ctr)) > RCU_GP_CTR_BOTTOM_BIT) {
> 
> Or did I misunderstand anything here? 

What is happening here is that between line 55, where rcu_gp_ctr is
loaded and line 57 where the store to *rrgp is done, the grace-period
mechanism is not aware that this reader exists.  If the grace-period
counter has advanced very far (nowhere near overflow), we want to start
over.  Yes, we could check for true overflow, but given that this should
be a rare event, there is little benefit (and some risk) to trying to
be exact.

This might be more clear with a macro set up specifically for this
purpose.  The value you have chosen would retry on any change in
rcu_gp_ctr, which is too strict.  It should be OK for it to get ahead
by 100 or so, hence the value I chose earlier.

The type of "rcu_gp_ctr" should be unsigned as well.  Signed overflow
is still undefined behavior in C.

The store into *rrgp should of course be WRITE_ONCE() because this value
is being read by other threads.

Probably other issues as well.

And thank you for looking at this!

							Thanx, Paul

>  40 static void rcu_read_lock(void)
>  41 {
>  42         long tmp;
>  43         long *rrgp;
>  44 
>  45         /*
>  46          * If this is the outermost RCU read-side critical section,
>  47          * copy the global grace-period counter.  In either case,
>  48          * increment the nesting count held in the low-order bits.
>  49          */
>  50 
>  51         rrgp = &__get_thread_var(rcu_reader_gp);
>  52 retry:
>  53         tmp = *rrgp;
>  54         if ((tmp & RCU_GP_CTR_NEST_MASK) == 0)
>  55                 tmp = READ_ONCE(rcu_gp_ctr);
>  56         tmp++;
>  57         *rrgp = tmp;
>  58         smp_mb();
>  59         if (((tmp & RCU_GP_CTR_NEST_MASK) == 1) &&
>  60             ((rcu_gp_ctr - tmp) > (RCU_GP_CTR_NEST_MASK << 8)) != 0) {
>  61                 (*rrgp)--;
>  62                 goto retry;
>  63         }
>  64 }
> 
> Thanks,
> --Junchang
> 


      reply	other threads:[~2019-04-28 21:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25  9:25 Question about the detection of overflow in rcu_nest:rcu_read_lock() Junchang Wang
2019-04-28 11:30 ` 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=20190428113027.GK3923@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=akiyks@gmail.com \
    --cc=junchangwang@gmail.com \
    --cc=perfbook@vger.kernel.org \
    /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.