From owner-freebsd-emulation@FreeBSD.ORG Tue May 8 14:24:43 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2D5016A406 for ; Tue, 8 May 2007 14:24:43 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 6D46313C4B9 for ; Tue, 8 May 2007 14:24:43 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by an-out-0708.google.com with SMTP id d23so206008and for ; Tue, 08 May 2007 07:24:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H6wPCds5WPDVcLbEC+R9043OgQbyVaeCmPbOTtpkNfiU/fPJK1hT24iM6YSEqMQi7cOWXEuU4qRd5GZ7j0sqYsYmQNgTQvjXJORtC2QfdNj2zzrHd9s2UkOgX5ZfKmAquY/iWYT0CfH8jRUzSihsyYKaDxMvuB/ynCGx6LDJ8Gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FNe0VZtJ5aHR/fiGC5oAPhB/K1/PfYhAZN7GxdVnfkfZmA1i5rqYObF9BkkJwE+fxjmmmO5M9w4NbA56HqizFe6oojm2dDwYVPnUSFj/iB3KfwAgmu3oozMMwWPWlPOYIqJbO9HVIO2YcR1J2x0usHa9bl06s4Fd8mfkIqhl45c= Received: by 10.100.202.13 with SMTP id z13mr5755790anf.1178634280899; Tue, 08 May 2007 07:24:40 -0700 (PDT) Received: by 10.100.139.10 with HTTP; Tue, 8 May 2007 07:24:40 -0700 (PDT) Message-ID: <790a9fff0705080724o1039c405g1cfa1b31ba6a91be@mail.gmail.com> Date: Tue, 8 May 2007 09:24:40 -0500 From: "Scot Hetzel" To: "Bruce Evans" In-Reply-To: <20070507124848.S47783@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0705021345j2ad9ae98o56aaf357d556fe27@mail.gmail.com> <790a9fff0705040004oab16ed8q1a1c476386379ea9@mail.gmail.com> <20070504190007.Y37951@besplex.bde.org> <790a9fff0705040819u24e4c2f0s5c9fc34b93770e13@mail.gmail.com> <790a9fff0705061005v1a1a883ehc155bac7f747c3eb@mail.gmail.com> <20070507124848.S47783@besplex.bde.org> Cc: emulation@freebsd.org, Pawel Jakub Dawidek Subject: Re: linuxolator: LTP lseek03 failure X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 14:24:43 -0000 On 5/6/07, Bruce Evans wrote: > On Sun, 6 May 2007, Scot Hetzel wrote: > > > On 5/4/07, Scot Hetzel wrote: > > >> Would the best fix be to change the native lseek to return EINVAL when > >> fo_ioctl returns ENOTTY? > > Probably. > > > I had a look at the OpenSolaris implementation of lseek and found that > > we are returning the wrong error code for the ENOTTY case. When > > ENOTTY is returned by fo_ioctl, we should be checking for the > > following cases: > > > > SEEK_DATA - Is offset past end of file > > SEEK_HOLE - Return virtual hole at end of file, if offset is valid > > > > on error, SEEK_DATA and SEEK_HOLE should be returning ENXIO for these > > cases. OpenSolaris also checks offset > OFF_MAX, and returns > > EOVERFLOW. > > > > When the lseek03 test is run, with these changes, it returns with ENXIO. > > Shouldn't it return with EOVERFLOW even for zfs? I guess the test doesn't > check for that, so the result should be EINVAL for non-zfs and maybe > ENXIO for zfs if the test didn't set up right for the seeks to work > (presumably it sets the offset to something reasonable so as not to get > spurious errors from args other than `whence', but it expects i/o to fail > so it doesn't set up for i/o. > > > I sent the attached patch for kern/vfs_syscalls.c to pjd for review. > I ran the lseek03 test on a unpatched kernel with a ZFS filesystem mounted on gentoo-stage3/tmp. The lseek03 test did return with ENXIO with the ZFS tmp, and ENOTTY with a UFS tmp. I then created a patch to kern/vfs_vnops.c:vn_ioctl that checked if com was either SEEK_DATA or SEEK_HOLE and return EINVAL. While this worked for UFS, it disabled SEEK_[DATA,HOLE] for ZFS. So this wasn't the correct fix either. The vn_ioctl function calls VOP_IOCTL. Should the fix be applied to VOP_IOCTL, or added to per filesystem *_ioctl functions. Where is VOP_IOCTL defined in the src tree? Scot Bruce thanks for your review of the code. -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised.