[PATCH 0/2] Fix tmpfile creation for MIT-SHM files

[Mark Kettenis]

> From: Keith Packard <keithp at keithp.com>
> Date: Tue, 19 Nov 2013 22:35:13 -0800
> 
> Keith Packard <keithp at keithp.com> writes:
> 
> > The new MIT-SHM CreateSegment request needs to stick the requested
> > shared memory file someplace in the file system. Precisely where it
> > needs to live depends on the target system.
> >
> >  [PATCH 1/2] Select directory for MIT-SHM temp files at configure time
> 
> > The first of these patches allows that to be configured in the X
> > server build process. By default, it looks through a list of likely
> > spots, picking the first that it finds. Of course, you can also
> > specify the directory on the configure command line using
> > --with-shared-memory-dir=3DPATH
> 
> I haven't seen anyone from non-Debian land chime in about this patch --
> it's designed to auto-detect a suitable directory for SHM temp files
> that the X server creates. I'd love a 'Reviewed-by:', or even a
> 'Tested-by:' as I want to merge this fix in time for another RC this
> Friday.

I still think the X server should not be concerned with picking a
suitable directory, but instead should use shm_open/shm_unlink...

> >  [PATCH 2/2] Xext: Use SHMDIR and O_TMPFILE when creating mapping
> >
> > The second patch actually uses that directory in the MIT-SHM
> > extension, at the same time it also adds support for the new Linux
> > O_TMPFILE flag, which avoids ever needing a name for the file nicely.
> >
> > To test the patch, I needed to stick this in the file above the call
> > as my glibc doesn't yet have the necessary O_TMPFILE define.
> >
> > /* Hacks needed until glibc has O_TMPFILE */
> > #define __O_TMPFILE    020000000
> > #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
> 
> I'd also like to hear from anyone who can test this patch; it's a useful
> change in that it avoids all of the pitfalls of mkstemp as used by the
> existing code. Something even as simple as 'this should wait until after
> 1.15 as it's not a serious bug fix' would be great.

...but some thought is required on how to use O_TMPFILE with shm_open.