On Wed, Apr 07, 2010 at 02:22:41PM +0100, David Howells wrote:
> Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>
> > +#define rcu_access_pointer(p, c) \
>
> Why is there a need for 'c'?
An example use is where rcu_access_pointer() is legal because we are
either initializing or cleaning up, so that no other CPU has access
to the pointer. In these cases, you might do something like:
q = rcu_access_pointer(p->a, p->refcnt == 0);
> > +#define rcu_dereference_protect(p, c) \
>
> I'd prefer rcu_dereference_protected(), I think. This macro doesn't protect
> anything. Also, again, why the need for 'c'?
Agreed on rcu_dereference_protected(). I succumbed to a fit of "make
the identifier shorter", please accept my apologies.
> For instance, in:
>
> static struct nfs_delegation *nfs_detach_delegation_locked(struct nfs_inode *nfsi, const nfs4_stateid *stateid)
> {
> struct nfs_delegation *delegation =
> rcu_dereference_protected(nfsi->delegation, ????);
>
> what would be the condition? That the spinlock is held? That's a condition
> for calling the function.
Yep, that the spinlock is held. I agree that it is a bit obvious in
this case, but I have come across a number of RCU uses where the lock
in question was acquired many function calls removed from the access,
and where there other locks were held for other purposes.
> And in:
>
> void nfs_inode_return_delegation_noreclaim(struct inode *inode)
> {
> struct nfs_client *clp = NFS_SERVER(inode)->nfs_client;
> struct nfs_inode *nfsi = NFS_I(inode);
> struct nfs_delegation *delegation;
>
> if (rcu_access_pointer(nfsi->delegation, ????) != NULL) {
>
> what would be the condition here? There's no lock to check - that's the whole
> point of the macro. I also can't give it nfsi->delegation to check as the
> value may change between the two accesses.
I suggest something like the following:
/* protected by double-check lock pattern. */
if (rcu_access_pointer(nfsi->delegation, 1) != NULL) {
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
