On 19 December 2017 at 18:52, Keno Fischer [off-list ref] wrote:

Yes it seems like an EINTR return should be considered a bug, so please drop
this from your patch queue. Thanks for the follow up.

Okay -- thanks for the info.

Cheers,

Michael

On Dec 19, 2017 14:57, "Michael Kerrisk (man-pages)"
[off-list ref] wrote:

quoted

Hi Keno,

On 12/04/2017 10:03 PM, Keno Fischer wrote:

quoted

Hi Michael,

I was hoping to get a clear statement one way or another from the kernel
maintainers as to whether an EINTR from stat() is supposed to be allowed
kernel behavior (hence the RFC in the subject). If it's not, then I
don't think
it should be documented, even if there is buggy filesystems that do at
the moment.
So I'd say let's hold off on applying this until more people have had a
chance
to comment. If it would be more convenient for you, feel free to drop
this from your
patch queue and if appropriate, I'll resend a non-RFC version of this
patch for you
to apply, once a conclusion has been reached.

So, was there any further conclusion on this?

Cheers,

Michael

quoted

On Mon, Dec 4, 2017 at 3:58 PM, Michael Kerrisk (man-pages)
[off-list ref] wrote:

quoted

Hello Keno

On 12/03/2017 04:15 AM, Keno Fischer wrote:

quoted

Resending as plain text (apologies for those receiving it twice, and
those that got
an HTML copy, I'm used to my mail client switching that over
automatically, which
for some reason didn't happen here).


This is exactly the discussion I want to generate, so thank you.
I should point out that I'm not advocating for anything other
than clarity of what kernel behavior user space may assume.

So, should the documentation patch be applied at this point, or
dropped?

Thanks,

Michael

quoted

On Sat, Dec 2, 2017 at 9:25 PM, Matthew Wilcox [off-list ref]
wrote:

quoted

On Sat, Dec 02, 2017 at 07:23:59PM -0500, Keno Fischer wrote:

quoted

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.

Wait, wait, wait.  killable is not uninterruptible.  It's "can accept
a signal if the signal is fatal".  ie userspace will never see it.
So, no, it doesn't prevent ^C.  It does prevent the debugging tool
you're
talking about from working, because it's handling the signal, so it's
not
fatal.

This probably shows that I've been in REPL based environments too
long,
that catch SIGINT ;). You are of course correct that a fatal SIGINT
would
still be delivered.

quoted

quoted

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.

A change to user-visible behaviour has to be opt-in.

I agree. However, it was my impression that stat() can return EINTR
depending on the file system. Prior to the referenced commit,
this was certainly true on 9p and I suspect it's not the only network
file
system for which this is true (though prior to my experiencing this
with 9p, the only
time I've ever experienced it was on HPC clusters with who knows what
code providing the network filesystem). If it is indeed the case that
an EINTR return from stat() and similar is illegal and should be
considered
a kernel bug, a statement to that extent all I'm looking for here.

--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/