From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752962AbdHKOG6 (ORCPT ); Fri, 11 Aug 2017 10:06:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:60867 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752631AbdHKOG4 (ORCPT ); Fri, 11 Aug 2017 10:06:56 -0400 Date: Fri, 11 Aug 2017 16:06:53 +0200 From: Michal Hocko To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= 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 Subject: Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK Message-ID: <20170811140653.GO30811@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 11-08-17 00:09:57, Colm MacCárthaigh wrote: > 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. OK, I guess I see your point. Thanks for the clarification. > For me, madvise() is the principle of least surprise, following > existing DONTDUMP semantics. I am sorry to look too insisting here (I have still hard time to reconcile myself with the madvise (ab)use) but if we in fact want minherit like interface why don't we simply add minherit and make the code which wants to use that interface easier to port? Is the only reason that hooking into madvise is less code? If yes is that a sufficient reason to justify the (ab)use of madvise? If there is a general consensus on that part I will shut up and won't object anymore. Arguably MADV_DONTFORK would fit into minherit API better as well. MADV_DONTDUMP is a differnet storry of course. -- Michal Hocko SUSE Labs