Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752333AbdGGRpj (ORCPT ); Fri, 7 Jul 2017 13:45:39 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:36287 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752153AbdGGRph (ORCPT ); Fri, 7 Jul 2017 13:45:37 -0400 Date: Fri, 7 Jul 2017 20:45:34 +0300 From: "Kirill A. Shutemov" To: Mike Kravetz Cc: linux-mm@kvack.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Andrea Arcangeli , Michal Hocko , Aaron Lu , "Kirill A . Shutemov" Subject: Re: [RFC PATCH 1/1] mm/mremap: add MREMAP_MIRROR flag for existing mirroring functionality Message-ID: <20170707174534.wdfbciyfpovi52dy@node.shutemov.name> References: <1499357846-7481-1-git-send-email-mike.kravetz@oracle.com> <1499357846-7481-2-git-send-email-mike.kravetz@oracle.com> <20170707102324.kfihkf72sjcrtn5b@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2085 Lines: 45 On Fri, Jul 07, 2017 at 10:29:52AM -0700, Mike Kravetz wrote: > On 07/07/2017 03:23 AM, Kirill A. Shutemov wrote: > > On Thu, Jul 06, 2017 at 09:17:26AM -0700, Mike Kravetz wrote: > >> The mremap system call has the ability to 'mirror' parts of an existing > >> mapping. To do so, it creates a new mapping that maps the same pages as > >> the original mapping, just at a different virtual address. This > >> functionality has existed since at least the 2.6 kernel. > >> > >> This patch simply adds a new flag to mremap which will make this > >> functionality part of the API. It maintains backward compatibility with > >> the existing way of requesting mirroring (old_size == 0). > >> > >> If this new MREMAP_MIRROR flag is specified, then new_size must equal > >> old_size. In addition, the MREMAP_MAYMOVE flag must be specified. > > > > The patch breaks important invariant that anon page can be mapped into a > > process only once. > > Actually, the patch does not add any new functionality. It only provides > a new interface to existing functionality. > > Is it not possible to have an anon page mapped twice into the same process > via system V shared memory? shmget(anon), shmat(), shmat. > Of course, those are shared rather than private anon pages. By anon pages I mean, private anon or file pages. These are subject to CoW. > > What is going to happen to mirrored after CoW for instance? > > > > In my opinion, it shouldn't be allowed for anon/private mappings at least. > > And with this limitation, I don't see much sense in the new interface -- > > just create mirror by mmap()ing the file again. > > The code today works for anon shared mappings. See simple program below. > > You are correct in that it makes little or no sense for private mappings. > When looking closer at existing code, mremap() creates a new private > mapping in this case. This is most likely a bug. IIRC, existing code doesn't create mirrors of private pages as it requires old_len to be zero. There's no way to get private pages mapped twice this way. -- Kirill A. Shutemov