README.Locking 6.9 KB

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