Re: [PATCH] tmpfs: let lseek return ENXIO with a negative offset

[William Kucharski <william.kucharski@oracle.com>]

> On Nov 8, 2018, at 4:07 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> I think that at this stage we should make tmpfs behaviour match the
> other filesystems.
> 
> If the manpage doesn't match the kernel's behaviour for this
> linux-specific feature(?) then we should fix the manpage.
> 
> If we find that the behaviour should actually change (and there's a way
> of doing that in a reasonably back-compatible manner) then let's change
> all filesystems and the manpage.
> 
> OK?

I did a little research, and according to lseek(2):

       SEEK_DATA and SEEK_HOLE are nonstandard extensions also present in
       Solaris, FreeBSD, and DragonFly BSD; they are proposed for inclusion
       in the next POSIX revision (Issue 8).
 
I wrote a brief test program that operated on a file of 1024 zeroes and found
that on an ext4 file system, lseek(2) matches Solaris' behavior on ZFS:

Solaris/ZFS
===========
lseek(3, -1, SEEK_HOLE) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_HOLE) returned 1024
lseek(3, 1, SEEK_HOLE) returned 1024

lseek(3, -1, SEEK_DATA) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_DATA) returned 0
lseek(3, 1, SEEK_DATA) returned 1

Linux/ext4
==========
lseek(3, -1, SEEK_HOLE) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_HOLE) returned 1024
lseek(3, 1, SEEK_HOLE) returned 1024

lseek(3, -1, SEEK_DATA) error, errno 6 (ENXIO)
lseek(3, 0, SEEK_DATA) returned 0
lseek(3, 1, SEEK_DATA) returned 1

That validates the xfstest expectations that a negative passed offset should
return ENXIO.

I suggest the man page wording be changed to read:

       ENXIO  whence is SEEK_DATA or SEEK_HOLE, and the file offset is negative or
              beyond the end of the file.

unless you'd prefer an alternative statement.

Thanks!!