From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752190AbdHHPWz (ORCPT ); Tue, 8 Aug 2017 11:22:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53936 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752010AbdHHPWy (ORCPT ); Tue, 8 Aug 2017 11:22:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 238E14E4CA Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com Subject: Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK To: Mike Kravetz , Rik van Riel , 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 References: <20170806140425.20937-1-riel@redhat.com> <1502198148.6577.18.camel@redhat.com> <0324df31-717d-32c1-95ef-351c5b23105f@oracle.com> From: Florian Weimer Message-ID: Date: Tue, 8 Aug 2017 17:22:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0324df31-717d-32c1-95ef-351c5b23105f@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 08 Aug 2017 15:22:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/08/2017 05:19 PM, Mike Kravetz wrote: > On 08/08/2017 06:15 AM, Rik van Riel wrote: >> 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? > > Sorry for the confusion. I accidentally used MADV_DONTFORK instead > of MADV_WIPEONFORK in my reply (which Florian commented on). Yes, I made the same mistake. I meant MADV_WIPEONFORK as well. Florian