Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Oct 2015 09:29:47 +0000 (UTC)
From:      Edward Tomasz Napierala <trasz@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r289112 - in head: lib/libc/sys sys/kern
Message-ID:  <201510100929.t9A9TlEv030244@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: trasz
Date: Sat Oct 10 09:29:47 2015
New Revision: 289112
URL: https://svnweb.freebsd.org/changeset/base/289112

Log:
  Change the default setting of kern.ipc.shm_allow_removed from 0 to 1.
  
  This removes the need for 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.
  
  This is the behaviour exhibited by Linux since... probably always, and
  also by OpenBSD since the following commit:
  
  revision 1.54
  date: 2011/10/27 07:56:28; author: robert; state: Exp; lines: +3 -8;
  Allow segments to be used even after they were marked for deletion with
  the IPC_RMID flag.
  This is permitted as an extension beyond the standards and this is similar
  to what other operating systems like linux do.
  
  MFC after:	1 month
  Relnotes:	yes
  Sponsored by:	The FreeBSD Foundation
  Differential Revision:	https://reviews.freebsd.org/D3603

Modified:
  head/lib/libc/sys/shmctl.2
  head/sys/kern/sysv_shm.c

Modified: head/lib/libc/sys/shmctl.2
==============================================================================
--- head/lib/libc/sys/shmctl.2	Sat Oct 10 09:21:55 2015	(r289111)
+++ head/lib/libc/sys/shmctl.2	Sat Oct 10 09:29:47 2015	(r289112)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd July 17, 1995
+.Dd October 10, 2015
 .Dt SHMCTL 2
 .Os
 .Sh NAME
@@ -72,15 +72,18 @@ or it must have superuser privileges.
 .It Dv IPC_RMID
 Removes the segment from the system.
 The removal will not take
-effect until all processes having attached the segment have exited;
-however, once the IPC_RMID operation has taken place, no further
-processes will be allowed to attach the segment.
+effect until all processes having attached the segment have exited.
 For the operation
 to succeed, the calling process's effective uid must match
 .Fa shm_perm.uid
 or
 .Fa shm_perm.cuid ,
 or the process must have superuser privileges.
+If the
+.Va kern.ipc.shm_allow_removed
+.Xr sysctl 3
+variable is set to 0, once the IPC_RMID operation has taken place,
+no further processes will be allowed to attach the segment.
 .\" .It Dv SHM_LOCK
 .\" Locks the segment in memory.  The calling process must have
 .\" superuser privileges. Not implemented in FreeBSD.

Modified: head/sys/kern/sysv_shm.c
==============================================================================
--- head/sys/kern/sysv_shm.c	Sat Oct 10 09:21:55 2015	(r289111)
+++ head/sys/kern/sysv_shm.c	Sat Oct 10 09:29:47 2015	(r289112)
@@ -162,7 +162,7 @@ struct	shminfo shminfo = {
 };
 
 static int shm_use_phys;
-static int shm_allow_removed;
+static int shm_allow_removed = 1;
 
 SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmmax, CTLFLAG_RWTUN, &shminfo.shmmax, 0,
     "Maximum shared memory segment size");



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201510100929.t9A9TlEv030244>