In a previous code update one extra spin_lock operation was left untouched. Consequently, a deadlock could occur when looping through cache pages. With this update, the extra lock operation has been removed from the source code and the deadlock no longer occurs in the described situation.
Description of problem:
While auditing the diff between the normal RHEL7 kernel and the RHEL7 kernel-rt tree (git diff kernel-3.10.0-376.el7..kernel-rt-3.10.0-376.rt56.253.el7) I found this gem:
diff --git a/fs/fscache/page.c b/fs/fscache/page.c
index e1500bda3bfc..966aa4376037 100644
--- a/fs/fscache/page.c
+++ b/fs/fscache/page.c
@@ -887,6 +887,7 @@ void fscache_invalidate_writes(struct fscache_cookie *cookie)
for (i = n - 1; i >= 0; i--)
page_cache_release(results[i]);
+ spin_lock(&cookie->stores_lock);
}
_leave("");
This will lead to a deadlock, since normal RHEL7 kernel has also merged an
equivalent of db7a50353, and takes the spinlock as the first thing when going around the loop:
for (;;) {
spin_lock(&cookie->stores_lock);
n = radix_tree_gang_lookup_tag(&cookie->stores, results, 0,
ARRAY_SIZE(results),
FSCACHE_COOKIE_PENDING_TAG);
if (n == 0) {
spin_unlock(&cookie->stores_lock);
break;
}
for (i = n - 1; i >= 0; i--) {
page = results[i];
radix_tree_delete(&cookie->stores, page->index);
}
spin_unlock(&cookie->stores_lock);
for (i = n - 1; i >= 0; i--)
page_cache_release(results[i]);
spin_lock(&cookie->stores_lock);
}
Version-Release number of selected component (if applicable):
kernel-rt-3.10.0-376.rt56.253.el7
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHSA-2016-2584.html