NFS deadlock on 9.2-Beta1

[Yamagi Burmeister]

On Wed, 21 Aug 2013 16:10:32 +0300
Konstantin Belousov <kostikbel at gmail.com> wrote:

> I already described what to do with this.  I need the debugging
> information to see what is going on.  Without the data, it is only
> wasted time of everybody involved.
> 
> Some technical notes.  The sendfile() uses shared lock for the duration
> of vnode i/o, so any thread which is sleeping on the vnode lock cannot
> be in the sendfile path, at least for UFS and NFS which do support true
> shared locks.
> 
> The right lock order is vnode lock -> page busy wait. From this PoV,
> the ordering in the sendfile is correct. Rick, are you aware of any
> situation where the VOP_READ in nfs client could drop vnode lock
> and then re-acquire it ? I was not able to find this from the code
> inspection. But, if such situation exists, it would be problematic in 9.
> 
> Last note.  The HEAD dropped pre-busying pages in the sendfile() syscall.
> As I understand, this is because new Attilio' busy implementation cannot
> support both busy and sbusy states simultaneously, and vfs_busy_pages()/
> vfs_drain_busy_pages() actually created such situation. I think that
> because the sbusy is removed from the sendfile(), and the vm object
> lock is dropped, there is no sense to require vm_page_grab() to wait
> for the busy state to clean.  It is done by buffer cache or filesystem
> code later. See the patch at the end.
> 
> Still, I do not know what happens in the supposedly reported deadlock.
> 
> diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c
> index 4797444..b974f53 100644
> --- a/sys/kern/uipc_syscalls.c
> +++ b/sys/kern/uipc_syscalls.c
> @@ -2230,7 +2230,8 @@ retry_space:
>  			pindex = OFF_TO_IDX(off);
>  			VM_OBJECT_WLOCK(obj);
>  			pg = vm_page_grab(obj, pindex, VM_ALLOC_NOBUSY |
> -			    VM_ALLOC_NORMAL | VM_ALLOC_WIRED | VM_ALLOC_RETRY);
> +			    VM_ALLOC_IGN_SBUSY | VM_ALLOC_NORMAL |
> +			    VM_ALLOC_WIRED | VM_ALLOC_RETRY);
>  
>  			/*
>  			 * Check if page is valid for what we need,

Could the problem be related to this deadlock / LOR? -
http://lists.freebsd.org/pipermail/freebsd-fs/2013-August/018052.html

My test setup is still in place. Will test with r250907 reverted
tomorrow morning and report back. Additional informations could be
provided if necessary. I just need to know what exactly.

Ciao,
Yamagi

-- 
Homepage:  www.yamagi.org
XMPP:      yamagi at yamagi.org
GnuPG/GPG: 0xEFBCCBCB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130821/313c9de5/attachment.sig>