From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 19:12:10 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67B99B33 for ; Mon, 25 Nov 2013 19:12:10 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9662621CA for ; Mon, 25 Nov 2013 19:12:09 +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 VAA25473; Mon, 25 Nov 2013 21:11:46 +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 1Vl1ZS-000Mku-2c; Mon, 25 Nov 2013 21:11:46 +0200 Message-ID: <5293A0B4.9070507@FreeBSD.org> Date: Mon, 25 Nov 2013 21:10:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: Help with filing a [maybe] ZFS/mmap bug. References: <20967.760.95825.310085@gargle.gargle.HOWL><51E80B30.1090004@FreeBSD.org><20968.10645.880772.30501@gargle.gargle.HOWL><520202E5.30300@FreeBSD.org><20994.55913.93606.436124@gargle.gargle.HOWL> <21111.12085.958991.356982@gargle.gargle.HOWL> <4EB902F80CE84DD2BF36C85EF4CE8EF8@multiplay.co.uk> <5284B8A5.8040604@FreeBSD.org> <52889105.7040404@FreeBSD.org> <4B5798F5-269A-4E71-9799-E1B4E0C1545F@transactionware.com> <5289DFFD.7080607@FreeBSD.org> <52939929.2090705@omnilan.de> In-Reply-To: <52939929.2090705@omnilan.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Jan Mikkelsen , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:12:10 -0000 on 25/11/2013 20:38 Harald Schmalzbauer said the following: > Bezüglich Andriy Gapon's Nachricht vom 18.11.2013 10:38 (localtime): >> ... >>>> Here is a patch (for head) that should fix the described above issue: >>>> >>>> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> index 2e2cbd6..4fcd571 100644 >>>> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> @@ -328,6 +328,20 @@ page_busy(vnode_t *vp, int64_t start, int64_t off, int64_t >>>> nbytes) >>>> { >>>> vm_object_t obj; >>>> vm_page_t pp; >>>> + int64_t end; >>>> + >>>> + /* >>>> + * At present vm_page_clear_dirty extends the cleared range to DEV_BSIZE >>>> + * aligned boundaries, if the range is not aligned. As a result a >>>> + * DEV_BSIZE subrange with partially dirty data may get marked as clean. >>>> + * It may happen that all DEV_BSIZE subranges are marked clean and thus >>>> + * the whole page would be considred clean despite have some dirty data. >>>> + * For this reason we should shrink the range to DEV_BSIZE aligned >>>> + * boundaries before calling vm_page_clear_dirty. >>>> + */ >>>> + end = rounddown2(off + nbytes, DEV_BSIZE); >>>> + off = roundup2(off, DEV_BSIZE); >>>> + nbytes = end - off; >>>> >>>> obj = vp->v_object; >>>> zfs_vmobject_assert_wlocked(obj); >>>> @@ -362,7 +376,8 @@ page_busy(vnode_t *vp, int64_t start, int64_t off, int64_t >>>> nbytes) >>>> ASSERT3U(pp->valid, ==, VM_PAGE_BITS_ALL); >>>> vm_object_pip_add(obj, 1); >>>> pmap_remove_write(pp); >>>> - vm_page_clear_dirty(pp, off, nbytes); >>>> + if (nbytes != 0) >>>> + vm_page_clear_dirty(pp, off, nbytes); >>>> } >>>> break; >>>> } >>> >>> 9.2 does not seem to have a rounddown2() macro. >> Thanks for the heads-up! >> You could use a plain rounddown() or just 'x & ~(DEV_BSIZE - 1)'. > > Hello, > > saw that this fix made it int 9-stable: > http://svnweb.freebsd.org/base/stable/9/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?r1=255517&r2=258555 > > But it uses rounddown2(), so I guess it's not workit atm, right? Yeah, sorry about this. I had a headsup and made a note to myself about it, but then got distracted at the actual mfc time. Should be fixed now. -- Andriy Gapon