[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /run vs /var/run

Hash: SHA1

md@Linux.IT (Marco d'Itri) writes:

> On Dec 19, Henrique de Moraes Holschuh <hmh@debian.org> wrote:
>> > > 1. It exists only on Linux-based OS's
>> > > 2. There is no gaurentee that it will continue to be there at all
>> > > 3. There is no guareteee that it will remain a filesystem in the future 
>> > > even if it is there.
>> > > 4. There is no gaurentee that it exists at all.
>> > These points apply to the proposed tmpfs-based /run as well.
>> /run would have no other special function, so it is much more future-proof
>> than using /dev/shm for stuff it was not created for.
> You keep saying this, but fail to provide any arguments except
> handwaving.

I provided you with a functional program code sample that demonstrates
how shm_open interacts with the filesystem.  Did you try it?  [link
with -lrt, BTW]

With this example, it's trivial to trigger namespace conflicts and
break shm_open().  "mkdir /dev/shm/foobar", for example, or create a
symbolic link.  These fail outright.  If a regular file was opened, it
would be ftruncated, zeroed and corrupted beyond repair.  Depending on
who alters it last, this will

1) Cause POSIX-SHM using applications to fail with SIGBUS as the
   backing store is removed.
2) Cause POSIX-SHM using applications to segfault or misbehave as
   their data gets changed behind their back.
3) Cause the program abusing /dev/shm to fail as its datafiles are
   trashed and/or unlinked behind their back.

Namespace conflicts aren't pretty.  Sure, you can call it
"handwaving", but to me it's something that's going to break at some
point in the future.  I can't believe you are condoning that,
especially when the fix is so simple.


- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>


Reply to: