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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:   Tue, 19 Dec 2017 20:28:28 +0100
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Keno Fischer <keno@...iacomputing.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        linux-man <linux-man@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>, tuomas@...era.com
Subject: Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR

On 19 December 2017 at 18:52, Keno Fischer <keno@...iacomputing.com> 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)"
> <mtk.manpages@...il.com> wrote:
>>
>>
>> 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@...il.com> 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@...radead.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/
>> >
>>
>>
>> --
>> 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/