It's possible for a request to invalidate a fscache_cookie will come in while we're already processing an invalidation. If that happens we currently take an extra access reference that will leak. Only call __fscache_begin_cookie_access if the FSCACHE_COOKIE_DO_INVALIDATE bit was previously clear. Suggested-by: David Howells <dhowells@xxxxxxxxxx> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> --- fs/fscache/cookie.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fscache/cookie.c b/fs/fscache/cookie.c index 74920826d8f6..8b1499be3d62 100644 --- a/fs/fscache/cookie.c +++ b/fs/fscache/cookie.c @@ -1063,8 +1063,8 @@ void __fscache_invalidate(struct fscache_cookie *cookie, return; case FSCACHE_COOKIE_STATE_LOOKING_UP: - __fscache_begin_cookie_access(cookie, fscache_access_invalidate_cookie); - set_bit(FSCACHE_COOKIE_DO_INVALIDATE, &cookie->flags); + if (!test_and_set_bit(FSCACHE_COOKIE_DO_INVALIDATE, &cookie->flags)) + __fscache_begin_cookie_access(cookie, fscache_access_invalidate_cookie); fallthrough; case FSCACHE_COOKIE_STATE_CREATING: spin_unlock(&cookie->lock); -- 2.37.1 -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
