Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1495435 > unrolled thread
| Started by | Artem Savkov <asavkov@redhat.com> |
|---|---|
| First post | 2016-10-04 15:40 +0200 |
| Last post | 2016-10-04 18:00 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] Use proper lock in fscache_objlist_config. Artem Savkov <asavkov@redhat.com> - 2016-10-04 15:40 +0200
Re: [PATCH] Use proper lock in fscache_objlist_config. David Howells <dhowells@redhat.com> - 2016-10-04 17:50 +0200
Re: [PATCH] Use proper lock in fscache_objlist_config. Artem Savkov <asavkov@redhat.com> - 2016-10-04 18:00 +0200
| From | Artem Savkov <asavkov@redhat.com> |
|---|---|
| Date | 2016-10-04 15:40 +0200 |
| Subject | [PATCH] Use proper lock in fscache_objlist_config. |
| Message-ID | <soy6R-3iO-15@gated-at.bofh.it> |
fscache_objlist_config doesn't hold rkey->sem when calling user_key_payload, that can result in a "suspicious RCU usage" warning. It does hold rcu_read_lock, so it either needs to use unprotected rcu_dereference, or take rkey->sem instead of rcu_read_lock. Signed-off-by: Artem Savkov <asavkov@redhat.com> --- fs/fscache/object-list.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fscache/object-list.c b/fs/fscache/object-list.c index 5d5ddaa..26c20e9 100644 --- a/fs/fscache/object-list.c +++ b/fs/fscache/object-list.c @@ -327,7 +327,7 @@ static void fscache_objlist_config(struct fscache_objlist_data *data) goto no_config; config = 0; - rcu_read_lock(); + down_read(&key->sem); confkey = user_key_payload(key); buf = confkey->data; @@ -349,7 +349,7 @@ static void fscache_objlist_config(struct fscache_objlist_data *data) } } - rcu_read_unlock(); + up_read(&key->sem); key_put(key); if (!(config & (FSCACHE_OBJLIST_CONFIG_COOKIE | FSCACHE_OBJLIST_CONFIG_NOCOOKIE))) -- 2.7.4
[toc] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-10-04 17:50 +0200 |
| Message-ID | <soA8F-4HM-5@gated-at.bofh.it> |
| In reply to | #1495435 |
Artem Savkov <asavkov@redhat.com> wrote: > fscache_objlist_config doesn't hold rkey->sem when calling user_key_payload, > that can result in a "suspicious RCU usage" warning. It does hold > rcu_read_lock, so it either needs to use unprotected rcu_dereference, > or take rkey->sem instead of rcu_read_lock. It shouldn't take key->sem. The RCU lock should be necessary as user_key_payload() wraps a call to rcu_dereference(). Did you encounter a lockdep report or did you visually inspect this? David
[toc] | [prev] | [next] | [standalone]
| From | Artem Savkov <asavkov@redhat.com> |
|---|---|
| Date | 2016-10-04 18:00 +0200 |
| Message-ID | <soAil-4L7-9@gated-at.bofh.it> |
| In reply to | #1495485 |
On Tue, Oct 04, 2016 at 04:43:31PM +0100, David Howells wrote: > Artem Savkov <asavkov@redhat.com> wrote: > > > fscache_objlist_config doesn't hold rkey->sem when calling user_key_payload, > > that can result in a "suspicious RCU usage" warning. It does hold > > rcu_read_lock, so it either needs to use unprotected rcu_dereference, > > or take rkey->sem instead of rcu_read_lock. > > It shouldn't take key->sem. The RCU lock should be necessary as > user_key_payload() wraps a call to rcu_dereference(). > > Did you encounter a lockdep report or did you visually inspect this? I didn't see a lockdep report for this one, I just assumed it would be the same as with the nfs_idmap_get_key case. -- Regards, Artem
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web