Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753355AbdHJWKB (ORCPT ); Thu, 10 Aug 2017 18:10:01 -0400 Received: from mail-yw0-f178.google.com ([209.85.161.178]:33690 "EHLO mail-yw0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752192AbdHJWJ6 (ORCPT ); Thu, 10 Aug 2017 18:09:58 -0400 MIME-Version: 1.0 In-Reply-To: <20170810170144.GA987@dhcp22.suse.cz> References: <20170806140425.20937-1-riel@redhat.com> <20170807132257.GH32434@dhcp22.suse.cz> <20170807134648.GI32434@dhcp22.suse.cz> <1502117991.6577.13.camel@redhat.com> <20170810130531.GS23863@dhcp22.suse.cz> <20170810153639.GB23863@dhcp22.suse.cz> <20170810170144.GA987@dhcp22.suse.cz> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Fri, 11 Aug 2017 00:09:57 +0200 Message-ID: Subject: Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK To: Michal Hocko Cc: Florian Weimer , Kees Cook , Mike Kravetz , Rik van Riel , Will Drewry , akpm@linux-foundation.org, dave.hansen@intel.com, kirill@shutemov.name, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, luto@amacapital.net, mingo@kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1221 Lines: 46 On Thu, Aug 10, 2017 at 7:01 PM, Michal Hocko wrote: > Does anybody actually do that using the minherit BSD interface? I can't find any OSS examples. I just thought of it in response to your question, but now that I have, I do want to use it that way in privsep code. As a mere user, fwiw it would make /my/ code less complex (in Kolmogorov terms) to be an madvise option. Here's what that would look like in user space: mmap() #if MAP_INHERIT_ZERO minherit() || pthread_atfork(workaround_fptr); #elif MADVISE_WIPEONFORK madvise() || pthread_atfork(workaround_fptr); #else pthread_atfork(workaround_fptr); #endif Vs: #if MAP_WIPEONFORK mmap( ... WIPEONFORK) || pthread_atfork(workaround_fptr); #else mmap() #endif #if MAP_INHERIT_ZERO madvise() || pthread_atfork(workaround_fptr); #endif #if !defined(MAP_WIPEONFORK) && !defined(MAP_INHERIT_ZERO) pthread_atfork(workaround_fptr); #endif The former is neater, and also a lot easier to stay structured if the code is separated across different functional units. Allocation is often handled in special functions. For me, madvise() is the principle of least surprise, following existing DONTDUMP semantics. -- Colm