Date: Sun, 10 Oct 2010 15:27:23 +0300 From: Andriy Gapon <avg@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Locked up processes after upgrade to ZFS v15 Message-ID: <4CB1B12B.3010107@freebsd.org> In-Reply-To: <20101010121532.GG2392@deviant.kiev.zoral.com.ua> References: <39F05641-4E46-4BE0-81CA-4DEB175A5FBE@free.de> <201010061732.o96HW2Vi005945@higson.cam.lispworks.com> <E5332812-379B-4EC1-A134-12176C718B2E@free.de> <4CAF45A8.3020401@icyb.net.ua> <4CB18BC6.70305@freebsd.org> <20101010121532.GG2392@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 10/10/2010 15:15 Kostik Belousov said the following: > On Sun, Oct 10, 2010 at 12:47:50PM +0300, Andriy Gapon wrote: >> Hm, I think that we actually shouldn't see a stack like that. >> vm_fault sets VPO_BUSY on a page before calling vnode_pager_generic_getpages, so >> the thread gets stuck forever in zfs mappedread. >> It seems like the page that was seen as invalid in vm_fault becomes valid while >> call flow reaches mappedread. > The vnode is share-locked, and vm object lock is dropped and reacquired > several times until control reaches zfs_mappedread. This indeed allows > a window during which page might be read by other thread. But wouldn't a page still stay protected by VPO_BUSY all that time? I mean that the page shouldn't be read in and marked valid by other thread while it's flagged with VPO_BUSY. And, AFAICS, vm_fault has the page busy for the whole duration. > There are two possible routes to solve the issue: > 1. Provide zfs-specific VOP_GETPAGES(). > 2. Use my vm6 patch. Sigh. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CB1B12B.3010107>