Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR

[Michael Kerrisk (man-pages)]

Hi Keno,

On 12/04/2017 10:03 PM, Keno Fischer wrote:
> 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

> On Mon, Dec 4, 2017 at 3:58 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@xxxxxxxxx> wrote:
>> Hello Keno
>>
>> On 12/03/2017 04:15 AM, Keno Fischer wrote:
>>> 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
>>
>>
>>> On Sat, Dec 2, 2017 at 9:25 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>>>> On Sat, Dec 02, 2017 at 07:23:59PM -0500, Keno Fischer wrote:
>>>>> 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.
>>>
>>>>> 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/