I_WILL_FREE was introduced by the following commit:
$ git show 991114c6fa6a21d1fa4d544abe78592352860c82
commit 991114c6fa6a21d1fa4d544abe78592352860c82
Author: Alexander Viro <aviro@xxxxxxxxxx>
Date: Thu Jun 23 00:09:01 2005 -0700
[PATCH] fix for prune_icache()/forced final iput() races
To me, the only reason we need it now is because we might drop inode lock before
evict it finally. So we set a flag saying: leave it alone please.
thanks,
-Zhihui
On Sat, Jan 2, 2016 at 12:18 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> [akpm Cc'd]
> On Fri, Jan 01, 2016 at 10:12:54PM -0500, Zhihui Zhang wrote:
>> 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.
>
> Hmm... That ihold() is actually a lot more recent than original
> introduction of I_WILL_FREE, but looking at the state of the tree
> back when it was originally introduced... I'm trying to recall
> what made us go for a separate flag, but so far I've got nothing
> definite. Hell knows - it had been 10 years ago, and I have a gap
> from late 2004 to September 2005 in mailboxes, so those are no help
> either... I _think_ it got discussed with akpm, maybe he would be
> able to help reconstructing what happened.
>
> It looks like you are right regarding the current state of the tree, but
> I really wonder if there's something subtle that got missed during
> one of rewrites in those ten years... OTOH, it's quite possible that there
> had been no good reason for using a separate flag from the very beginning.
>
> Andrew, do you have any memories of (or, better yet, archived mails relevant
> to) that thing?
--
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
