On Wed, Mar 22, 2017 at 2:20 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Wed, Mar 22, 2017 at 11:31 AM, Marko Rauhamaa > <marko.rauhamaa@xxxxxxxxxxxx> wrote: >> >> An F-Secure product uses fanotify with OPEN_PERM. We ran into an >> unexpected situation: a read(2) on the fanotify fd returned -1 with >> errno == EOPENSTALE. The only place in the (development) kernel where I >> can find EOPENSTALE is in nfs4file.c:nfs4_file_open(). >> > > Hi Marko, > > Is this issue reproducible? > Which file system is the notification coming from? NFS? > >> Questions: >> >> * Should an fanotify client expect EOPENSTALE from read(2)? >> > > The fanotify event metadata->fd can be an error (e.g. EOPENSTALE), > so if you don't check that the fd you get is valid (>=0) > I suppose glibc might be setting errno if you pass > it a negative fd??? > > Anyway, over NFS it seems that something like this can happen. > >> * According to <URL: >> https://github.com/torvalds/linux/blob/master/include/linux/errno.h>, >> EOPENSTALE "should never be seen by user programs." Is this a kernel >> bug? >> > > Well, the behavior was changed in kernel 4.7 (and stable kernels) by > commit by Al Viro: > fac7d19 fix EOPENSTALE bug in do_last() > > Since that commit userspace will be able to see this error in fanotify events. > I can't say for sure about other ways that this error could get to > user, but a quick > grep for users of dentry_open() that don't convert EOPENSTALE such as > fanotify finds: > autofs4, ecrypts, cachefiles, overlayfs (the error may be converted higher up) from code audit of the modules above I think only APIs that *may* be leaking EOPENSTALE to userspace (besides fanotify and xfs open by handle) are: - autofs_dev_ioctl_openmount - overlayfs readdir (when opening lower NFS dir) Amir.
