fs/jffs2/README.Locking

5 This document attempts to describe the existing locking rules for
6 JFFS2. It is not expected to remain perfectly up to date, but ought to
13 The alloc_sem is a per-filesystem mutex, used primarily to ensure
23 have been properly linked into the data structures for the inode to
25 nodes to an inode may obsolete old ones, and by holding the alloc_sem
29 don't actually get erased until the write-buffer has been flushed to
33 the alloc_sem is also used to protect the wbuf-related members of the
34 jffs2_sb_info structure. Atomically reading the wbuf_len member to see
48 The reason that the i_sem itself isn't used for this purpose is to
50 before calling a function which may need to allocate space. The
51 allocation may trigger garbage-collection, which may need to move a
52 node belonging to the inode which was locked in the first place by the
53 VFS. If the garbage collection code were to attempt to lock the i_sem
55 lead to deadlock, unless we played games with unlocking the i_sem
64 	1. Never attempt to allocate space or lock alloc_sem with
66 	2. Never attempt to lock two file mutexes in one thread.
74 This is used to serialise access to the eraseblock lists, to the
80 to be called from bottom-half (timer) context (on the basis that nobody
81 ever actually implemented such a thing), it's now sufficient to use
85 case. Any changes to _valid_ nodes (i.e. ->flash_offset & 1 == 0) in
90 long as the pointer you're holding is to a _valid_ node, not an
93 The erase_completion_lock is also used to protect the c->gc_task
94 pointer when the garbage collection thread exits. The code to kill the
105 has to be locked while walking the c->inocache_list hash buckets.
109 if we need to deal with wrapping after 4 milliard inode numbers are used.
112 will not be removed. So, it is allowed to access it without locking
118 	c->erase_completion has to be acquired first.
126 The latter function on NAND flash must read _obsolete_ nodes to
128 discarded or whether it is still required to show that an inode has
131 heavyweight lock was required to prevent the erase code from freeing
135 Suggestions for alternative solutions to this problem would be welcomed.
141 This read/write semaphore protects against concurrent access to the
154 This read/write semaphore protects against concurrent access to the
161 of those objects. Thus, a series of processes is often required to retry,
163 For example, do_jffs2_getxattr() holds read-semaphore to scan xref and
165 after release read-semaphore, if it's necessary to load name/value pair