Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org,
        linux-fsdevel@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        viro@zeniv.linux.org.uk, tuomas@tuxera.com
Subject: Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR
To: Keno Fischer <keno@juliacomputing.com>,
        Matthew Wilcox <willy@infradead.org>
References: <20171203002359.GA17037@juliacomputing.com>
 <20171203022504.GA14505@bombadil.infradead.org>
 <CABV8kRwbsjW1XbybDx12HmC9Gd1_5_C-KDhdtEz12KSZf-84_Q@mail.gmail.com>
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Message-ID: <24ffa267-4d45-e6e8-2441-f82ce47ad725@gmail.com>
Date: Mon, 4 Dec 2017 21:58:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CABV8kRwbsjW1XbybDx12HmC9Gd1_5_C-KDhdtEz12KSZf-84_Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2653
Lines: 64

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@infradead.org> 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/