From owner-freebsd-fs@FreeBSD.ORG  Mon Aug 30 09:20:10 2004
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id C0ACD16A4CE; Mon, 30 Aug 2004 09:20:10 +0000 (GMT)
Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 9EC0F43D69; Mon, 30 Aug 2004 09:20:08 +0000 (GMT)
	(envelope-from yar@comp.chem.msu.su)
Received: from comp.chem.msu.su (localhost [127.0.0.1])
	by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i7U9K56E025368;
	Mon, 30 Aug 2004 13:20:05 +0400 (MSD)
	(envelope-from yar@comp.chem.msu.su)
Received: (from yar@localhost)
	by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i7U9K5JJ025363;
	Mon, 30 Aug 2004 13:20:05 +0400 (MSD)
	(envelope-from yar)
Date: Mon, 30 Aug 2004 13:20:04 +0400
From: Yar Tikhiy <yar@comp.chem.msu.su>
To: fs@freebsd.org, hackers@freebsd.org
Message-ID: <20040830092004.GC22366@comp.chem.msu.su>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Subject: A typical bug around VOP_GETPAGES?
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Aug 2004 09:20:10 -0000

Hi folks,

Users' complaints about HFS for FreeBSD not compiling again encouraged
me to hack up a yet another patchlevel allowing for recent changes
in our beloved OS :-)

This time fsx started to fail upon a mmapped access near the end
of an HFS file with diagnostics that non-zero data were found beyond
EOF (which is against POSIX.)  I'm confused by this.  HFS relies
on the default VOP_GETPAGES handler and hence I used to believe
that the kernel should just bread() the last block of the file,
copy the appropriate part of it to the process' page, and zero out
the rest of the page.   Fsx found no other problems in a reasonable
time, which meant plain vanilla reading from (and writing to) the
FS worked OK.

Perhaps anyone has a quick idea where to look for problematic code?

-- 
Yar