From: Marko Rauhamaa <marko.rauhamaa@f-secure.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Trond Myklebust <trondmy@primarydata.com>,
Jeff Layton <jlayton@poochiereds.net>,
"J . Bruce Fields" <bfields@fieldses.org>,
Tyler Hicks <tyhicks@canonical.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-unionfs@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"stable [v4.9]" <stable@vger.kernel.org>
Subject: Re: [PATCH] ovl: don't expose EOPENSTALE to userspace
Date: Thu, 27 Apr 2017 10:40:57 +0300 [thread overview]
Message-ID: <87tw5a47sm.fsf@drapion.f-secure.com> (raw)
In-Reply-To: <CAOQ4uxiODuLDYLouWJppgPkew16tTeOTxk+UTmP6Bdt2fJY6Mw@mail.gmail.com> (Amir Goldstein's message of "Wed, 26 Apr 2017 18:45:54 +0300")
Amir Goldstein <amir73il@gmail.com>:
> There are more error that you can get same way that you got
> EOPENSTALE. The fact that I filtered EOPENSTALE is fixing a POSIX bug,
> but it does not fix the general problem you described.
>
> For example, I know you can get ENODEV, because I got it on
> out test env. This is the case of a "stale device node" - by the time
> you get to read an access event generated on a device file, the device
> that this file represents does not exists and cannot be opened.
>
> As with the case of EOPENSTALE, your app should just read again
> when that happens.
Thing is, I must treat every unknown error value as critical and exit.
That's because the problem might be persistent and spinning in a read
loop hangs the system.
Unless, of course, the system call API explicitly declares all problems
as transient and tells the application to retry indefinitely. ENODEV
certainly doesn't have the ring of a transient error.
I don't really see why read(2) on the fanotify fd should return any
random errors. The fanotify fd is purely a software device and should
only have a fixed, documented set of failure modes. The other file
descriptor (metadata->fd) is tied to a real file and could fail in a
million ways; that's understandable.
Marko
--
+358 44 990 4795
Skype: marko.rauhamaa_f-secure
WARNING: multiple messages have this Message-ID (diff)
From: Marko Rauhamaa <marko.rauhamaa@f-secure.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Trond Myklebust <trondmy@primarydata.com>,
Jeff Layton <jlayton@poochiereds.net>,
"J . Bruce Fields" <bfields@fieldses.org>,
Tyler Hicks <tyhicks@canonical.com>,
Al Viro <viro@zeniv.linux.org.uk>,
<linux-unionfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"stable [v4.9]" <stable@vger.kernel.org>
Subject: Re: [PATCH] ovl: don't expose EOPENSTALE to userspace
Date: Thu, 27 Apr 2017 10:40:57 +0300 [thread overview]
Message-ID: <87tw5a47sm.fsf@drapion.f-secure.com> (raw)
In-Reply-To: <CAOQ4uxiODuLDYLouWJppgPkew16tTeOTxk+UTmP6Bdt2fJY6Mw@mail.gmail.com> (Amir Goldstein's message of "Wed, 26 Apr 2017 18:45:54 +0300")
Amir Goldstein <amir73il@gmail.com>:
> There are more error that you can get same way that you got
> EOPENSTALE. The fact that I filtered EOPENSTALE is fixing a POSIX bug,
> but it does not fix the general problem you described.
>
> For example, I know you can get ENODEV, because I got it on
> out test env. This is the case of a "stale device node" - by the time
> you get to read an access event generated on a device file, the device
> that this file represents does not exists and cannot be opened.
>
> As with the case of EOPENSTALE, your app should just read again
> when that happens.
Thing is, I must treat every unknown error value as critical and exit.
That's because the problem might be persistent and spinning in a read
loop hangs the system.
Unless, of course, the system call API explicitly declares all problems
as transient and tells the application to retry indefinitely. ENODEV
certainly doesn't have the ring of a transient error.
I don't really see why read(2) on the fanotify fd should return any
random errors. The fanotify fd is purely a software device and should
only have a fixed, documented set of failure modes. The other file
descriptor (metadata->fd) is tied to a real file and could fail in a
million ways; that's understandable.
Marko
--
+358 44 990 4795
Skype: marko.rauhamaa_f-secure
next prev parent reply other threads:[~2017-04-27 7:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-25 13:57 [PATCH] ovl: don't expose EOPENSTALE to userspace Amir Goldstein
2017-04-26 13:47 ` Miklos Szeredi
2017-04-26 14:06 ` Marko Rauhamaa
2017-04-26 14:06 ` Marko Rauhamaa
2017-04-26 15:45 ` Amir Goldstein
2017-04-27 7:40 ` Marko Rauhamaa [this message]
2017-04-27 7:40 ` Marko Rauhamaa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tw5a47sm.fsf@drapion.f-secure.com \
--to=marko.rauhamaa@f-secure.com \
--cc=amir73il@gmail.com \
--cc=bfields@fieldses.org \
--cc=jlayton@poochiereds.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stable@vger.kernel.org \
--cc=trondmy@primarydata.com \
--cc=tyhicks@canonical.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.