Date: Wed, 9 May 2007 22:48:56 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Scot Hetzel <swhetzel@gmail.com> Cc: emulation@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: linuxolator: LTP lseek03 failure Message-ID: <20070509223211.O6076@delplex.bde.org> In-Reply-To: <790a9fff0705080724o1039c405g1cfa1b31ba6a91be@mail.gmail.com> 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> <790a9fff0705080724o1039c405g1cfa1b31ba6a91be@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 May 2007, Scot Hetzel wrote: > On 5/6/07, Bruce Evans <bde@zeta.org.au> wrote: >> On Sun, 6 May 2007, Scot Hetzel wrote: >> >> > On 5/4/07, Scot Hetzel <swhetzel@gmail.com> wrote: >> >> >> Would the best fix be to change the native lseek to return EINVAL when >> >> fo_ioctl returns ENOTTY? >> >> Probably. >> ... > 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. I meant to just translate ENOTTY to EINVAL after calling VOP_IOCTL(). The vop must be called to see what it wants to do. > 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? VOP_IOCTL is automatically generated from vnode_if.src into vnode_if.h. The contents of vnode_if.h is uninteresting -- it is just glue code, and you usually don't want to add to it (but there are some debugging hooks that add to it). When a whole ioctl is not supported, VOP_IOCTL just calls vop_enotty() which just returns ENOTTY. You probably don't want to add to this either -- for of its most callers, ENOTTY is the correct error code. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070509223211.O6076>