stat.2: Document that stat can fail with EINTR

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 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.

Quoted 8 lines · Keno Fischer

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.

Quoted 3 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.

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

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.

Quoted 10 lines · Keno Fischer

Quoted 8 lines

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.

Quoted 5 lines

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 5 lines

Quoted 3 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.

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.

Hello Keno

Quoted 10 lines · Keno Fischer

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 27 lines · Matthew Wilcox

Quoted 10 lines · Keno Fischer

Quoted 8 lines

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.

Quoted 5 lines

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 5 lines

Quoted 3 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.

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

Quoted 10 lines

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/

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.

Quoted 64 lines · Michael Kerrisk (man-pages)

Hello Keno

Quoted 10 lines · Keno Fischer

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 27 lines · Matthew Wilcox

Quoted 10 lines · Keno Fischer

Quoted 8 lines

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.

Quoted 5 lines

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 5 lines

Quoted 3 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.

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

Quoted 10 lines

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/

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.

Quoted 108 lines · Michael Kerrisk (man-pages)

Hi Keno,

Quoted 15 lines · Keno Fischer

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 70 lines

Quoted 68 lines · Michael Kerrisk (man-pages)

Hello Keno

Quoted 10 lines · Keno Fischer

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 44 lines

Quoted 10 lines · Matthew Wilcox

Quoted 8 lines · Keno Fischer

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.

Quoted 7 lines

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 5 lines

Quoted 3 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.

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.

Quoted 5 lines

Quoted 4 lines

--
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/

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.

Quoted 10 lines · Keno Fischer

Quoted 8 lines

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.

Quoted 5 lines

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 5 lines

Quoted 3 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.

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.

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-9DCaDmOhoh+8M3too/[email protected]>

---

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.

 man2/stat.2 | 5 +++++
 1 file changed, 5 insertions(+)

man2/stat.2 +0 -0

index dad9a01..f10235a 100644