On Wed, 21 Aug 2013 16:10:32 +0300 Konstantin Belousov <kostik...@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: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB
pgpiQ7wf0tTdP.pgp
Description: PGP signature
