Pull video into release branch

[linux-2.6-omap-h63xx.git] / fs / jffs2 / README.Locking

diff --git a/fs/jffs2/README.Locking b/fs/jffs2/README.Locking
index b7943439b6ec995cbe795603c91c63566526e211..d14d5a4dc5ac6f9a956fc1653e04de94079470e7 100644 (file)
--- a/fs/jffs2/README.Locking
+++ b/fs/jffs2/README.Locking
@@ -1,4 +1,3 @@
-       $Id: README.Locking,v 1.12 2005/04/13 13:22:35 dwmw2 Exp $
 
        JFFS2 LOCKING DOCUMENTATION
        ---------------------------
@@ -150,3 +149,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.