Date: Fri, 4 May 2007 21:20:34 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Roman Divacky <rdivacky@freebsd.org> Cc: emulation@freebsd.org, Scot Hetzel <swhetzel@gmail.com> Subject: Re: linuxolator: LTP lseek03 failure Message-ID: <20070504212034.135246d5@deskjail> In-Reply-To: <20070504163536.GA4479@freebsd.org> References: <790a9fff0705021345j2ad9ae98o56aaf357d556fe27@mail.gmail.com> <790a9fff0705040004oab16ed8q1a1c476386379ea9@mail.gmail.com> <20070504190007.Y37951@besplex.bde.org> <790a9fff0705040819u24e4c2f0s5c9fc34b93770e13@mail.gmail.com> <20070504163536.GA4479@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Roman Divacky <rdivacky@freebsd.org> (Fri, 4 May 2007 18:35:36 +0200): > 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? It depends... For opening of a directory (fails in linux) we should be compatible (programs may expect it, AFAIR at least acroread or realplay rely upon some kind of such behavior), but for the SEEK stuff which is discussed here I'm indifferent. If POSIX (or something else) uses fixed values which are used here, then I don't see a reason to limit this, but if no fixed value is provided, I lean towards forbidding it in the linuxulator (what if linux implements it with switched values?). Bye, Alexander. -- We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, "By Any Other Name", stardate 4657.5 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070504212034.135246d5>