[PATCH] Use proper lock in fscache_objlist_config.

[PATCH] Use proper lock in fscache_objlist_config.

[Artem Savkov]

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

Re: [PATCH] Use proper lock in fscache_objlist_config.

[David Howells]

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

Re: [PATCH] Use proper lock in fscache_objlist_config.

[Artem Savkov]

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