From owner-freebsd-arch@freebsd.org Tue Sep 8 19:13:16 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56E509CC89F for ; Tue, 8 Sep 2015 19:13:16 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 370B6143C for ; Tue, 8 Sep 2015 19:13:16 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3608C9CC89E; Tue, 8 Sep 2015 19:13:16 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35A2C9CC89C for ; Tue, 8 Sep 2015 19:13:16 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4A18143A for ; Tue, 8 Sep 2015 19:13:15 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wicgb1 with SMTP id gb1so90101856wic.1 for ; Tue, 08 Sep 2015 12:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition:user-agent; bh=VxbmxBzSSmH5LPJwID8vQlcbkb1W6PPbyJSxhXjv4pc=; b=XaEaqUTqQOIXBjJUE9atzSB+6F9RhglJHjSRsU0LqRmqp3SKSdOSnjyiEi4/2hEK1O 8q4yobqm1VRm2tCrGeyvck7jLgaoc4rjV9tY+BEl5ZKA+m5bkC7lTGN2Ywc+BUH0zwYi TaupuXaM2FEteUNwmimAJPCaLv/T9p7WT7ST79A5hDNKddoBkbNch55FNCr3MGtYLC+9 RsARAXqaMZHjhPid/esZaSNactvKF7+eV4R51I4GOgGD42W6DwFkTU0J8uVn5aCMX0Lq GY1cK+1fjsyH3lpXL1m69r1NeIRHRzx+R5u5u9XuSBhqxltxOJpNsL4wA56plhhbDQty yfwg== X-Received: by 10.180.37.201 with SMTP id a9mr48639591wik.83.1441739594356; Tue, 08 Sep 2015 12:13:14 -0700 (PDT) Received: from brick.home (adit71.neoplus.adsl.tpnet.pl. [79.184.201.71]) by smtp.gmail.com with ESMTPSA id c11sm7289519wib.1.2015.09.08.12.13.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Sep 2015 12:13:13 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 8 Sep 2015 21:13:10 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: arch@FreeBSD.org Subject: Make kern.ipc.shm_allow_removed default to 1. Message-ID: <20150908191310.GA3104@brick.home> Mail-Followup-To: arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 19:13:16 -0000 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. 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. Arguments - on both sides - welcome. Thanks!