Re: [patch] document that O_TMPFILE works with shm_open

[Daniel Colascione <dancol-CpwT7fMy01Ydnm+yROfE0A@public.gmane.org>]

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