Date: Wed, 21 Aug 2013 20:03:35 +0200 From: Yamagi Burmeister <lists@yamagi.org> To: kostikbel@gmail.com Cc: rmacklem@uoguelph.ca, freebsd-stable@freebsd.org, michael@esosoft.com, scottl@freebsd.org, j.david.lists@gmail.com, killing@multiplay.co.uk Subject: Re: NFS deadlock on 9.2-Beta1 Message-ID: <20130821200335.01528095f2bb0efabff10ba3@yamagi.org> In-Reply-To: <20130821131032.GX4972@kib.kiev.ua> References: <CABXB=RTMV840C3dCiBa=tJ_ru9BS2mpFTGr5h6BoH5AbjL1kYQ@mail.gmail.com> <937358501.11648801.1377037096794.JavaMail.root@uoguelph.ca> <20130821131032.GX4972@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Wed__21_Aug_2013_20_03_35_+0200_HrTD8TdNh/zYzUQl Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 21 Aug 2013 16:10:32 +0300 Konstantin Belousov <kostikbel@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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Still, I do not know what happens in the supposedly reported deadlock. >=20 > 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 =3D OFF_TO_IDX(off); > VM_OBJECT_WLOCK(obj); > pg =3D 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); > =20 > /* > * 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 --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Wed__21_Aug_2013_20_03_35_+0200_HrTD8TdNh/zYzUQl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlIVAPsACgkQWTjlg++8y8twrACg0inoxm+sqEKuYdLmkdyShtOf cM0An0ILQbYHQwV/SsZJlUYIpcRHPXIv =EvaR -----END PGP SIGNATURE----- --Signature=_Wed__21_Aug_2013_20_03_35_+0200_HrTD8TdNh/zYzUQl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130821200335.01528095f2bb0efabff10ba3>