From: David Woodhouse <david.woodho...@intel.com>
With this fix, all code paths should now be obtaining the page lock before
f->sem.
Reported-by: Szabó Tamás <sztom...@gmail.com>
Tested-by: Thomas Betker <thomas.bet...@rohde-schwarz.com>
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
Cc: sta...@vger.kernel.org
10 7 cpukit/libfs/src/jffs2/src/gc.c
diff --git a/cpukit/libfs/src/jffs2/src/gc.c b/cpukit/libfs/src/jffs2/src/gc.c
index 22963dc3a6..2c945e7621 100644
--- a/cpukit/libfs/src/jffs2/src/gc.c
+++ b/cpukit/libfs/src/jffs2/src/gc.c
@@ -1304,14 +1304,17 @@ static int jffs2_garbage_collect_dnode(struct
jffs2_sb_info *c, struct jffs2_era
BUG_ON(start > orig_start);
}
- /* First, use readpage() to read the appropriate page into the page
cache */
- /* Q: What happens if we actually try to GC the _same_ page for which
commit_write()
- * triggered garbage collection in the first place?
- * A: I _think_ it's OK. read_cache_page shouldn't deadlock, we'll
write out the
- * page OK. We'll actually write it out again in commit_write, which
is a little
- * suboptimal, but at least we're correct.
- */
+ /* The rules state that we must obtain the page lock *before* f->sem, so
+ * drop f->sem temporarily. Since we also hold c->alloc_sem, nothing's
+ * actually going to *change* so we're safe; we only allow reading.
+ *
+ * It is important to note that jffs2_write_begin() will ensure that its
+ * page is marked Uptodate before allocating space. That means that if
we
+ * end up here trying to GC the *same* page that jffs2_write_begin() is
+ * trying to write out, read_cache_page() will not deadlock. */
+ mutex_unlock(&f->sem);
pg_ptr = jffs2_gc_fetch_page(c, f, start, &pg);
+ mutex_lock(&f->sem);
if (IS_ERR(pg_ptr)) {
pr_warn("read_cache_page() returned error: %ld\n",
--
2.13.7
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
