[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151007142042.GE3910@linux.vnet.ibm.com>
Date: Wed, 7 Oct 2015 07:20:42 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH tip/core/rcu 10/13] rcu: Add rcu_pointer_handoff()
On Wed, Oct 07, 2015 at 09:22:27AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 06, 2015 at 02:02:43PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 06, 2015 at 10:27:41PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 06, 2015 at 09:13:45AM -0700, Paul E. McKenney wrote:
> > > > /**
> > > > + * rcu_pointer_handoff() - Hand off a pointer from RCU to other mechanism
> > > > + * @p: The pointer to hand off
> > > > + *
> > > > + * This is simply an identity function, but it documents where a pointer
> > > > + * is handed off from RCU to some other synchronization mechanism, for
> > > > + * example, reference counting or locking. In C11, it would map to
> > > > + * kill_dependency(). It could be used as follows:
> > > > + *
> > > > + * rcu_read_lock();
> > > > + * p = rcu_dereference(gp);
> > > > + * long_lived = is_long_lived(p);
> > > > + * if (long_lived) {
> > > > + * if (!atomic_inc_not_zero(p->refcnt))
> > > > + * long_lived = false;
> > > > + * else
> > > > + * p = rcu_pointer_handoff(p);
> > > > + * }
> > > > + * rcu_read_unlock();
> > > > + */
> > > > +#define rcu_pointer_handoff(p) (p)
> > >
> > > Will you actually be using this? It seems a tad pointless to add if you
> > > don't.
> >
> > Some of the LLVM guys believe that they can diagnose RCU pointer leaks
> > if this is used. But yes, it does need to be used.
>
> The thing is, I'm not convinced this is a 'sane' interface. Its _far_
> too easy to forget. It doesn't make any kind of sense either, which is
> part of why its hard to remember.
Indeed, the only thing that would make it easy to remember is if there are
tools that check for pointer leaks from RCU read-side critical sections.
But without this interface, such tools are insanely difficult to create.
So there is a chicken-and-egg problem here, which I am attempting to
deal with by providing an egg. Hopefully not laying an egg, but time
will tell. ;-)
Thanx, Paul
--
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