From: David Howells <dhowells@redhat.com>
To: paulmck@linux.vnet.ibm.com
Cc: dhowells@redhat.com, Eric Dumazet <eric.dumazet@gmail.com>,
Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] NFS: Fix RCU warnings in nfs_inode_return_delegation_noreclaim() [ver #2]
Date: Tue, 30 Mar 2010 17:37:49 +0100 [thread overview]
Message-ID: <2397.1269967069@redhat.com> (raw)
In-Reply-To: <20100329232636.GT2569@linux.vnet.ibm.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> rcu: Add update-side variant of rcu_dereference()
>
> Upcoming consistency-checking features are requiring that even update-side
> accesses to RCU-protected pointers use some variant of rcu_dereference().
> Even though rcu_dereference() is quite lightweight, it does constrain the
> compiler, thus producing code that is worse than required. This patch
> therefore adds rcu_dereference_update(), which allows lockdep-style
> checks for holding the correct update-side lock, but which does not
> constrain the compiler.
Ummm... I'm not so keen on the name for two reasons. Firstly, why shouldn't
the read side do:
struct foo {
struct bar *b;
};
void manage_bar(struct foo *f)
{
struct bar *b;
rcu_read_lock();
b = rcu_dereference(f->b);
if (b)
do_something_to_bar(b);
rcu_read_unlock();
}
void manage_foo(struct foo *f)
{
...
if (f->b)
manage_bar(f);
...
}
Why should this be limited to the update side?
Secondly, the name rcu_dereference_update() seems to imply that this function
itself does an update, perhaps after having done an rcu_dereference().
Perhaps rcu_pointer_valid()?
if (rcu_pointer_valid(f->b))
manage_bar(f);
or if you really do want to limit this sort of thing to the update side:
if (rcu_destination_for_update(f->b)) {
spin_lock(&f->lock);
update_bar(f);
spin_unlock(&f->lock);
}
Another possibility is have an 'RCU write lock' that just does the lockdep
thing and doesn't interpolate a barrier:
rcu_write_lock();
if (rcu_dereference_for_update(f->b)) {
spin_lock(&f->lock);
update_bar(f->b);
spin_unlock(&f->lock);
}
rcu_write_unlock();
Or might it make sense to roll together with the lock primitive:
if (rcu_dereference_and_lock(f->b, &f->lock)) {
update_bar(f);
spin_unlock(&f->lock);
}
(I'm not keen on that one because you might not want to take the lock
immediately, and you have a wide choice of locks).
Sorry to be picky.
David
next prev parent reply other threads:[~2010-03-30 16:38 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 13:33 [PATCH] NFS: Fix RCU warnings in nfs_inode_return_delegation_noreclaim() [ver #2] David Howells
[not found] ` <20100318133302.29754.1584.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2010-03-19 2:25 ` Paul E. McKenney
2010-03-19 2:25 ` Paul E. McKenney
2010-03-29 19:02 ` David Howells
2010-03-29 19:21 ` Paul E. McKenney
2010-03-29 20:15 ` David Howells
2010-03-29 20:26 ` Eric Dumazet
2010-03-29 20:26 ` Eric Dumazet
2010-03-29 21:05 ` Paul E. McKenney
2010-03-29 22:22 ` David Howells
2010-03-29 22:36 ` Paul E. McKenney
2010-03-29 22:59 ` David Howells
2010-03-29 23:26 ` Paul E. McKenney
2010-03-30 15:40 ` Paul E. McKenney
2010-03-30 16:39 ` David Howells
2010-03-30 16:49 ` Paul E. McKenney
2010-03-30 17:04 ` Eric Dumazet
2010-03-30 17:04 ` Eric Dumazet
2010-03-30 17:25 ` Paul E. McKenney
2010-03-30 17:25 ` Paul E. McKenney
2010-03-30 23:51 ` David Howells
2010-03-31 0:08 ` Paul E. McKenney
2010-03-31 14:04 ` David Howells
2010-03-31 15:16 ` Paul E. McKenney
2010-03-31 17:37 ` David Howells
2010-03-31 18:30 ` Paul E. McKenney
2010-03-31 18:32 ` Eric Dumazet
2010-03-31 18:32 ` Eric Dumazet
2010-03-31 22:53 ` David Howells
2010-04-01 1:29 ` Paul E. McKenney
2010-04-01 11:45 ` David Howells
2010-04-01 14:39 ` Paul E. McKenney
2010-04-01 14:46 ` David Howells
2010-04-05 17:57 ` Paul E. McKenney
2010-04-06 9:30 ` David Howells
2010-04-06 16:14 ` David Howells
2010-04-06 17:29 ` Paul E. McKenney
2010-04-06 19:34 ` David Howells
2010-04-07 0:02 ` Paul E. McKenney
2010-04-07 13:22 ` David Howells
2010-04-07 15:57 ` Paul E. McKenney
2010-04-07 16:35 ` RCU condition checks David Howells
2010-04-07 17:10 ` Paul E. McKenney
2010-04-11 22:57 ` Trond Myklebust
[not found] ` <1271026643.6620.37.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-04-12 16:47 ` Paul E. McKenney
2010-04-12 16:47 ` Paul E. McKenney
2010-03-30 16:37 ` David Howells [this message]
2010-03-30 17:01 ` [PATCH] NFS: Fix RCU warnings in nfs_inode_return_delegation_noreclaim() [ver #2] 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=2397.1269967069@redhat.com \
--to=dhowells@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/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.