diff options
| -rw-r--r-- | 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 b7943439b6ec..c8f0bd64e53e 100644 --- a/fs/jffs2/README.Locking +++ b/fs/jffs2/README.Locking | |||
| @@ -150,3 +150,24 @@ the buffer. | |||
| 150 | 150 | ||
| 151 | Ordering constraints: | 151 | Ordering constraints: |
| 152 | Lock wbuf_sem last, after the alloc_sem or and f->sem. | 152 | Lock wbuf_sem last, after the alloc_sem or and f->sem. |
| 153 | |||
| 154 | |||
| 155 | c->xattr_sem | ||
| 156 | ------------ | ||
| 157 | |||
| 158 | This read/write semaphore protects against concurrent access to the | ||
| 159 | xattr related objects which include stuff in superblock and ic->xref. | ||
| 160 | In read-only path, write-semaphore is too much exclusion. It's enough | ||
| 161 | by read-semaphore. But you must hold write-semaphore when updating, | ||
| 162 | creating or deleting any xattr related object. | ||
| 163 | |||
| 164 | Once xattr_sem released, there would be no assurance for the existence | ||
| 165 | of those objects. Thus, a series of processes is often required to retry, | ||
| 166 | when updating such a object is necessary under holding read semaphore. | ||
| 167 | For example, do_jffs2_getxattr() holds read-semaphore to scan xref and | ||
| 168 | xdatum at first. But it retries this process with holding write-semaphore | ||
| 169 | after release read-semaphore, if it's necessary to load name/value pair | ||
| 170 | from medium. | ||
| 171 | |||
| 172 | Ordering constraints: | ||
| 173 | Lock xattr_sem last, after the alloc_sem. | ||
