All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Howells <dhowells@redhat.com>,
	Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] rcu: add rcu_access_pointer and rcu_dereference_protect
Date: Wed, 7 Apr 2010 08:59:29 -0700	[thread overview]
Message-ID: <20100407155929.GB2481@linux.vnet.ibm.com> (raw)
In-Reply-To: <1270652210.8141.9.camel@edumazet-laptop>

On Wed, Apr 07, 2010 at 04:56:50PM +0200, Eric Dumazet wrote:
> Le mercredi 07 avril 2010 =E0 14:57 +0100, David Howells a =E9crit :
> > From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >=20
> > This patch adds variants of rcu_dereference() that handle situation=
s
> > where the RCU-protected data structure cannot change, perhaps due t=
o
> > our holding the update-side lock, or where the RCU-protected pointe=
r is
> > only to be fetched, not dereferenced.
> >=20
> > The new rcu_access_pointer() primitive is for the case where the po=
inter
> > is be fetch and not dereferenced.  This primitive may be used witho=
ut
> > protection, RCU or otherwise, due to the fact that it uses ACCESS_O=
NCE().
> >=20
> > The new rcu_dereference_protect() primitive is for the case where u=
pdates
> > are prevented, for example, due to holding the update-side lock.  T=
his
> > primitive does neither ACCESS_ONCE() nor smp_read_barrier_depends()=
, so
> > can only be used when updates are somehow prevented.
> >=20
> > Suggested-by: David Howells <dhowells@redhat.com>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Signed-off-by: David Howells <dhowells@redhat.com>
> > ---
> >=20
> >  include/linux/rcupdate.h |   34 ++++++++++++++++++++++++++++++++++
> >  1 files changed, 34 insertions(+), 0 deletions(-)
> >=20
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 872a98e..a1b14b6 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -209,9 +209,43 @@ static inline int rcu_read_lock_sched_held(voi=
d)
> >  		rcu_dereference_raw(p); \
> >  	})
> > =20
> > +/**
> > + * rcu_access_pointer - fetch RCU pointer with no dereferencing
> > + *
> > + * Return the value of the specified RCU-protected pointer, but om=
it the
> > + * smp_read_barrier_depends() and keep the ACCESS_ONCE().  This is=
 useful
> > + * when the value of this pointer is accessed, but the pointer is =
not
> > + * dereferenced, for example, when testing an RCU-protected pointe=
r against
> > + * NULL.  This may also be used in cases where update-side locks p=
revent
> > + * the value of the pointer from changing, but rcu_dereference_pro=
tect()
> > + * is a lighter-weight primitive for this use case.
> > + */
> > +#define rcu_access_pointer(p) \
> > +	({ \
> > +		ACCESS_ONCE(p); \
> > +	})
> > +
> > +/**
> > + * rcu_dereference_protected - fetch RCU pointer when updates prev=
ented
> > + *
> > + * Return the value of the specified RCU-protected pointer, but om=
it
> > + * both the smp_read_barrier_depends() and the ACCESS_ONCE().  Thi=
s
> > + * is useful in cases where update-side locks prevent the value of=
 the
> > + * pointer from changing.  Please note that this primitive does -n=
ot-
> > + * prevent the compiler from repeating this reference or combining=
 it
> > + * with other references, so it should not be used without protect=
ion
> > + * of appropriate locks.
> > + */
> > +#define rcu_dereference_protected(p) \
> > +	({ \
> > +		(p); \
> > +	})
> > +
> >  #else /* #ifdef CONFIG_PROVE_RCU */
> > =20
> >  #define rcu_dereference_check(p, c)	rcu_dereference_raw(p)
> > +#define rcu_access_pointer(p)		ACCESS_ONCE(p)
> > +#define rcu_dereference_protect(p)	(p)
> > =20
> >  #endif /* #else #ifdef CONFIG_PROVE_RCU */
> > =20
> >=20
> > --
>=20
> This is not the version Paul posted.=20

I blew the name -- rcu_dereference_protected() is in fact a better name=
=2E

> Removing checks just to shutup warnings ?
>=20
> All the point is to get lockdep assistance, and you throw it away.
>=20
> We want to explicit the condition, so that RCU users can explicitly
> state what protects their data.

What Eric said!!!  ;-)

							Thanx, Paul

WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Howells <dhowells@redhat.com>,
	Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] rcu: add rcu_access_pointer and rcu_dereference_protect
Date: Wed, 7 Apr 2010 08:59:29 -0700	[thread overview]
Message-ID: <20100407155929.GB2481@linux.vnet.ibm.com> (raw)
In-Reply-To: <1270652210.8141.9.camel@edumazet-laptop>

