Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966875AbcCPLLw (ORCPT ); Wed, 16 Mar 2016 07:11:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:47387 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966577AbcCPK74 (ORCPT ); Wed, 16 Mar 2016 06:59:56 -0400 X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" From: Jiri Slaby To: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, David Woodhouse , Jiri Slaby Subject: [PATCH 3.12 21/58] jffs2: Fix page lock / f->sem deadlock Date: Wed, 16 Mar 2016 11:59:06 +0100 Message-Id: X-Mailer: git-send-email 2.7.3 In-Reply-To: <377b71e18f20d69b0df301ce7040554f40ba9651.1458125909.git.jslaby@suse.cz> References: <377b71e18f20d69b0df301ce7040554f40ba9651.1458125909.git.jslaby@suse.cz> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2902 Lines: 74 From: David Woodhouse 3.12-stable review patch. If anyone has any objections, please let me know. =============== commit 49e91e7079febe59a20ca885a87dd1c54240d0f1 upstream. With this fix, all code paths should now be obtaining the page lock before f->sem. Reported-by: Szabó Tamás Tested-by: Thomas Betker Signed-off-by: David Woodhouse Signed-off-by: Jiri Slaby --- fs/jffs2/README.Locking | 5 +---- fs/jffs2/gc.c | 17 ++++++++++------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/fs/jffs2/README.Locking b/fs/jffs2/README.Locking index 3ea36554107f..8918ac905a3b 100644 --- a/fs/jffs2/README.Locking +++ b/fs/jffs2/README.Locking @@ -2,10 +2,6 @@ JFFS2 LOCKING DOCUMENTATION --------------------------- -At least theoretically, JFFS2 does not require the Big Kernel Lock -(BKL), which was always helpfully obtained for it by Linux 2.4 VFS -code. It has its own locking, as described below. - This document attempts to describe the existing locking rules for JFFS2. It is not expected to remain perfectly up to date, but ought to be fairly close. @@ -69,6 +65,7 @@ Ordering constraints: any f->sem held. 2. Never attempt to lock two file mutexes in one thread. No ordering rules have been made for doing so. + 3. Never lock a page cache page with f->sem held. erase_completion_lock spinlock diff --git a/fs/jffs2/gc.c b/fs/jffs2/gc.c index 5a2dec2b064c..95d5880a63ee 100644 --- a/fs/jffs2/gc.c +++ b/fs/jffs2/gc.c @@ -1296,14 +1296,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.7.3