fs/jffs2/README.Locking

3 	---------------------------
9 This document attempts to describe the existing locking rules for
10 JFFS2. It is not expected to remain perfectly up to date, but ought to
15 	---------
17 The alloc_sem is a per-filesystem mutex, used primarily to ensure
20 upon write completion (jffs2_complete_reservation()). Note that
23 preventing any other write activity on the file system during a
27 have been properly linked into the data structures for the inode to
28 which they belong. This is for the benefit of NAND flash - adding new
29 nodes to an inode may obsolete old ones, and by holding the alloc_sem
30 until this happens we ensure that any data in the write-buffer at the
32 was written afterwards. Hence, we can ensure the newly-obsoleted nodes
33 don't actually get erased until the write-buffer has been flushed to
36 With the introduction of NAND flash support and the write-buffer,
37 the alloc_sem is also used to protect the wbuf-related members of the
38 jffs2_sb_info structure. Atomically reading the wbuf_len member to see
41 Ordering constraints: See f->sem.
44 	File Mutex f->sem
45 	---------------------
47 This is the JFFS2-internal equivalent of the inode mutex i->i_sem.
52 The reason that the i_sem itself isn't used for this purpose is to
53 avoid deadlocks with garbage collection -- the VFS will lock the i_sem
54 before calling a function which may need to allocate space. The
55 allocation may trigger garbage-collection, which may need to move a
56 node belonging to the inode which was locked in the first place by the
57 VFS. If the garbage collection code were to attempt to lock the i_sem
58 of the inode from which it's garbage-collecting a physical node, this
59 lead to deadlock, unless we played games with unlocking the i_sem
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.
75 	------------------------------
77 This is used to serialise access to the eraseblock lists, to the
78 per-eraseblock lists of physical jffs2_raw_node_ref structures, and
79 (NB) the per-inode list of physical nodes. The latter is a special
80 case - see below.
82 As the MTD API no longer permits erase-completion callback functions
83 to be called from bottom-half (timer) context (on the basis that nobody
84 ever actually implemented such a thing), it's now sufficient to use
87 Note that the per-inode list of physical nodes (f->nodes) is a special
88 case. Any changes to _valid_ nodes (i.e. ->flash_offset & 1 == 0) in
89 the list are protected by the file mutex f->sem. But the erase code
92 erase_completion_lock, and can drop the lock temporarily mid-walk as
93 long as the pointer you're holding is to a _valid_ node, not an
96 The erase_completion_lock is also used to protect the c->gc_task
97 pointer when the garbage collection thread exits. The code to kill the
98 GC thread locks it, sends the signal, then unlocks it - while the GC
99 thread itself locks it, zeroes c->gc_task, then unlocks on the exit path.
103 	----------------------
105 This spinlock protects the hashed list (c->inocache_list) of the
106 in-core jffs2_inode_cache objects (each inode in JFFS2 has the
108 has to be locked while walking the c->inocache_list hash buckets.
111 currently just '++->highest_ino++', but might one day get more complicated
112 if we need to deal with wrapping after 4 milliard inode numbers are used.
114 Note, the f->sem guarantees that the correspondent jffs2_inode_cache
115 will not be removed. So, it is allowed to access it without locking
121 	c->erase_completion has to be acquired first.
125 	--------------
129 The latter function on NAND flash must read _obsolete_ nodes to
131 discarded or whether it is still required to show that an inode has
134 heavyweight lock was required to prevent the erase code from freeing
138 Suggestions for alternative solutions to this problem would be welcomed.
142 	--------
144 This read/write semaphore protects against concurrent access to the
145 write-behind buffer ('wbuf') used for flash chips where we must write
151 	Lock wbuf_sem last, after the alloc_sem or and f->sem.
154 	c->xattr_sem
155 	------------
157 This read/write semaphore protects against concurrent access to the
158 xattr related objects which include stuff in superblock and ic->xref.
159 In read-only path, write-semaphore is too much exclusion. It's enough
160 by read-semaphore. But you must hold write-semaphore when updating,
164 of those objects. Thus, a series of processes is often required to retry,
166 For example, do_jffs2_getxattr() holds read-semaphore to scan xref and
167 xdatum at first. But it retries this process with holding write-semaphore
168 after release read-semaphore, if it's necessary to load name/value pair