Re: NFS deadlock on 9.2-Beta1
--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--
討論串 (同標題文章)
完整討論串 (本文為第 22 之 27 篇)：