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) and the XFS specific XFS_IOC_OPEN_BY_HANDLE ioctl. I don't know if that's called a bug or out of date documentation. RHEL must have picked up this bug fix so have the same behavior as upstream now. > * The kernel in question is kernel-3.10.0-229.el7.x86_64 (RHEL 7.3). I > will take it up with Red Hat if necessary. However, is this a known > issue that has been fixed in a newer kernel version? > > > Marko
