Make kern.ipc.shm_allow_removed default to 1.

[John Baldwin]

On Tuesday, September 08, 2015 09:13:10 PM Edward Tomasz Napierała wrote:
> I'd like to commit - well, discuss it first - the following change:
> 
> https://reviews.freebsd.org/D3603
> 
> This changes the default setting of kern.ipc.shm_allow_removed from 0 to 1.
> This removes the need of manually changing this flag for Google Chrome
> users. It also improves compatibility with Linux applications running under
> Linuxulator compatibility layer, and possibly also helps in porting software
> from Linux.
> 
> Generally speaking, the flag allows applications to create the shared memory
> segment, attach it, remove it, and then continue to use it and to reattach it
> later. This means that the kernel will automatically "clean up" after the
> application exits.
> 
> It could be argued that it's against POSIX. However, SUSv3 says this
> about IPC_RMID: "Remove the shared memory identifier specified by shmid from
> the system and destroy the shared memory segment and shmid_ds data structure
> associated with it." From my reading, we break it in any case by deferring
> removal of the segment until it's detached; we won't break it any more
> by also deferring removal of the identifier.

It is against POSIX.  When I last raised this with kib@ and alc@, Alan noted
that our current behavior is not really against POSIX as he felt there was
enough wriggle room to permit existing mappings to remain valid.

That said, in the thread kib@ felt it was ok to change the default.  I think
it's probably fine.  It's a hack for the fact that shmget() isn't returning
a real fd the way shm_open() does, so in that sense it is ok.  That is,
in shm_open() you can do this:

	fd = shm_open("/some/path");
	shm_unlink("/some/path");
	
	mmap(..., fd);

	/* later */

	mmap(..., fd);

	/* or pass fd over a UNIX domain socket and map it in another process */

	close(fd);

	/* now mmap won't work */

With FreeBSD's SHM_ANON you can collapse the first two steps down to:

	fd = shm_open(SHM_ANON);

If you think of the return value from shmget() as an fd, then setting this to 1
does make sense in a way.  That is you can have a sequence of:

	id = shmget(...);

	hold = shmat(id, ...);  /* "hold" mapping */

	shmctl(IPC_RMID, id);

	/* later */

	shmat(id, ...);

	/* or pass 'id' as a value across a socket and shmat in another process */

    shmdt(hold);

    /* now shmat may or may not work */

However, note that this does require you to do some things carefully:

  1) You have to keep an existing mapping around via shmat() that serves as
     the equivalent of the open file descriptor to keep the 'id' valid.
     This also means you have to defer the IPC_RMID until after you have
     created this "hold" mapping.

  2) You always have to invoke IPC_RMID.  In particular, even if you use
     shmget() with IPC_PRIVATE you have to explicitly IPC_RMID.

So, I think it is fine to change this (and have asked about doing it myself
in the past).  However, I think shm_open() is definitely a superior API for
this sort of thing with semantics that are clearer and more inline with UNIX.

-- 
John Baldwin