[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170925145238.gic2n37ffc6ytyvx@dhcp22.suse.cz>
Date: Mon, 25 Sep 2017 16:52:38 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Mike Kravetz <mike.kravetz@...cle.com>, mtk.manpages@...il.com,
linux-man@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Vlastimil Babka <vbabka@...e.cz>,
Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
linux-mm@...ck.org
Subject: Re: [patch] mremap.2: Add description of old_size == 0 functionality
On Mon 25-09-17 15:16:09, Florian Weimer wrote:
> On 09/25/2017 02:52 PM, Michal Hocko wrote:
> > So, how are you going to deal with the CoW and the implementation which
> > basically means that the newm mmap content is not the same as the
> > original one?
>
> I don't understand why CoW would kick in.
So you can guarantee nobody is going to write to that memory? Moreover
for the anonymous mapping you really get zero pages rather than the
original content AFAIR.
> The approach I outlined is
> desirable because it avoids the need to modify any executable pages, so this
> is not a concern. The point is to create a potentially unbounded number of
> thunks *without* run-time code generation.
>
> If the file is rewritten on disk, that's already undefined today, so it's
> not something we need to be concerned with. (Anything which replaces ELF
> files needs to use the rename-into-place approach anyway.)
Yeah that part is not all that interesting.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists