Re: [PATCH] ovl: don't expose EOPENSTALE to userspace

[Marko Rauhamaa <marko.rauhamaa@f-secure.com>]

Miklos Szeredi <miklos@szeredi.hu>:

> I'm looking at the EOPENSTALE story and it very much looks like we can
> just replace the single use with ESTALE and handle the lookup retry
> logic nuances inside the lookup code...

The fanotify problem is not simply a matter of choosing a POSIX name for
an error. The question is, what problems should an fanotify application
be prepared to handle and what should it do about them?

Since a misbehaving fanotify application is likely to hang the entire
operating system, it needs very clear guidelines for correct behavior.
In particular, when the application does a read(2) on an fanotify file
descriptor and gets back an error code, how is the application to
recover gracefully and safely?

Amir's patch shields the fanotify application from EOPENSTALE. I would
very much like an extensive list of errors that read(2) on a fanotify fd
can return. As it stands, I'm only aware of EAGAIN in the nonblocking
case and EINTR in the blocking case -- and even those haven't been
explicitly documented.


Marko