Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752133AbdHHNPy (ORCPT ); Tue, 8 Aug 2017 09:15:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60424 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752070AbdHHNPw (ORCPT ); Tue, 8 Aug 2017 09:15:52 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9347D6148B Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=riel@redhat.com Message-ID: <1502198148.6577.18.camel@redhat.com> Subject: Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK From: Rik van Riel To: Florian Weimer , Mike Kravetz , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, colm@allcosts.net, akpm@linux-foundation.org, keescook@chromium.org, luto@amacapital.net, wad@chromium.org, mingo@kernel.org, kirill@shutemov.name, dave.hansen@intel.com Date: Tue, 08 Aug 2017 09:15:48 -0400 In-Reply-To: References: <20170806140425.20937-1-riel@redhat.com> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 08 Aug 2017 13:15:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1308 Lines: 33 On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: > On 08/07/2017 08:23 PM, Mike Kravetz wrote: > > If my thoughts above are correct, what about returning EINVAL if > > one > > attempts to set MADV_DONTFORK on mappings set up for sharing? > > That's my preference as well.  If there is a use case for shared or > non-anonymous mappings, then we can implement MADV_DONTFORK with the > semantics for this use case.  If we pick some arbitrary semantics > now, > without any use case, we might end up with something that's not > actually > useful. MADV_DONTFORK is existing semantics, and it is enforced on shared, non-anonymous mappings. It is frequently used for things like device mappings, which should not be inherited by a child process, because the device can only be used by one process at a time. When someone requests MADV_DONTFORK on a shared VMA, they will get it. The later madvise request overrides the mmap flags that were used earlier. The question is, should MADV_WIPEONFORK (introduced by this series) have not just different semantics, but also totally different behavior from MADV_DONTFORK? Does the principle of least surprise dictate that the last request determines the policy on an area, or should later requests not be able to override policy that was set at mmap time?