On Wed, Apr 07, 2010 at 04:56:50PM +0200, Eric Dumazet wrote:
> Le mercredi 07 avril 2010 à 14:57 +0100, David Howells a écrit :
> > From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > This patch adds variants of rcu_dereference() that handle situations
> > where the RCU-protected data structure cannot change, perhaps due to
> > our holding the update-side lock, or where the RCU-protected pointer is
> > only to be fetched, not dereferenced.
> > 
> > The new rcu_access_pointer() primitive is for the case where the pointer
> > is be fetch and not dereferenced.  This primitive may be used without
> > protection, RCU or otherwise, due to the fact that it uses ACCESS_ONCE().
> > 
> > The new rcu_dereference_protect() primitive is for the case where updates
> > are prevented, for example, due to holding the update-side lock.  This
> > primitive does neither ACCESS_ONCE() nor smp_read_barrier_depends(), so
> > can only be used when updates are somehow prevented.
> > 
> > Suggested-by: David Howells <dhowells@redhat.com>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Signed-off-by: David Howells <dhowells@redhat.com>
> > ---
> > 
> >  include/linux/rcupdate.h |   34 ++++++++++++++++++++++++++++++++++
> >  1 files changed, 34 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 872a98e..a1b14b6 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -209,9 +209,43 @@ static inline int rcu_read_lock_sched_held(void)
> >  		rcu_dereference_raw(p); \
> >  	})
> >  
> > +/**
> > + * rcu_access_pointer - fetch RCU pointer with no dereferencing
> > + *
> > + * Return the value of the specified RCU-protected pointer, but omit the
> > + * smp_read_barrier_depends() and keep the ACCESS_ONCE().  This is useful
> > + * when the value of this pointer is accessed, but the pointer is not
> > + * dereferenced, for example, when testing an RCU-protected pointer against
> > + * NULL.  This may also be used in cases where update-side locks prevent
> > + * the value of the pointer from changing, but rcu_dereference_protect()
> > + * is a lighter-weight primitive for this use case.
> > + */
> > +#define rcu_access_pointer(p) \
> > +	({ \
> > +		ACCESS_ONCE(p); \
> > +	})
> > +
> > +/**
> > + * rcu_dereference_protected - fetch RCU pointer when updates prevented
> > + *
> > + * Return the value of the specified RCU-protected pointer, but omit
> > + * both the smp_read_barrier_depends() and the ACCESS_ONCE().  This
> > + * is useful in cases where update-side locks prevent the value of the
> > + * pointer from changing.  Please note that this primitive does -not-
> > + * prevent the compiler from repeating this reference or combining it
> > + * with other references, so it should not be used without protection
> > + * of appropriate locks.
> > + */
> > +#define rcu_dereference_protected(p) \
> > +	({ \
> > +		(p); \
> > +	})
> > +
> >  #else /* #ifdef CONFIG_PROVE_RCU */
> >  
> >  #define rcu_dereference_check(p, c)	rcu_dereference_raw(p)
> > +#define rcu_access_pointer(p)		ACCESS_ONCE(p)
> > +#define rcu_dereference_protect(p)	(p)
> >  
> >  #endif /* #else #ifdef CONFIG_PROVE_RCU */
> >  
> > 
> > --
> 
> This is not the version Paul posted. 

I blew the name -- rcu_dereference_protected() is in fact a better name.

> Removing checks just to shutup warnings ?
> 
> All the point is to get lockdep assistance, and you throw it away.
> 
> We want to explicit the condition, so that RCU users can explicitly
> state what protects their data.

What Eric said!!!  ;-)

							Thanx, Paul

  parent reply	other threads:[~2010-04-07 15:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-07 13:57 [PATCH 1/2] rcu: add rcu_access_pointer and rcu_dereference_protect David Howells
     [not found] ` <20100407135732.12414.16416.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2010-04-07 13:57   ` [PATCH 2/2] NFS: Fix RCU warnings in nfs_inode_return_delegation_noreclaim() David Howells
2010-04-07 13:57     ` David Howells
2010-04-07 14:56   ` [PATCH 1/2] rcu: add rcu_access_pointer and rcu_dereference_protect Eric Dumazet
2010-04-07 14:56     ` Eric Dumazet
2010-04-07 15:40     ` David Howells
2010-04-07 16:00       ` Eric Dumazet
2010-04-07 16:00         ` Eric Dumazet
2010-04-07 16:19         ` David Howells
2010-04-07 16:29           ` Eric Dumazet
2010-04-07 16:29             ` Eric Dumazet
2010-04-07 16:35           ` Eric Dumazet
2010-04-07 16:35             ` Eric Dumazet
2010-04-07 15:59     ` Paul E. McKenney [this message]
2010-04-07 15:59       ` Paul E. McKenney

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=20100407155929.GB2481@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=dhowells@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@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.