linuxolator: LTP lseek03 failure

[Roman Divacky]

On Fri, May 04, 2007 at 10:19:56AM -0500, Scot Hetzel wrote:
> On 5/4/07, Bruce Evans <bde at zeta.org.au> wrote:
> >On Fri, 4 May 2007, Scot Hetzel wrote:
> >
> >> On 5/2/07, Scot Hetzel <swhetzel at gmail.com> wrote:
> >>> I have investigated the new LTP test failure for lseek03, and the
> >>> first test sets whence to 4 (SEEK_HOLE):
> >>>
> >>> test 1 lseek(tfile_1554, 1, 4) Failed, errno=25 Inappropriate ioctl
> >>> for device, expected 22(EINVAL)
> >>>
> >> Looking thru -CURRENT, I found that SEEK_HOLE and SEEK_DATA were added
> >> to lseek (sys/kern/vfs_syscalls.c 1.437) on April 5th, 2007 by pjd as
> >> a requirement for the ZFS implementation.
> >
> >The main bug is in the implementation of SEEK_HOLE and SEEK_DATA.  This
> >uses fo_ioctl() and fo_ioctl() returns ENOTTY if the file system doesn't
> >support these seeks, but ENOTTY (Inappropriate ioctl for device) is a
> >very inappropriate errno for a syscall that is not ioctl(), especially
> >on a file that is not a device.  POSIX requires EINVAL if the `whence'
> >arg is not a standard POSIX one, and I think ENOTTY should be translated
> >to this.
> >
> 
> I see three places where this could be fixed:
> 
> kern/vfs_vnops.c:vn_ioctl(...)
> kern/vfs_syscalls.c:lseek(...)
> compat/linux/linux_file.c:(linux_lseek and linux_llseek)

I was thikning a lot about these things and I think that we should NOT fix
cases where we allow something what linux forbids. I mean for example maximum
number of fds opened, support for SEEK_HOLE etc.

why cripple what we provide to the programs?