summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorkiran.modukuri <kiran.modukuri@gmail.com>2018-11-26 16:41:48 +0100
committerDavid Howells <dhowells@redhat.com>2018-11-28 14:19:20 +0100
commit3f2b7b9035107d6096ea438ea3d97dcf0481b6d2 (patch)
tree594e6595c42f3095a7e459fef8bc40a611c7cff4 /include
parentcachefiles: Fix an assertion failure when trying to update a failed object (diff)
downloadlinux-3f2b7b9035107d6096ea438ea3d97dcf0481b6d2.tar.xz
linux-3f2b7b9035107d6096ea438ea3d97dcf0481b6d2.zip
fscache: Fix race in fscache_op_complete() due to split atomic_sub & read
The code in fscache_retrieval_complete is using atomic_sub followed by an atomic_read: atomic_sub(n_pages, &op->n_pages); if (atomic_read(&op->n_pages) <= 0) fscache_op_complete(&op->op, true); This causes two threads doing a decrement of n_pages to race with each other seeing the op->refcount 0 at same time - and they end up calling fscache_op_complete() in both the threads leading to an assertion failure. Fix this by using atomic_sub_return_relaxed() instead of two calls. Note that I'm using 'relaxed' rather than, say, 'release' as there aren't multiple variables that appear to need ordering across the release. The oops looks something like: FS-Cache: Assertion failed FS-Cache: 0 > 0 is false ... kernel BUG at /usr/src/linux-4.4.0/fs/fscache/operation.c:449! ... Workqueue: fscache_operation fscache_op_work_func [fscache] ... RIP: 0010:[<ffffffffc037eacd>] fscache_op_complete+0x10d/0x180 [fscache] ... Call Trace: [<ffffffffc1464cf9>] cachefiles_read_copier+0x3a9/0x410 [cachefiles] [<ffffffffc037e272>] fscache_op_work_func+0x22/0x50 [fscache] [<ffffffff81096da0>] process_one_work+0x150/0x3f0 [<ffffffff8109751a>] worker_thread+0x11a/0x470 [<ffffffff81808e59>] ? __schedule+0x359/0x980 [<ffffffff81097400>] ? rescuer_thread+0x310/0x310 [<ffffffff8109cdd6>] kthread+0xd6/0xf0 [<ffffffff8109cd00>] ? kthread_park+0x60/0x60 [<ffffffff8180d0cf>] ret_from_fork+0x3f/0x70 [<ffffffff8109cd00>] ? kthread_park+0x60/0x60 This seen this in 4.4.x kernels and the same bug affects fscache in latest upstreams kernels. Fixes: 1bb4b7f98f36 ("FS-Cache: The retrieval remaining-pages counter needs to be atomic_t") Signed-off-by: Kiran Kumar Modukuri <kiran.modukuri@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com>
Diffstat (limited to 'include')
-rw-r--r--include/linux/fscache-cache.h3
1 files changed, 1 insertions, 2 deletions
diff --git a/include/linux/fscache-cache.h b/include/linux/fscache-cache.h
index 34cf0fdd7dc7..610815e3f1aa 100644
--- a/include/linux/fscache-cache.h
+++ b/include/linux/fscache-cache.h
@@ -196,8 +196,7 @@ static inline void fscache_enqueue_retrieval(struct fscache_retrieval *op)
static inline void fscache_retrieval_complete(struct fscache_retrieval *op,
int n_pages)
{
- atomic_sub(n_pages, &op->n_pages);
- if (atomic_read(&op->n_pages) <= 0)
+ if (atomic_sub_return_relaxed(n_pages, &op->n_pages) <= 0)
fscache_op_complete(&op->op, false);
}