Re: [PATCH 1/2] NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode()

["zhangxiaoxu (A)" <zhangxiaoxu5@huawei.com>]

在 2021/6/7 21:51, Trond Myklebust 写道:
>> 在 2021/6/2 1:36,trondmy@kernel.org  写道:
>>> From: Trond Myklebust<trond.myklebust@hammerspace.com>
>>>
>>> If the inode is being evicted, but has to return a delegation
>>> first,
>>> then it can cause a deadlock in the corner case where the server
>>> reboots
>>> before the delegreturn completes, but while the call to
>>> iget5_locked() in
>>> nfs4_opendata_get_inode() is waiting for the inode free to
>>> complete.
>>> Since the open call still holds a session slot, the reboot recovery
>>> cannot proceed.
>>>
>>> In order to break the logjam, we can turn the delegation return
>>> into a
>>> privileged operation for the case where we're evicting the inode.
>>> We
>>> know that in that case, there can be no other state recovery
>>> operation
>>> that conflicts.
>>>
>> it's looks good to me.
>>
>> but i have another confuse, how to ensure no writeback when evict nfs
>> inode?
>> because flush writes to server when close?
>> but not all close will flush writes to server.
> The struct nfs_open_context holds a reference to the dentry (which
> holds a reference to the inode) and to the superblock. The struct
> nfs_page that is tracking page dirtiness then holds a reference to the
> nfs_open_context.
> 
> That mechanism ensures the inode cannot be evicted until all dirty
> pages have been either flushed or cancelled. The only thing we need to
> worry about is the delegation and the pNFS layout since neither one is
> allowed to reference the inode in any way (because otherwise they would
> prevent the memory reclaim mechanisms from working).
> 
Yes, it is.
Thank you very much.