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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]