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

From: William Kucharski <william.kucharski@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Yufen Yu <yuyufen@huawei.com>,
	viro@zeniv.linux.org.uk, hughd@google.com, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org
Subject: Re: [PATCH] tmpfs: let lseek return ENXIO with a negative offset
Date: Thu, 8 Nov 2018 03:46:35 -0700	[thread overview]
Message-ID: <EDFDF8C6-F164-4C5A-A5D3-010802D02DC2@oracle.com> (raw)
In-Reply-To: <20181107151955.777fcbcf9a5932677e245287@linux-foundation.org>

> On Nov 7, 2018, at 4:19 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> man 2 lseek says
> 
> :      EINVAL whence  is  not  valid.   Or: the resulting file offset would be
> :             negative, or beyond the end of a seekable device.
> :
> :      ENXIO  whence is SEEK_DATA or SEEK_HOLE, and the file offset is  beyond
> :             the end of the file.
> 
> 
> Make tmpfs return ENXIO under these circumstances as well.  After this,
> tmpfs also passes xfstests's generic/448.

As I objected to last week, despite the fact that other file systems do this, is
this in fact the desired behavior?

I'll let you reread that message rather than repeat it in its entirety here, but
certainly a negative offset is not "beyond the end of the file," and the end
result is errno is set to ENXIO for a reason that does not match what the
lseek(2) man page describes.

I also mentioned if a negative offset is used with SEEK_CUR or SEEK_WHENCE,
arguably the negative offset should actually be treated as "0" given lseek(2)
also states:

      SEEK_DATA
             Adjust the file offset to the next location in the file
             greater than or equal to offset containing data.  If offset
             points to data, then the file offset is set to offset.

      SEEK_HOLE
             Adjust the file offset to the next hole in the file greater
             than or equal to offset.  If offset points into the middle of
             a hole, then the file offset is set to offset.  If there is no
             hole past offset, then the file offset is adjusted to the end
             of the file (i.e., there is an implicit hole at the end of any
             file).

Since the "next location" or "next hole" will never be at a negative offset, the
"greater than" clause of both descriptions would mean the resulting offset should
be treated as if it were passed as zero.

However, if xfstest-compliant behavior is desired, the lseek(2) man page
description for ENXIO should be updated to something like:

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

I don't mean to be pedantic, but I also know how frustrating it can be when a system
call returns with errno set for a reason that doesn't correspond to the man page.

    Thanks,
         William Kucharski