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 <[email protected]>
---
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
Artem Savkov <[email protected]> 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
On Tue, Oct 04, 2016 at 04:43:31PM +0100, David Howells wrote:
> Artem Savkov <[email protected]> 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