On Tue, Apr 25, 2017 at 4:42 PM, J . Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Tue, Apr 25, 2017 at 02:29:35PM +0300, Amir Goldstein wrote: >> When delivering an event to userspace for a file on an NFS share, >> if the file is deleted on server side before user reads the event, >> user will not get the event. >> >> If the event queue contained several events, the stale event is >> quietly dropped and read() returns to user with events read so far >> in the buffer. >> >> If the event queue contains a single stale event or if the stale >> event is a permission event, read() returns to user with the kernel >> internal error code 518 (EOPENSTALE), which is not a POSIX error code. >> >> Check the internal return value -EOPENSTALE in fanotify_read(), just >> the same as it is checked in path_openat() and drop the event in the >> cases that it is not already dropped. > > Makes sense to me. > > Of course we can't prevent the case where a file's deleted on the server > after the read but before the application uses the event, so the > application could see ESTALE on a later operation; but that's not the > case you're talking about here. > Sure. This is not meant to prevent ESTALE, just to prevent EOPENSTALE and there was no point to report ESTALE to the user in this case. I do have another patch coming up to fix the same issue in overlayfs, where I do return ESTALE instead of EOPENSTALE. Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
