Re: [PATCH] btrfs: add delayed_iput list head to btrfs inode

[Eric Sandeen <sandeen@redhat.com>]

On 2/5/13 8:08 PM, Liu Bo wrote:
> On Tue, Feb 05, 2013 at 03:14:05PM -0800, Zach Brown wrote:
>>> +	struct btrfs_inode *b_inode = BTRFS_I(inode);
>>> +	struct btrfs_fs_info *fs_info = b_inode->root->fs_info;
>>>  
>>>  	if (atomic_add_unless(&inode->i_count, -1, 1))
>>>  		return;
>>>  
>>> -	delayed = kmalloc(sizeof(*delayed), GFP_NOFS | __GFP_NOFAIL);
>>> -	delayed->inode = inode;
>>> -
>>>  	spin_lock(&fs_info->delayed_iput_lock);
>>> -	list_add_tail(&delayed->list, &fs_info->delayed_iputs);
>>> +	list_add_tail(&b_inode->delayed_iput, &fs_info->delayed_iputs);
>>>  	spin_unlock(&fs_info->delayed_iput_lock);
>>>  }
>>
>> Hmm.  I'm not great with inode life cycles, but isn't this only safe if
>> someone else can't get an i_count reference while this is in flight?  It
>> looks like the final iput does the unhashing, and so on, so couldn't an
>> iget/iput race with this and try to add the inode's list_head twice?
> 
> Yeah, same concern here.  Basically this will result in inodes still being
> in use on unmount.
> 
> Actually I did a similar one, here is some disscussion:
> 
> https://patchwork.kernel.org/patch/1824711/

I read it, thanks.  Did you try the counter approach?

-Eric

> thanks,
> liubo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>