Jeff Layton <jlayton@xxxxxxxxxxxxxxx>: > It was definitely not the intention to leak this error code to > userland. EOPENSTALE is not a POSIX sanctioned error code, so > applications generally don't know anything about it and will be > confused. Got it. I will try to work on a reproduction and make a proper bug report. > I haven't looked closely at this particular problem, but IIRC we > usually just translate EOPENSTALE to ESTALE, and that may be all that > needs to be done here. If this happened in the RHEL kernel, then > please do open a bug with Red Hat and we'll get it straightened out. ESTALE has not been mentioned as a possible error code from an fanotify read. Most importantly, since read fails, I suppose there is no recovery but you must close the fanotify fd and call fanotify_init() again. Or should I just ignore it and read on? If so, why bother returning the error from the kernel in the first place? > That said, you should take heed that all of the [fa|i|d]notify APIs do > not extend beyond the local machine when you use them on network > filesystems. If you're expecting to get notification of events that > are occurring on other clients, you're going to be disappointed here. That certainly is disappointing. However, there is a certain level of coherency one would expect, namely: * An NFS4 client opening a file should be subject to an OPEN_PERM check on that client (if the client is monitoring the mount point). * An NFS4 client opening a file should be subject to an OPEN_PERM check on the server (if the server is monitoring the mount point). * An fanotify read should not fail mysteriously. Rather, a read on metadata->fd should be the one failing. Marko
