Date: Fri, 4 May 2007 18:35:36 +0200 From: Roman Divacky <rdivacky@freebsd.org> To: Scot Hetzel <swhetzel@gmail.com> Cc: emulation@freebsd.org Subject: Re: linuxolator: LTP lseek03 failure Message-ID: <20070504163536.GA4479@freebsd.org> In-Reply-To: <790a9fff0705040819u24e4c2f0s5c9fc34b93770e13@mail.gmail.com> References: <790a9fff0705021345j2ad9ae98o56aaf357d556fe27@mail.gmail.com> <790a9fff0705040004oab16ed8q1a1c476386379ea9@mail.gmail.com> <20070504190007.Y37951@besplex.bde.org> <790a9fff0705040819u24e4c2f0s5c9fc34b93770e13@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 04, 2007 at 10:19:56AM -0500, Scot Hetzel wrote: > On 5/4/07, Bruce Evans <bde@zeta.org.au> wrote: > >On Fri, 4 May 2007, Scot Hetzel wrote: > > > >> On 5/2/07, Scot Hetzel <swhetzel@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070504163536.GA4479>