[JFFS2][XATTR] Add a description about c->xattr_sem
Linux-MTD Mailing List
linux-mtd at lists.infradead.org
Sun May 21 14:59:04 EDT 2006
Commit: 8b0b339d46ca0105a9936e3caa3bac80b72de7a3
Parent: de1f72fab35d2b6215017690c6dc27b8f4aa14bc
Author: KaiGai Kohei <kaigai at ak.jp.nec.com>
AuthorDate: Sat May 13 15:14:14 2006 +0900
Commit: KaiGai Kohei <kaigai at ak.jp.nec.com>
CommitDate: Sat May 13 15:14:14 2006 +0900
[JFFS2][XATTR] Add a description about c->xattr_sem
Add a description about the c->xattr_sem read/write semaphore
into README.Locking.
[3/10] jffs2-xattr-v5.1-03-append_README.Locking.patch
Signed-off-by: KaiGai Kohei <kaigai at ak.jp.nec.com>
fs/jffs2/README.Locking | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/fs/jffs2/README.Locking b/fs/jffs2/README.Locking
index b794343..c8f0bd6 100644
--- a/fs/jffs2/README.Locking
+++ b/fs/jffs2/README.Locking
@@ -150,3 +150,24 @@ the buffer.
Ordering constraints:
Lock wbuf_sem last, after the alloc_sem or and f->sem.
+
+
+ c->xattr_sem
+ ------------
+
+This read/write semaphore protects against concurrent access to the
+xattr related objects which include stuff in superblock and ic->xref.
+In read-only path, write-semaphore is too much exclusion. It's enough
+by read-semaphore. But you must hold write-semaphore when updating,
+creating or deleting any xattr related object.
+
+Once xattr_sem released, there would be no assurance for the existence
+of those objects. Thus, a series of processes is often required to retry,
+when updating such a object is necessary under holding read semaphore.
+For example, do_jffs2_getxattr() holds read-semaphore to scan xref and
+xdatum at first. But it retries this process with holding write-semaphore
+after release read-semaphore, if it's necessary to load name/value pair
+from medium.
+
+Ordering constraints:
+ Lock xattr_sem last, after the alloc_sem.
More information about the linux-mtd-cvs
mailing list