From: walter harms <wharms@bfs.de>
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
Date: Sun, 03 Dec 2017 17:09:03 +0100 [thread overview]
Message-ID: <5A24219F.4010802@bfs.de> (raw)
In-Reply-To: <20171203002359.GA17037@juliacomputing.com>
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;
prev parent reply other threads:[~2017-12-03 16:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-03 0:23 [PATCH RFC] stat.2: Document that stat can fail with EINTR Keno Fischer
2017-12-03 2:25 ` Matthew Wilcox
2017-12-03 3:15 ` Keno Fischer
2017-12-04 20:58 ` Michael Kerrisk (man-pages)
2017-12-04 21:03 ` Keno Fischer
2017-12-19 13:57 ` Michael Kerrisk (man-pages)
[not found] ` <CABV8kRxw97+YCWuZHvcFPsUA7HbtKXjYL+0UVMqa0mC7q2RssA@mail.gmail.com>
2017-12-19 19:28 ` Michael Kerrisk (man-pages)
2017-12-04 22:31 ` Matthew Wilcox
2017-12-03 16:09 ` walter harms [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5A24219F.4010802@bfs.de \
--to=wharms@bfs.de \
--cc=keno@juliacomputing.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=tuomas@tuxera.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).