1
  2	JFFS2 LOCKING DOCUMENTATION
  3	---------------------------
  4
 
 
 
 
  5This document attempts to describe the existing locking rules for
  6JFFS2. It is not expected to remain perfectly up to date, but ought to
  7be fairly close.
  8
  9
 10	alloc_sem
 11	---------
 12
 13The alloc_sem is a per-filesystem mutex, used primarily to ensure
 14contiguous allocation of space on the medium. It is automatically
 15obtained during space allocations (jffs2_reserve_space()) and freed
 16upon write completion (jffs2_complete_reservation()). Note that
 17the garbage collector will obtain this right at the beginning of
 18jffs2_garbage_collect_pass() and release it at the end, thereby
 19preventing any other write activity on the file system during a
 20garbage collect pass.
 21
 22When writing new nodes, the alloc_sem must be held until the new nodes
 23have been properly linked into the data structures for the inode to
 24which they belong. This is for the benefit of NAND flash - adding new
 25nodes to an inode may obsolete old ones, and by holding the alloc_sem
 26until this happens we ensure that any data in the write-buffer at the
 27time this happens are part of the new node, not just something that
 28was written afterwards. Hence, we can ensure the newly-obsoleted nodes
 29don't actually get erased until the write-buffer has been flushed to
 30the medium.
 31
 32With the introduction of NAND flash support and the write-buffer, 
 33the alloc_sem is also used to protect the wbuf-related members of the
 34jffs2_sb_info structure. Atomically reading the wbuf_len member to see
 35if the wbuf is currently holding any data is permitted, though.
 36
 37Ordering constraints: See f->sem.
 38
 39
 40	File Mutex f->sem
 41	---------------------
 42
 43This is the JFFS2-internal equivalent of the inode mutex i->i_sem.
 44It protects the contents of the jffs2_inode_info private inode data,
 45including the linked list of node fragments (but see the notes below on
 46erase_completion_lock), etc.
 47
 48The reason that the i_sem itself isn't used for this purpose is to
 49avoid deadlocks with garbage collection -- the VFS will lock the i_sem
 50before calling a function which may need to allocate space. The
 51allocation may trigger garbage-collection, which may need to move a
 52node belonging to the inode which was locked in the first place by the
 53VFS. If the garbage collection code were to attempt to lock the i_sem
 54of the inode from which it's garbage-collecting a physical node, this
 55lead to deadlock, unless we played games with unlocking the i_sem
 56before calling the space allocation functions.
 57
 58Instead of playing such games, we just have an extra internal
 59mutex, which is obtained by the garbage collection code and also
 60by the normal file system code _after_ allocation of space.
 61
 62Ordering constraints: 
 63
 64	1. Never attempt to allocate space or lock alloc_sem with 
 65	   any f->sem held.
 66	2. Never attempt to lock two file mutexes in one thread.
 67	   No ordering rules have been made for doing so.
 68	3. Never lock a page cache page with f->sem held.
 69
 70
 71	erase_completion_lock spinlock
 72	------------------------------
 73
 74This is used to serialise access to the eraseblock lists, to the
 75per-eraseblock lists of physical jffs2_raw_node_ref structures, and
 76(NB) the per-inode list of physical nodes. The latter is a special
 77case - see below.
 78
 79As the MTD API no longer permits erase-completion callback functions
 80to be called from bottom-half (timer) context (on the basis that nobody
 81ever actually implemented such a thing), it's now sufficient to use
 82a simple spin_lock() rather than spin_lock_bh().
 83
 84Note that the per-inode list of physical nodes (f->nodes) is a special
 85case. Any changes to _valid_ nodes (i.e. ->flash_offset & 1 == 0) in
 86the list are protected by the file mutex f->sem. But the erase code
 87may remove _obsolete_ nodes from the list while holding only the
 88erase_completion_lock. So you can walk the list only while holding the
 89erase_completion_lock, and can drop the lock temporarily mid-walk as
 90long as the pointer you're holding is to a _valid_ node, not an
 91obsolete one.
 92
 93The erase_completion_lock is also used to protect the c->gc_task
 94pointer when the garbage collection thread exits. The code to kill the
 95GC thread locks it, sends the signal, then unlocks it - while the GC
 96thread itself locks it, zeroes c->gc_task, then unlocks on the exit path.
 97
 98
 99	inocache_lock spinlock
