Re: [PATCH] open(2): document O_PATH

["Aneesh Kumar K.V" <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Aneesh,
>
>>
>> I don't know much about markers, but as per fsnotify_backend.h
>>
>> /*
>>  * a mark is simply an object attached to an in core inode which allows an
>>  * fsnotify listener to indicate they are either no longer interested in events
>>  * of a type matching mask or only interested in those events.
>>  *
>>  * these are flushed when an inode is evicted from core and may be flushed
>>  * when the inode is modified (as seen by fsnotify_access).  Some fsnotify users
>>  * (such as dnotify) will flush these when the open fd is closed and not at
>>  * inode eviction or modification.
>>  */
>> struct fsnotify_mark {
>
> Unfortunately, I'm still none the wiser about what this means for
> O_PATH file descriptors...
>

I looked at dnotify_flush, they remove markers on an inode.
But then it also checks for filp to match. So I am not sure
whether skipping dnotify_flush for O_PATH descriptor have any impact. We
can't use O_PATH descriptor for dnotify fcntl any way. So in
dnotify_flush we will not match the filp.

Viro,

Any reason why we skip dnotify_flush  ?


-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html