[PATCH] open: Document O_TMPFILE

[PATCH] open: Document O_TMPFILE

[Andy Lutomirski]

O_TMPFILE is new in Linux 3.11

Signed-off-by: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
---

This may have formatting issues -- I'm terrible at groff.

If the corresponding linkat patch makes it in, it would probably be
worth documenting as well:

https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/commit/?h=for-linus&id=bb2314b47996491bbc5add73633905c3120b6268

 man2/open.2 | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/man2/open.2 b/man2/open.2
index ef0f664..8bf56a0 100644
--- a/man2/open.2
+++ b/man2/open.2
@@ -126,6 +126,7 @@ are
 .BR O_EXCL ,
 .BR O_NOCTTY ,
 .BR O_NOFOLLOW ,
+.BR O_TMPFILE ,
 .BR O_TRUNC ,
 and
 .BR O_TTY_INIT .
@@ -226,11 +227,15 @@ described in
 specifies the permissions to use in case a new file is created.
 This argument must be supplied when
 .B O_CREAT
+or
+.B O_TMPFILE
 is specified in
 .IR flags ;
-if
+if neither
 .B O_CREAT
-is not specified, then
+nor
+.B O_TMPFILE
+is specified, then
 .I mode
 is ignored.
 The effective permissions are modified by
@@ -284,6 +289,29 @@ The following symbolic constants are provided for
 00001 others have execute permission
 .RE
 .TP
+.BR O_TMPFILE " (Since Linux 3.11)"
+Create an unnamed temporary file.  The pathname parameter specifies a
+directory; an unnamed inode will be created in that directory's
+filesystem.  Anything written to the resulting file will be lost when
+the last fd is closed, unless the file is given a name.
+.RS
+.PP
+.B O_TMPFILE
+must be specified with one of
+.B O_RDWR
+or
+.B O_WRONLY
+and, optionally,
+.B O_EXCL.
+If O_EXCL is not specified, then
+.BR linkat (2)
+can be used to link the temporary file into the filesystem, making it
+permanent.
+.PP
+The mode parameter determines the inode's mode, as with
+.B O_CREAT.
+.RE
+.TP
 .BR O_DIRECT " (Since Linux 2.4.10)"
 Try to minimize cache effects of the I/O to and from this file.
 In general this will degrade performance, but it is useful in
-- 
1.8.3.1

--
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

Re: [PATCH] open: Document O_TMPFILE

[Michael Kerrisk (man-pages)]

[CC list expanded a littlle]

Andy (et al.)

See comments below.

On Wed, Aug 7, 2013 at 7:31 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> O_TMPFILE is new in Linux 3.11
>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>
> This may have formatting issues -- I'm terrible at groff.
>
> If the corresponding linkat patch makes it in, it would probably be
> worth documenting as well:
>
> https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/commit/?h=for-linus&id=bb2314b47996491bbc5add73633905c3120b6268
>
>  man2/open.2 | 32 ++++++++++++++++++++++++++++++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/man2/open.2 b/man2/open.2
> index ef0f664..8bf56a0 100644
> --- a/man2/open.2
> +++ b/man2/open.2
> @@ -126,6 +126,7 @@ are
>  .BR O_EXCL ,
>  .BR O_NOCTTY ,
>  .BR O_NOFOLLOW ,
> +.BR O_TMPFILE ,
>  .BR O_TRUNC ,
>  and
>  .BR O_TTY_INIT .
> @@ -226,11 +227,15 @@ described in
>  specifies the permissions to use in case a new file is created.
>  This argument must be supplied when
>  .B O_CREAT
> +or
> +.B O_TMPFILE
>  is specified in
>  .IR flags ;
> -if
> +if neither
>  .B O_CREAT
> -is not specified, then
> +nor
> +.B O_TMPFILE
> +is specified, then
>  .I mode
>  is ignored.
>  The effective permissions are modified by
> @@ -284,6 +289,29 @@ The following symbolic constants are provided for
>  00001 others have execute permission
>  .RE
>  .TP
> +.BR O_TMPFILE " (Since Linux 3.11)"
> +Create an unnamed temporary file.  The pathname parameter specifies a
> +directory; an unnamed inode will be created in that directory's
> +filesystem.  Anything written to the resulting file will be lost when
> +the last fd is closed, unless the file is given a name.
> +.RS
> +.PP
> +.B O_TMPFILE
> +must be specified with one of
> +.B O_RDWR
> +or
> +.B O_WRONLY
> +and, optionally,
> +.B O_EXCL.
> +If O_EXCL is not specified, then
> +.BR linkat (2)
> +can be used to link the temporary file into the filesystem, making it
> +permanent.
> +.PP
> +The mode parameter determines the inode's mode, as with
> +.B O_CREAT.
> +.RE
> +.TP
>  .BR O_DIRECT " (Since Linux 2.4.10)"
>  Try to minimize cache effects of the I/O to and from this file.
>  In general this will degrade performance, but it is useful in