100	----------------------
101
102This spinlock protects the hashed list (c->inocache_list) of the
103in-core jffs2_inode_cache objects (each inode in JFFS2 has the
104correspondent jffs2_inode_cache object). So, the inocache_lock
105has to be locked while walking the c->inocache_list hash buckets.
106
107This spinlock also covers allocation of new inode numbers, which is
108currently just '++->highest_ino++', but might one day get more complicated
109if we need to deal with wrapping after 4 milliard inode numbers are used.
110
111Note, the f->sem guarantees that the correspondent jffs2_inode_cache
112will not be removed. So, it is allowed to access it without locking
113the inocache_lock spinlock. 
114
115Ordering constraints: 
116
117	If both erase_completion_lock and inocache_lock are needed, the
118	c->erase_completion has to be acquired first.
119
120
121	erase_free_sem
122	--------------
123
124This mutex is only used by the erase code which frees obsolete node
125references and the jffs2_garbage_collect_deletion_dirent() function.
126The latter function on NAND flash must read _obsolete_ nodes to
127determine whether the 'deletion dirent' under consideration can be
128discarded or whether it is still required to show that an inode has
129been unlinked. Because reading from the flash may sleep, the
130erase_completion_lock cannot be held, so an alternative, more
131heavyweight lock was required to prevent the erase code from freeing
132the jffs2_raw_node_ref structures in question while the garbage
133collection code is looking at them.
134
135Suggestions for alternative solutions to this problem would be welcomed.
136
137
138	wbuf_sem
139	--------
140
141This read/write semaphore protects against concurrent access to the
142write-behind buffer ('wbuf') used for flash chips where we must write
143in blocks. It protects both the contents of the wbuf and the metadata
144which indicates which flash region (if any) is currently covered by 
145the buffer.
146
147Ordering constraints:
148	Lock wbuf_sem last, after the alloc_sem or and f->sem.
149
150
151	c->xattr_sem
152	------------
153
154This read/write semaphore protects against concurrent access to the
155xattr related objects which include stuff in superblock and ic->xref.
156In read-only path, write-semaphore is too much exclusion. It's enough
157by read-semaphore. But you must hold write-semaphore when updating,
158creating or deleting any xattr related object.
159
160Once xattr_sem released, there would be no assurance for the existence
161of those objects. Thus, a series of processes is often required to retry,
162when updating such a object is necessary under holding read semaphore.
163For example, do_jffs2_getxattr() holds read-semaphore to scan xref and
164xdatum at first. But it retries this process with holding write-semaphore
165after release read-semaphore, if it's necessary to load name/value pair
166from medium.
167
168Ordering constraints:
169	Lock xattr_sem last, after the alloc_sem.

  1
  2	JFFS2 LOCKING DOCUMENTATION
  3	---------------------------
  4
  5At least theoretically, JFFS2 does not require the Big Kernel Lock
  6(BKL), which was always helpfully obtained for it by Linux 2.4 VFS
  7code. It has its own locking, as described below.
  8
  9This document attempts to describe the existing locking rules for
 10JFFS2. It is not expected to remain perfectly up to date, but ought to
 11be fairly close.
 12
 13
 14	alloc_sem
 15	---------
 16
 17The alloc_sem is a per-filesystem mutex, used primarily to ensure
 18contiguous allocation of space on the medium. It is automatically
 19obtained during space allocations (jffs2_reserve_space()) and freed
 20upon write completion (jffs2_complete_reservation()). Note that
 21the garbage collector will obtain this right at the beginning of
 22jffs2_garbage_collect_pass() and release it at the end, thereby
 23preventing any other write activity on the file system during a
 24garbage collect pass.
 25
 26When writing new nodes, the alloc_sem must be held until the new nodes
 27have been properly linked into the data structures for the inode to
 28which they belong. This is for the benefit of NAND flash - adding new
 29nodes to an inode may obsolete old ones, and by holding the alloc_sem
 30until this happens we ensure that any data in the write-buffer at the
 31time this happens are part of the new node, not just something that
 32was written afterwards. Hence, we can ensure the newly-obsoleted nodes
 33don't actually get erased until the write-buffer has been flushed to
 34the medium.
 35
 36With the introduction of NAND flash support and the write-buffer, 
 37the alloc_sem is also used to protect the wbuf-related members of the
 38jffs2_sb_info structure. Atomically reading the wbuf_len member to see
 39if the wbuf is currently holding any data is permitted, though.
 40
 41Ordering constraints: See f->sem.
 42
 43
 44	File Mutex f->sem
 45	---------------------
 46
 47This is the JFFS2-internal equivalent of the inode mutex i->i_sem.
 48It protects the contents of the jffs2_inode_info private inode data,
 49including the linked list of node fragments (but see the notes below on
 50erase_completion_lock), etc.
 51
 52The reason that the i_sem itself isn't used for this purpose is to
 53avoid deadlocks with garbage collection -- the VFS will lock the i_sem
 54before calling a function which may need to allocate space. The
 55allocation may trigger garbage-collection, which may need to move a
 56node belonging to the inode which was locked in the first place by the
 57VFS. If the garbage collection code were to attempt to lock the i_sem
 58of the inode from which it's garbage-collecting a physical node, this
 59lead to deadlock, unless we played games with unlocking the i_sem
 60before calling the space allocation functions.
 61
 62Instead of playing such games, we just have an extra internal
 63mutex, which is obtained by the garbage collection code and also
 64by the normal file system code _after_ allocation of space.
 65
 66Ordering constraints: 
 67
 68	1. Never attempt to allocate space or lock alloc_sem with 
 69	   any f->sem held.
 70	2. Never attempt to lock two file mutexes in one thread.
 71	   No ordering rules have been made for doing so.
 
 72
 73
 74	erase_completion_lock spinlock
 75	------------------------------
 76
 77This is used to serialise access to the eraseblock lists, to the
 78per-eraseblock lists of physical jffs2_raw_node_ref structures, and
 79(NB) the per-inode list of physical nodes. The latter is a special
 80case - see below.
 81
 82As the MTD API no longer permits erase-completion callback functions
 83to be called from bottom-half (timer) context (on the basis that nobody
 84ever actually implemented such a thing), it's now sufficient to use
 85a simple spin_lock() rather than spin_lock_bh().
 86
 87Note that the per-inode list of physical nodes (f->nodes) is a special
 88case. Any changes to _valid_ nodes (i.e. ->flash_offset & 1 == 0) in
 89the list are protected by the file mutex f->sem. But the erase code
 90may remove _obsolete_ nodes from the list while holding only the
 91erase_completion_lock. So you can walk the list only while holding the
 92erase_completion_lock, and can drop the lock temporarily mid-walk as
 93long as the pointer you're holding is to a _valid_ node, not an
 94obsolete one.
 95
 96The erase_completion_lock is also used to protect the c->gc_task
 97pointer when the garbage collection thread exits. The code to kill the
 98GC thread locks it, sends the signal, then unlocks it - while the GC
 99thread itself locks it, zeroes c->gc_task, then unlocks on the exit path.
