Aneesh,
[...]
>> --- a/man2/open.2
>> +++ b/man2/open.2
>> @@ -428,6 +427,66 @@ For a discussion of the effect of
>> ?in conjunction with mandatory file locks and with file leases, see
>> ?.BR fcntl (2).
>> ?.TP
>> +.BR O_PATH " (since Linux 2.6.39)"
>> +.\" commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bd
>> +Obtain a file descriptor that is used only for fetching file attributes.
>> +The file itself is not opened, and most file operations (e.g.,
>> +.BR read (2),
>> +.BR write (2))
>> +fail with the error
>> +.BR EBADF .
>> +The following operations
>> +.I can
>> +be performed on the resulting file descriptor:
>> +.RS
>> +.IP * 3
>> +Closing the file descriptor
>> +.RB ( close (2)).
>> +.\" FIXME Commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bdcw
>> +.\" message says that closing the file descriptor does not affect
>> +.\" POSIX locks or dnotify.
>> +.\" However, my testing shows that it DOES affect dnotify (and inotify).
>> +.\" Does close() affect POSIX locks?
>> +.IP *
>
>
> IIUC what an O_PATH descritor doesn't do is to flush dnotify markers
>
> ? ? ? ?if (likely(!(filp->f_mode & FMODE_PATH))) {
> ? ? ? ? ? ? ? ?dnotify_flush(filp, id);
> ? ? ? ? ? ? ? ?locks_remove_posix(filp, id);
> ? ? ? ?}
>
> 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...
> It also doesn't remove posix locks. I tested this with a test prg
>
> ? ?struct flock flock;
> ? ?flock.l_type = F_WRLCK;
> ? ?flock.l_whence = SEEK_SET;
> ? ?flock.l_start = 0;
> ? ?flock.l_len = 0;
> ? ?fd = open(argv[1], O_RDWR);
> ? ?fcntl(fd, F_SETLKW, &flock);
> ? ?fd = open(argv[1], O_PATH);
> ? ?close(fd);
>
> The close doesn't result in lock release.
Okay -- I'll add mention of this to the O_PATH description.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
"Michael Kerrisk (man-pages)" <[email protected]> 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
On Thu, May 03, 2012 at 07:34:35PM +0530, Aneesh Kumar K.V wrote:
> 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 ?
See your last sentence above - why bother finding the mark, scanning the
list, etc. when we know that there won't be any matches?
On Fri, May 4, 2012 at 2:11 AM, Al Viro <[email protected]> wrote:
> On Thu, May 03, 2012 at 07:34:35PM +0530, Aneesh Kumar K.V wrote:
>
>> 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 ??
>
> See your last sentence above - why bother finding the mark, scanning the
> list, etc. when we know that there won't be any matches?
So, am I correct to understand that O_PATH has no interaction with dnotify?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/