linuxolator: LTP lseek03 failure

[Scot Hetzel]

On 5/6/07, Bruce Evans <bde at zeta.org.au> wrote:
> On Sun, 6 May 2007, Scot Hetzel wrote:
>
> > On 5/4/07, Scot Hetzel <swhetzel at gmail.com> 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.