See my reply to the thread started by Christoph Hellwig
(https://lwn.net/Articles/562297/). I've taken your man-pages patch,
and applied it in a branch. I tweaked the language and formatting a
bit, and also added documentation of the EINVAL and EISDIR (ick!)
error cases.

As noted in the other thread, the API is questionable in the opinion
of a few people. Maybe it will change, and this man-pages patch will
need some further tweaking. If that doesn't happen, I'll merge it as
is, at the time of the 3.11 stable release.

Cheers,

Michael

Re: [PATCH] open: Document O_TMPFILE

[Christoph Hellwig]

On Thu, Aug 08, 2013 at 02:00:18PM +0200, Michael Kerrisk (man-pages) wrote:
> See my reply to the thread started by Christoph Hellwig
> (https://lwn.net/Articles/562297/). I've taken your man-pages patch,
> and applied it in a branch. I tweaked the language and formatting a
> bit, and also added documentation of the EINVAL and EISDIR (ick!)
> error cases.
> 
> As noted in the other thread, the API is questionable in the opinion
> of a few people. Maybe it will change, and this man-pages patch will
> need some further tweaking. If that doesn't happen, I'll merge it as
> is, at the time of the 3.11 stable release.

Looks like my API comments were simplify ignored, so maybe it's time to
document things properly and pull the O_TMPFILE bits in?  

> 
> Cheers,
> 
> Michael
> --
> 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
---end quoted text---
--
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

Re: [PATCH] open: Document O_TMPFILE

[Michael Kerrisk (man-pages)]

On 08/07/2013 07:31 PM, Andy Lutomirski wrote:
> O_TMPFILE is new in Linux 3.11

Thanks, Andy. I've applied your patch. I also added the following
errors under ERRORS. Do they look okay to you?

       EINVAL O_TMPFILE  was  specified in flags, but neither O_WRONLY
              nor O_RDWR was specified.

       EISDIR O_TMPFILE  and  one of O_WRONLY or O_RDWR were specified
              in flags, but this kernel version does not  provide  the
              O_TMPFILE functionality.

Cheers,

Michael


> Signed-off-by: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> ---
> 
> This may have formatting issues -- I'm terrible at groff.
> 
> If the corresponding linkat patch makes it in, it would probably be
> worth documenting as well:
> 
> https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/commit/?h=for-linus&id=bb2314b47996491bbc5add73633905c3120b6268
> 
>  man2/open.2 | 32 ++++++++++++++++++++++++++++++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/man2/open.2 b/man2/open.2
> index ef0f664..8bf56a0 100644
> --- a/man2/open.2
> +++ b/man2/open.2
> @@ -126,6 +126,7 @@ are
>  .BR O_EXCL ,
>  .BR O_NOCTTY ,
>  .BR O_NOFOLLOW ,
> +.BR O_TMPFILE ,
>  .BR O_TRUNC ,
>  and
>  .BR O_TTY_INIT .
> @@ -226,11 +227,15 @@ described in
>  specifies the permissions to use in case a new file is created.
>  This argument must be supplied when
>  .B O_CREAT
> +or
> +.B O_TMPFILE
>  is specified in
>  .IR flags ;
> -if
> +if neither
>  .B O_CREAT
> -is not specified, then
> +nor
> +.B O_TMPFILE
> +is specified, then
>  .I mode
>  is ignored.
>  The effective permissions are modified by
> @@ -284,6 +289,29 @@ The following symbolic constants are provided for
>  00001 others have execute permission
>  .RE
>  .TP
> +.BR O_TMPFILE " (Since Linux 3.11)"
> +Create an unnamed temporary file.  The pathname parameter specifies a
> +directory; an unnamed inode will be created in that directory's
> +filesystem.  Anything written to the resulting file will be lost when
> +the last fd is closed, unless the file is given a name.
> +.RS
> +.PP
> +.B O_TMPFILE
> +must be specified with one of
> +.B O_RDWR
> +or
> +.B O_WRONLY
> +and, optionally,
> +.B O_EXCL.
> +If O_EXCL is not specified, then
> +.BR linkat (2)
> +can be used to link the temporary file into the filesystem, making it
> +permanent.
> +.PP
> +The mode parameter determines the inode's mode, as with
> +.B O_CREAT.
> +.RE
> +.TP
>  .BR O_DIRECT " (Since Linux 2.4.10)"
>  Try to minimize cache effects of the I/O to and from this file.
>  In general this will degrade performance, but it is useful in
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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

Re: [PATCH] open: Document O_TMPFILE

[Andy Lutomirski]

On Mon, Jan 20, 2014 at 4:52 AM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 08/07/2013 07:31 PM, Andy Lutomirski wrote:
>> O_TMPFILE is new in Linux 3.11
>
> Thanks, Andy. I've applied your patch. I also added the following
> errors under ERRORS. Do they look okay to you?
>
>        EINVAL O_TMPFILE  was  specified in flags, but neither O_WRONLY
>               nor O_RDWR was specified.
>
>        EISDIR O_TMPFILE  and  one of O_WRONLY or O_RDWR were specified
>               in flags, but this kernel version does not  provide  the
>               O_TMPFILE functionality.

I suspect that EISDIR only happens if the directory exists and is
accessible (matching the flags).  Otherwise EACCES and ENOENT sound
plausible.

Sigh.  Why wasn't this implemented as a brand new syscall?

--Andy
--
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

Re: [PATCH] open: Document O_TMPFILE

[Michael Kerrisk (man-pages)]

On 01/21/2014 01:14 AM, Andy Lutomirski wrote:
> On Mon, Jan 20, 2014 at 4:52 AM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 08/07/2013 07:31 PM, Andy Lutomirski wrote:
>>> O_TMPFILE is new in Linux 3.11
>>
>> Thanks, Andy. I've applied your patch. I also added the following
>> errors under ERRORS. Do they look okay to you?
>>
>>        EINVAL O_TMPFILE  was  specified in flags, but neither O_WRONLY
>>               nor O_RDWR was specified.
>>
>>        EISDIR O_TMPFILE  and  one of O_WRONLY or O_RDWR were specified
>>               in flags, but this kernel version does not  provide  the
>>               O_TMPFILE functionality.
> 
> I suspect that EISDIR only happens if the directory exists and is
> accessible (matching the flags).  

Good point.

> Otherwise EACCES and ENOENT sound
> plausible.

Testing on older kernels, with a directory that has no permissions 
available, and a nonexistent directory, it looks like only ENOENT
comes into play (i.e., the EISDIR check is made before the EACCES 
check). So I'll add the following:

       ENOENT pathname  refers  to  a nonexistent directory, O_TMPFILE
              and one of O_WRONLY or O_RDWR were specified  in  flags,
              but  this  kernel version does not provide the O_TMPFILE
              functionality.

Look okay?

> Sigh.  Why wasn't this implemented as a brand new syscall?

Hmmm? You think it's a problem that a user of O_TMPFILE has to check for
two different error codes to see if the flag is unsupported by the kernel?

</irony>

Yes, it's a mess. Presumably, things were done this way because
other open() flags--e.g., O_CLOEXEC, O_APPEND, O_SYNC)
could be meaningfully used with tmpfiles. But it would, I imagine,
have been possible to implement those flags in a separate syscall
with some suitable refactoring to handle the pieces common to open().
I can't help but wonder if this abuse of the interface will come
back to bite us some time.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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