100
101
102	inocache_lock spinlock
103	----------------------
104
105This spinlock protects the hashed list (c->inocache_list) of the
106in-core jffs2_inode_cache objects (each inode in JFFS2 has the
107correspondent jffs2_inode_cache object). So, the inocache_lock
108has to be locked while walking the c->inocache_list hash buckets.
109
110This spinlock also covers allocation of new inode numbers, which is
111currently just '++->highest_ino++', but might one day get more complicated
112if we need to deal with wrapping after 4 milliard inode numbers are used.
113
114Note, the f->sem guarantees that the correspondent jffs2_inode_cache
115will not be removed. So, it is allowed to access it without locking
116the inocache_lock spinlock. 
117
118Ordering constraints: 
119
120	If both erase_completion_lock and inocache_lock are needed, the
121	c->erase_completion has to be acquired first.
122
123
124	erase_free_sem
125	--------------
126
127This mutex is only used by the erase code which frees obsolete node
128references and the jffs2_garbage_collect_deletion_dirent() function.
129The latter function on NAND flash must read _obsolete_ nodes to
130determine whether the 'deletion dirent' under consideration can be
131discarded or whether it is still required to show that an inode has
132been unlinked. Because reading from the flash may sleep, the
133erase_completion_lock cannot be held, so an alternative, more
134heavyweight lock was required to prevent the erase code from freeing
135the jffs2_raw_node_ref structures in question while the garbage
136collection code is looking at them.
137
138Suggestions for alternative solutions to this problem would be welcomed.
139
140
141	wbuf_sem
142	--------
143
144This read/write semaphore protects against concurrent access to the
145write-behind buffer ('wbuf') used for flash chips where we must write
146in blocks. It protects both the contents of the wbuf and the metadata
147which indicates which flash region (if any) is currently covered by 
148the buffer.
149
150Ordering constraints:
151	Lock wbuf_sem last, after the alloc_sem or and f->sem.
152
153
154	c->xattr_sem
155	------------
156
157This read/write semaphore protects against concurrent access to the
158xattr related objects which include stuff in superblock and ic->xref.
159In read-only path, write-semaphore is too much exclusion. It's enough
160by read-semaphore. But you must hold write-semaphore when updating,
161creating or deleting any xattr related object.
162
163Once xattr_sem released, there would be no assurance for the existence
164of those objects. Thus, a series of processes is often required to retry,
165when updating such a object is necessary under holding read semaphore.
166For example, do_jffs2_getxattr() holds read-semaphore to scan xref and
167xdatum at first. But it retries this process with holding write-semaphore
168after release read-semaphore, if it's necessary to load name/value pair
169from medium.
170
171Ordering constraints:
172	Lock xattr_sem last, after the alloc_sem.