[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1404846110.758430333@decadent.org.uk>
Date: Tue, 08 Jul 2014 20:01:50 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org,
"Laurence Withers" <lwithers@...alp.com>,
"hujianyang" <hujianyang@...wei.com>,
"Artem Bityutskiy" <artem.bityutskiy@...ux.intel.com>
Subject: [PATCH 3.2 004/125] UBIFS: fix an mmap and fsync race condition
3.2.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: hujianyang <hujianyang@...wei.com>
commit 691a7c6f28ac90cccd0dbcf81348ea90b211bdd0 upstream.
There is a race condition in UBIFS:
Thread A (mmap) Thread B (fsync)
->__do_fault ->write_cache_pages
-> ubifs_vm_page_mkwrite
-> budget_space
-> lock_page
-> release/convert_page_budget
-> SetPagePrivate
-> TestSetPageDirty
-> unlock_page
-> lock_page
-> TestClearPageDirty
-> ubifs_writepage
-> do_writepage
-> release_budget
-> ClearPagePrivate
-> unlock_page
-> !(ret & VM_FAULT_LOCKED)
-> lock_page
-> set_page_dirty
-> ubifs_set_page_dirty
-> TestSetPageDirty (set page dirty without budgeting)
-> unlock_page
This leads to situation where we have a diry page but no budget allocated for
this page, so further write-back may fail with -ENOSPC.
In this fix we return from page_mkwrite without performing unlock_page. We
return VM_FAULT_LOCKED instead. After doing this, the race above will not
happen.
Signed-off-by: hujianyang <hujianyang@...wei.com>
Tested-by: Laurence Withers <lwithers@...alp.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
fs/ubifs/file.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -1522,8 +1522,7 @@ static int ubifs_vm_page_mkwrite(struct
ubifs_release_dirty_inode_budget(c, ui);
}
- unlock_page(page);
- return 0;
+ return VM_FAULT_LOCKED;
out_unlock:
unlock_page(page);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists