Messages in this thread | | | Date | Wed, 21 Nov 2012 00:05:33 -0800 | From | Andrew Morton <> | Subject | Re: The bug of iput() removal from flusher thread? |
| |
On Wed, 21 Nov 2012 02:48:51 +0100 Jan Kara <jack@suse.cz> wrote:
> +/* > + * Add inode to LRU if needed (inode is unused and clean). > + * > + * Needs inode->i_lock held. > + */ > +void inode_add_lru(struct inode *inode) > +{ > + if (!(inode->i_state & (I_DIRTY | I_FREEING | I_SYNC)) && > + !atomic_read(&inode->i_count) && inode->i_sb->s_flags & MS_ACTIVE) > + inode_lru_list_add(inode); > +}
Is i_lock sufficient to stabilise i_count?
<looks at the code a bit>
Is evict_inodes() wrong to test i_count outside i_lock?
invalidate_inodes() looks better.
can_unuse() must be called under i_lock, and is. Apparently this requirement was sufficiently obvious to not meed documenting.
prune_icache_sb() gets it right.
iput() gets it right.
So to answer my own question: yes, it is sufficient. But a) the comment for inode.i_lock is out of date and b) evict_inodes() looks fishy.
| |