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

From: Michael Kerrisk (man-pages)
Date: Thu May 03 2012 - 02:47:52 EST


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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/