Skip to contentSkip to conversation

document that O_TMPFILE works with shm_open

PATCH In review Daniel Colascione 3 participants 6 messages Oct 24, 2015 – Dec 4, 2015 4 messages not in the archive Man-pages: manual pages for Linux -- Sections 2, 3, 4, 5, and 7

lore
Share & tools
lore

Daniel Colascione

author
#0 lore raw

PATCH 1/1 document that O_TMPFILE works with shm_open

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;
}
man3/shm_open.3 +19 -0
index 6b04f39..7b9b7c3 100644
@@ -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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw

* Daniel Colascione:

Quoted 5 lines

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

Quoted 7 lines
{
    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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#4 lore raw
Quoted 12 lines · Florian Weimer

* Daniel Colascione:

Quoted 10 lines

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);
Quoted 5 lines
Quoted 2 lines
    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.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw

* Daniel Colascione:

Quoted 13 lines · Florian Weimer
Quoted 12 lines

* Daniel Colascione:

Quoted 10 lines

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);
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
    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.

Quoted 2 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#8 lore raw
Quoted 18 lines · Florian Weimer

* Daniel Colascione:

Quoted 16 lines · Florian Weimer
Quoted 15 lines

* Daniel Colascione:

Quoted 12 lines

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;
}
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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.

Quoted 5 lines
Quoted 2 lines

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.

#9 lore raw
In reply to a message not in the archive

Hello Daniel (and Al),

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

Quoted 41 lines · 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;
}
man3/shm_open.3 +19 -0
index 6b04f39..7b9b7c3 100644
@@ -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

man3/shm_open.3

Quoted 10 lines
man3/shm_open.3 +7 -0
+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

Signature · 7 lines
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html