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. | ||