noexec on /dev/shm

[drago01]

On Tue, Dec 21, 2010 at 2:26 AM, Fernando Lopez-Lezcano
<nando at ccrma.stanford.edu> wrote:
> On 12/20/2010 02:17 PM, Adam Jackson wrote:
>> On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
>>
>>> I would like to bring to the attention of the list another current usage
>>> of the tmpfs mounted on /dev/shm in Fedora packages:
>>>
>>> Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the
>>> file api (apologies if my wording is not absolutely correct in unix
>>> terms) on the tmpfs filesystem that is mounted on /dev/shm for a very
>>> long time (10 years?). "/tmp" is not useful to Jack because Jack's
>>> internal communication pipes can't be stored in any disk based journaled
>>> filesystem as the latencies involved in accessing them cause glitches in
>>> the audio streams handled by Jack.
>>
>> This is right and wrong.
>
> Right! Thanks very much for looking at this in such detail (I presume
> you looked at the 1.9.6 code base?).
>
>> JACK uses /dev/shm for two purposes on Linux [1].  The first is as the
>> definition of what its configure script calls HOST_DEFAULT_TMP_DIR.
>> This path is only used as a name to which to attach the jack sockets.
>> The extent to which this will _ever_ touch the disk, even on a journaled
>> filesystem, is:
>>
>> - eventually, the inode for that socket and the dnode for the containing
>> directory will have to be written to the disk, once.
>  >
>> - under memory pressure the vfs may decide to throw away the inode cache
>> for that socket, which would then have to be re-read from disk for
>> subsequent connecting JACK clients.
>>
>> In other words, these are setup costs, not maintenance costs.  This may
>> cause glitches in a realtime scenario to the extent that clients are
>> created and destroyed, but in general I submit that the cost of exec()
>> of those new clients is going to dwarf the cost of the inode cache miss
>> for the JACK socket. [2]
>
> My experience (caveat: a long time ago, maybe everything has changed
> internally in both jack and the kernel and that has invalidated my
> experience cache :-) was that using /tmp would lead to constant - not
> all the time, but very frequent and not correlated with client
> connection/disconnection - xruns (glitches in the audio), using /dev/shm
> would fix that immediately. That was why things were moved over to
> /dev/shm if I remember correctly.

Well /tmp should be mounted tmpfs anyway (I have been doing this for
years and it is working just fine).
tmp isn't a persistent storage so it makes a lot of sense, and it is
*not* a dumping ground for giant files (apps that try to do that are
just broken).