Date: Wed, 20 May 2020 14:30:48 -0400 From: Mark Johnston <markj@freebsd.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r361287 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys Message-ID: <20200520183048.GB59386@raichu> In-Reply-To: <202005201829.04KITNRs083936@repo.freebsd.org> References: <202005201829.04KITNRs083936@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 20, 2020 at 06:29:23PM +0000, Mark Johnston wrote: > Author: markj > Date: Wed May 20 18:29:23 2020 > New Revision: 361287 > URL: https://svnweb.freebsd.org/changeset/base/361287 > > Log: > Don't block on the range lock in zfs_getpages(). > > After r358443 the vnode object lock no longer synchronizes concurrent > zfs_getpages() and zfs_write() (which must update vnode pages to > maintain coherence). This created a potential deadlock between ZFS > range locks and VM page busy locks: a fault on a mapped file will cause > the fault page to be busied, after which zfs_getpages() locks a range > around the file offset in order to map adjacent, resident pages; > zfs_write() locks the range first, and then must busy vnode pages when > synchronizing. > > Solve this by adding a non-blocking mode for ZFS range locks, and using > it in zfs_getpages(). If zfs_getpages() fails to acquire the range > lock, only the fault page will be populated. I will work on getting this submitted to OpenZFS.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200520183048.GB59386>