You are right, I was thinking from the perspective of I_WILL_FREE.
However, for the examples in fs-writeback.c and a few in
ext4/btrfs/inode.c, we can argue that they really should check
I_WILL_FREE as well. In theory, bad things can happen if they don't
because as soon as I_WILL_FREE is set, the inode is going to be
evicted. For example, in fs-writeback.c:
471 spin_lock(&inode->i_lock);
472 if (inode->i_state & (I_WB_SWITCH | I_FREEING) ||
<-- Assume I_WILL_FREE is set
at this point.
473 inode_to_wb(inode) == isw->new_wb) {
474 spin_unlock(&inode->i_lock);
475 goto out_free;
476 }
477 inode->i_state |= I_WB_SWITCH;
478 spin_unlock(&inode->i_lock);
479
480 ihold(inode); <-- This will cause a warning because of i_count.
thanks,
-Zhihui
On Fri, Jan 1, 2016 at 9:31 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Jan 01, 2016 at 08:52:06PM -0500, Zhihui Zhang wrote:
>> I_WILL_FREE does not really add any new functionality over I_FREEING.
>> If I_WILL_FREE is set, it will be replaced by I_FREEING under the inode
>> lock. And they always appear in the same if statement.
>
> Do they? Consider
>
> fs/fs-writeback.c:351: if (unlikely(inode->i_state & I_FREEING))
> fs/fs-writeback.c:472: if (inode->i_state & (I_WB_SWITCH | I_FREEING) ||
> fs/fs-writeback.c:1161: if (inode->i_state & I_FREEING)
> fs/fs-writeback.c:2049: if (inode->i_state & I_FREEING)
>
> for a few counterexamples...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
