From owner-svn-src-all@FreeBSD.ORG Sun Feb 3 19:23:22 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6AEBEF6; Sun, 3 Feb 2013 19:23:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 519F07A2; Sun, 3 Feb 2013 19:23:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA10073; Sun, 03 Feb 2013 21:23:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U259q-0006yS-SJ; Sun, 03 Feb 2013 21:23:18 +0200 Message-ID: <510EB926.7030307@FreeBSD.org> Date: Sun, 03 Feb 2013 21:23:18 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 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 References: <201302031842.r13IgK7e089609@svn.freebsd.org> In-Reply-To: <201302031842.r13IgK7e089609@svn.freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 19:23:22 -0000 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. -- Andriy Gapon