Message-ID: <5A24219F.4010802@bfs.de>
Date: Sun, 03 Dec 2017 17:09:03 +0100
From: walter harms <wharms@bfs.de>
Reply-To: wharms@bfs.de
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11
MIME-Version: 1.0
To: Keno Fischer <keno@juliacomputing.com>
CC: linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
        mtk.manpages@gmail.com, tuomas@tuxera.com
Subject: Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR
References: <20171203002359.GA17037@juliacomputing.com>
In-Reply-To: <20171203002359.GA17037@juliacomputing.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2242
Lines: 64


Am 03.12.2017 01:23, schrieb Keno Fischer:
> Particularly on network file systems, a stat call may require
> submitting a message over the network and waiting interruptably
> for a reply.
> 
> Signed-off-by: Keno Fischer <keno@juliacomputing.com>
> ---
> 
> The catalyst for this patch was me experiencing EINTR errors when
> using the 9p file system. In linux commit 9523feac, the 9p file
> system was changed to use wait_event_killable instead of
> wait_event_interruptible, which does indeed address my problem,
> but also makes me a bit unhappy, because uninterruptable waits
> prevents things like ^C'ing the execution and some debugging
> tools which depend on being able to cancel long-running operations
> by sending signals. I'd like to ask the user space applications I
> care about to properly handle such situations (either by using
> SA_RESTART or by explicitly handling EINTR), but it's a bit of a
> hard sell if EINTR isn't documented to be a possibility. I'm hoping
> this doc PATCH will generate a discussion of whether EINTR is an
> appropriate thing for stat (as a stand in for a file system call that's
> not read/write) to return. If so, I'd be happy to submit
> patches to other file system-related syscalls along these same lines.
> 
> I realize I'm probably 20 years too late here, but it feels like
> clarificaion on what to expect from the kernel would still go a long
> way here.  
> 

no matter, if it can happen it should be document.
Nothing is more anoying that triggering an undocumented error.


>  man2/stat.2 | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/man2/stat.2 b/man2/stat.2
> index dad9a01..f10235a 100644
> --- a/man2/stat.2
> +++ b/man2/stat.2
> @@ -452,6 +452,11 @@ Invalid flag specified in
>  is relative and
>  .I dirfd
>  is a file descriptor referring to a file other than a directory.
> +.TP
> +.B EINTR
> +The call was interrupted by delivery of a signal caught by a handler; see
What is about:
  The call was interrupted by a
.BR signal (7).
> +.BR signal (7).
> +The possibility of this error is file-system dependent.
You mean:
  This error is file-system dependent.

just my 2 cents,
re,
 wh

>  .SH VERSIONS
>  .BR fstatat ()
>  was added to Linux in kernel 2.6.16;