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