[patch] document that O_TMPFILE works with shm_open

[patch] document that O_TMPFILE works with shm_open

[Daniel Colascione]

This test program works fine. (Watch it work in strace.) This patch is
against git master. It's okay to document accidental features, right?

int
main()
{
    int shmfd = shm_open(".", O_TMPFILE | O_RDWR | O_EXCL, 0600);
    ftruncate(shmfd, 1000);
    mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);

    return 0;
}


diff --git a/man3/shm_open.3 b/man3/shm_open.3
index 6b04f39..7b9b7c3 100644
--- a/man3/shm_open.3
+++ b/man3/shm_open.3
@@ -116,6 +116,32 @@ object can be set using
 The newly allocated bytes of a shared memory
 object are automatically initialized to 0.
 .TP
+.BR O_TMPFILE " (since Linux 3.11)"
+.BR shm_open ()
+can be used to create an anonymous shared memory region by using exactly
+the string "." as
+.I name
+and including both
+.B O_TMPFILE
+and
+.B O_EXCL
+in
+.I oflag
+while omitting
+.B O_CREAT
+.
+Shared memory regions created this way work just like ones created without
+.B O_TMPFILE
+and with
+.B O_CREAT
+except that they are automatically released and their contents
discarded when the
+last reference to the
+region disappears.  References are either
+.BR mmap (2)
+mappings or file descriptors.
+See also
+.BR memfd_create (2).
+.TP
 .B O_EXCL
 If
 .B O_CREAT
--
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] document that O_TMPFILE works with shm_open

[Florian Weimer]

* Daniel Colascione:

> This test program works fine. (Watch it work in strace.) This patch is
> against git master. It's okay to document accidental features, right?
>
> int
> main()
> {
>     int shmfd = shm_open(".", O_TMPFILE | O_RDWR | O_EXCL, 0600);
>     ftruncate(shmfd, 1000);
>     mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
>
>     return 0;
> }

This looks more like a bug to me.  I wouldn't count on it continuing
to work.  glibc already tightened the rules for the name once.

Florian
--
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] document that O_TMPFILE works with shm_open

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On 10/27/2015 03:12 PM, Florian Weimer wrote:
> * Daniel Colascione:
>
>> This test program works fine. (Watch it work in strace.) This patch is
>> against git master. It's okay to document accidental features, right?
>>
>> int
>> main()
>> {
>>     int shmfd = shm_open(".", O_TMPFILE | O_RDWR | O_EXCL, 0600);
>>     ftruncate(shmfd, 1000);
>>     mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
>>
>>     return 0;
>> }
>
> This looks more like a bug to me.  I wouldn't count on it continuing
> to work.  glibc already tightened the rules for the name once.

I don't think they can break compatibility like that, and besides: it's
a useful feature, not a bug. Is it better for people to blindly open
files in /dev/shm? Because that's what they do today.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [patch] document that O_TMPFILE works with shm_open

[Florian Weimer]

* Daniel Colascione:

> On 10/27/2015 03:12 PM, Florian Weimer wrote:
>> * Daniel Colascione:
>>
>>> This test program works fine. (Watch it work in strace.) This patch is
>>> against git master. It's okay to document accidental features, right?
>>>
>>> int
>>> main()
>>> {
>>>     int shmfd = shm_open(".", O_TMPFILE | O_RDWR | O_EXCL, 0600);
>>>     ftruncate(shmfd, 1000);
>>>     mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
>>>
>>>     return 0;
>>> }
>>
>> This looks more like a bug to me.  I wouldn't count on it continuing
>> to work.  glibc already tightened the rules for the name once.
>
> I don't think they can break compatibility like that, and besides: it's
> a useful feature, not a bug.

Names not starting with '/' do not have well-defined behavior with
shm_open.  Applications shouldn't rely on that.

> Is it better for people to blindly open files in /dev/shm? Because
> that's what they do today.

memfd_create is the official interface for this purpose.  But neither
O_TMPFILE or memfd_create is very widely supported.

Florian
--
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] document that O_TMPFILE works with shm_open

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On 10/27/2015 03:19 PM, Florian Weimer wrote:
> * Daniel Colascione:
> 
>> On 10/27/2015 03:12 PM, Florian Weimer wrote:
>>> * Daniel Colascione:
>>>
>>>> This test program works fine. (Watch it work in strace.) This patch is
>>>> against git master. It's okay to document accidental features, right?
>>>>
>>>> int
>>>> main()
>>>> {
>>>>     int shmfd = shm_open(".", O_TMPFILE | O_RDWR | O_EXCL, 0600);
>>>>     ftruncate(shmfd, 1000);
>>>>     mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
>>>>
>>>>     return 0;
>>>> }
>>>
>>> This looks more like a bug to me.  I wouldn't count on it continuing
>>> to work.  glibc already tightened the rules for the name once.
>>
>> I don't think they can break compatibility like that, and besides: it's
>> a useful feature, not a bug.
> 
> Names not starting with '/' do not have well-defined behavior with
> shm_open.  Applications shouldn't rely on that.

We document non-portable extensions all the time. Why not this one? In
any case, the glibc info page documents that its implementation of
shm_open accepts whatever open(2) does, and the Linux man page for
open(2) indicates that O_TMPFILE works with the shmem filesystem.

>> Is it better for people to blindly open files in /dev/shm? Because
>> that's what they do today.
> 
> memfd_create is the official interface for this purpose.  But neither
> O_TMPFILE or memfd_create is very widely supported.

O_TMPFILE appeared in 3.11; memfd_create appeared in 3.17.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [patch] document that O_TMPFILE works with shm_open

[Michael Kerrisk (man-pages)]

Hello Daniel (and Al),

Al: perhaps you could comment please, as the creator of O_TMPFILE.

On 24 October 2015 at 09:01, Daniel Colascione <dancol-CpwT7fMy01Ydnm+yROfE0A@public.gmane.org> wrote:
> This test program works fine. (Watch it work in strace.) This patch is
> against git master. It's okay to document accidental features, right?
>
> int
> main()
> {
>     int shmfd = shm_open(".", O_TMPFILE | O_RDWR | O_EXCL, 0600);
>     ftruncate(shmfd, 1000);
>     mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
>
>     return 0;
> }
>
> diff --git a/man3/shm_open.3 b/man3/shm_open.3
> index 6b04f39..7b9b7c3 100644
> --- a/man3/shm_open.3
> +++ b/man3/shm_open.3
> @@ -116,6 +116,32 @@ object can be set using
>  The newly allocated bytes of a shared memory
>  object are automatically initialized to 0.
>  .TP
> +.BR O_TMPFILE " (since Linux 3.11)"
> +.BR shm_open ()
> +can be used to create an anonymous shared memory region by using exactly
> +the string "." as
> +.I name
> +and including both
> +.B O_TMPFILE
> +and
> +.B O_EXCL
> +in
> +.I oflag
> +while omitting
> +.B O_CREAT
> +.
> +Shared memory regions created this way work just like ones created without
> +.B O_TMPFILE
> +and with
> +.B O_CREAT
> +except that they are automatically released and their contents
> discarded when the
> +last reference to the
> +region disappears.  References are either
> +.BR mmap (2)
> +mappings or file descriptors.
> +See also
> +.BR memfd_create (2).
> +.TP
>  .B O_EXCL
>  If
>  .B O_CREAT

So, like Florian, I was a little surprised by this "feature". I'm not
sure whether it should be documented, or perhaps whether it should be
documented as "don't do this".

Al, could you comment? Is this expected behavior/was this planned behavior?

Thanks,

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