Date: Sun, 03 Feb 2013 21:28:19 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r246293 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <510EBA53.5020003@FreeBSD.org> In-Reply-To: <510EB926.7030307@FreeBSD.org> References: <201302031842.r13IgK7e089609@svn.freebsd.org> <510EB926.7030307@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 03/02/2013 21:23 Andriy Gapon said the following: > on 03/02/2013 20:42 Andriy Gapon said the following: >> - vm_page_busy(pp); >> - vm_page_undirty(pp); > > ZFS lookup_page previously had two interesting bugs that almost canceled each other. > > The first bug was that vm_page_undirty was called even if we read from a > ZFS-backed page into a user buffer. Obviously this action didn't actually > magically make the page clean. > The second bug was that vm_page_undirty was called without doing > pmap_remove_write() first and so, if the page was actually modified, the > modified bit leaked back from a pmap to the dirty bits. So no harm was done. > > On the other hand, if a ZFS-backed dirty page was over-written with a content > from ARC (which was first put there from a userland buffer), then the page > stayed marked dirty for all the same reason (lack of pmap_remove_write). And so > exactly the same data would have to be re-written to ARC / disk again. Eh, just realized that on the third hand, this cancelled yet another bug :-) vm_page_undirty was called on the whole page even when only a part of it overlapped with the buffer and thus was supposed to become clean. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?510EBA53.5020003>