lk/linux-kernel-test
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

kill I_LOCK

Browse Source 
After I_SYNC was split from I_LOCK the leftover is always used together with
I_NEW and thus superflous.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This commit is contained in:
Christoph Hellwig
2009-12-17 14:25:01 +01:00
committed by Al Viro
parent 7a0ad10c36
commit eaff8079d4
9 changed files with 39 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
include/linux/fs.h
View File

@@ -1587,7 +1587,7 @@ struct super_operations {
* until that flag is cleared. I_WILL_FREE, I_FREEING and I_CLEAR are set at
* various stages of removing an inode.
*
* Two bits are used for locking and completion notification, I_LOCK and I_SYNC.
* Two bits are used for locking and completion notification, I_NEW and I_SYNC.
*
* I_DIRTY_SYNC Inode is dirty, but doesn't have to be written on
* fdatasync(). i_atime is the usual cause.
@@ -1596,8 +1596,14 @@ struct super_operations {
* don't have to write inode on fdatasync() when only
* mtime has changed in it.
* I_DIRTY_PAGES Inode has dirty pages. Inode itself may be clean.
* I_NEW get_new_inode() sets i_state to I_LOCK|I_NEW. Both
* are cleared by unlock_new_inode(), called from iget().
* I_NEW Serves as both a mutex and completion notification.
* New inodes set I_NEW. If two processes both create
* the same inode, one of them will release its inode and
* wait for I_NEW to be released before returning.
* Inodes in I_WILL_FREE, I_FREEING or I_CLEAR state can
* also cause waiting on I_NEW, without I_NEW actually
* being set. find_inode() uses this to prevent returning
* nearly-dead inodes.
* I_WILL_FREE Must be set when calling write_inode_now() if i_count
* is zero. I_FREEING must be set when I_WILL_FREE is
* cleared.
@@ -1611,20 +1617,11 @@ struct super_operations {
* prohibited for many purposes. iget() must wait for
* the inode to be completely released, then create it
* anew. Other functions will just ignore such inodes,
* if appropriate. I_LOCK is used for waiting.
* if appropriate. I_NEW is used for waiting.
*
* I_LOCK Serves as both a mutex and completion notification.
* New inodes set I_LOCK. If two processes both create
* the same inode, one of them will release its inode and
* wait for I_LOCK to be released before returning.
* Inodes in I_WILL_FREE, I_FREEING or I_CLEAR state can
* also cause waiting on I_LOCK, without I_LOCK actually
* being set. find_inode() uses this to prevent returning
* nearly-dead inodes.
* I_SYNC Similar to I_LOCK, but limited in scope to writeback
* of inode dirty data. Having a separate lock for this
* purpose reduces latency and prevents some filesystem-
* specific deadlocks.
* I_SYNC Synchonized write of dirty inode data. The bits is
* set during data writeback, and cleared with a wakeup
* on the bit address once it is done.
*
* Q: What is the difference between I_WILL_FREE and I_FREEING?
* Q: igrab() only checks on (I_FREEING|I_WILL_FREE). Should it also check on
@@ -1633,13 +1630,12 @@ struct super_operations {
#define I_DIRTY_SYNC 1
#define I_DIRTY_DATASYNC 2
#define I_DIRTY_PAGES 4
#define I_NEW 8
#define __I_NEW 3
#define I_NEW (1 << __I_NEW)
#define I_WILL_FREE 16
#define I_FREEING 32
#define I_CLEAR 64
#define __I_LOCK 7
#define I_LOCK (1 << __I_LOCK)
#define __I_SYNC 8
#define __I_SYNC 7
#define I_SYNC (1 << __I_SYNC)
#define I_DIRTY (I_DIRTY_SYNC | I_DIRTY_DATASYNC | I_DIRTY_PAGES)