| README.Locking (c1b054d03f5b31c33eaa0b267c629b118eaf3790) | README.Locking (8b0b339d46ca0105a9936e3caa3bac80b72de7a3) |
|---|---|
| 1 $Id: README.Locking,v 1.12 2005/04/13 13:22:35 dwmw2 Exp $ 2 3 JFFS2 LOCKING DOCUMENTATION 4 --------------------------- 5 6At least theoretically, JFFS2 does not require the Big Kernel Lock 7(BKL), which was always helpfully obtained for it by Linux 2.4 VFS 8code. It has its own locking, as described below. --- 136 unchanged lines hidden (view full) --- 145This read/write semaphore protects against concurrent access to the 146write-behind buffer ('wbuf') used for flash chips where we must write 147in blocks. It protects both the contents of the wbuf and the metadata 148which indicates which flash region (if any) is currently covered by 149the buffer. 150 151Ordering constraints: 152 Lock wbuf_sem last, after the alloc_sem or and f->sem. | 1 $Id: README.Locking,v 1.12 2005/04/13 13:22:35 dwmw2 Exp $ 2 3 JFFS2 LOCKING DOCUMENTATION 4 --------------------------- 5 6At least theoretically, JFFS2 does not require the Big Kernel Lock 7(BKL), which was always helpfully obtained for it by Linux 2.4 VFS 8code. It has its own locking, as described below. --- 136 unchanged lines hidden (view full) --- 145This read/write semaphore protects against concurrent access to the 146write-behind buffer ('wbuf') used for flash chips where we must write 147in blocks. It protects both the contents of the wbuf and the metadata 148which indicates which flash region (if any) is currently covered by 149the buffer. 150 151Ordering constraints: 152 Lock wbuf_sem last, after the alloc_sem or and f->sem. |
| 153 154 155 c->xattr_sem 156 ------------ 157 158This read/write semaphore protects against concurrent access to the 159xattr related objects which include stuff in superblock and ic->xref. 160In read-only path, write-semaphore is too much exclusion. It's enough 161by read-semaphore. But you must hold write-semaphore when updating, 162creating or deleting any xattr related object. 163 164Once xattr_sem released, there would be no assurance for the existence 165of those objects. Thus, a series of processes is often required to retry, 166when updating such a object is necessary under holding read semaphore. 167For example, do_jffs2_getxattr() holds read-semaphore to scan xref and 168xdatum at first. But it retries this process with holding write-semaphore 169after release read-semaphore, if it's necessary to load name/value pair 170from medium. 171 172Ordering constraints: 173 Lock xattr_sem last, after the alloc_sem. |
|