Subject: Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK
To: riel@redhat.com, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, fweimer@redhat.com, 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>
From: Mike Kravetz <mike.kravetz@oracle.com>
Message-ID: <a0d79f77-f916-d3d6-1d61-a052581dbd4a@oracle.com>
Date: Mon, 7 Aug 2017 11:23:50 -0700
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: <20170806140425.20937-1-riel@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1124
Lines: 25

On 08/06/2017 07:04 AM, riel@redhat.com wrote:
> v2: fix MAP_SHARED case and kbuild warnings
> 
> Introduce MADV_WIPEONFORK semantics, which result in a VMA being
> empty in the child process after fork. This differs from MADV_DONTFORK
> in one important way.

It seems that the target use case might be private anonymous mappings.
If a shared or file backed mapping exists, one would assume that it
was created with the intention of sharing, even across fork.  So,
setting MADV_DONTFORK on such a mapping seems to change the meaning
and conflict with the original intention of the mapping.

If my thoughts above are correct, what about returning EINVAL if one
attempts to set MADV_DONTFORK on mappings set up for sharing?

If not, and you really want this to be applicable to all mappings, then
you should be more specific about what happens at fork time.  Do they
all get turned into anonymous mappings?  What happens to file references?
What about the really ugly case of hugetlb mappings?  Do they get
'transformed' to non-hugetlb mappings?  Or, do you create a separate
hugetlb mapping for the child?

-- 
Mike Kravetz