From: KaiGai Kohei Date: Sat, 13 May 2006 06:14:14 +0000 (+0900) Subject: [JFFS2][XATTR] Add a description about c->xattr_sem X-Git-Url: https://git.karo-electronics.de/?a=commitdiff_plain;h=8b0b339d46ca0105a9936e3caa3bac80b72de7a3;p=linux-beck.git [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 --- diff --git a/fs/jffs2/README.Locking b/fs/jffs2/README.Locking index b7943439b6ec..c8f0bd64e53e 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.