[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150514205750.GH6776@linux.vnet.ibm.com>
Date: Thu, 14 May 2015 13:57:51 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
laijs@...fujitsu.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, josh@...htriplett.org,
tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
fweisbec@...il.com, oleg@...hat.com,
bobby prani <bobby.prani@...il.com>
Subject: Re: [PATCH tip/core/rcu 2/3] documentation: Update
rcu_dereference.txt based on WG21 discussions
On Wed, May 13, 2015 at 06:33:10PM +0000, Mathieu Desnoyers wrote:
> ----- Original Message -----
> > From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> >
> > This commit provides another caveat for the care and feeding of pointers
> > returned by rcu_dereference() that was pointed out in discussions within
> > the C++ standards committee.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
>
> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Thank you, applied.
> BTW, reading through rcu_dereference.txt, I found a nit:
>
> operatiors -> operators
Hmmm... Almost like I was trying (and spectacularly failing) to write
the document in French. ;-)
> Very interesting reading :)
Glad you liked it!
Thanx, Paul
> Thanks!
>
> Mathieu
>
> > ---
> > Documentation/RCU/rcu_dereference.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/RCU/rcu_dereference.txt
> > b/Documentation/RCU/rcu_dereference.txt
> > index ceb05da5a5ac..2d05c9241a33 100644
> > --- a/Documentation/RCU/rcu_dereference.txt
> > +++ b/Documentation/RCU/rcu_dereference.txt
> > @@ -193,6 +193,11 @@ o Be very careful about comparing pointers obtained from
> > pointer. Note that the volatile cast in rcu_dereference()
> > will normally prevent the compiler from knowing too much.
> >
> > + However, please note that if the compiler knows that the
> > + pointer takes on only one of two values, a not-equal
> > + comparison will provide exactly the information that the
> > + compiler needs to deduce the value of the pointer.
> > +
> > o Disable any value-speculation optimizations that your compiler
> > might provide, especially if you are making use of feedback-based
> > optimizations that take data collected from prior runs. Such
> > --
> > 1.8.1.5
> >
> >
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists