Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935645AbdIYNQY (ORCPT ); Mon, 25 Sep 2017 09:16:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44928 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933559AbdIYNQS (ORCPT ); Mon, 25 Sep 2017 09:16:18 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5D008356F4 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com Subject: Re: [patch] mremap.2: Add description of old_size == 0 functionality To: Michal Hocko Cc: Mike Kravetz , mtk.manpages@gmail.com, linux-man@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Andrea Arcangeli , "Kirill A . Shutemov" , Vlastimil Babka , Anshuman Khandual , linux-mm@kvack.org References: <20170915213745.6821-1-mike.kravetz@oracle.com> <20170925123508.pzjbe7wgwagnr5li@dhcp22.suse.cz> <20170925125207.4tu24sbpnihljknu@dhcp22.suse.cz> From: Florian Weimer Message-ID: <765cd0cb-aa35-187c-456d-05d8752caa04@redhat.com> Date: Mon, 25 Sep 2017 15:16:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170925125207.4tu24sbpnihljknu@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed 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.30]); Mon, 25 Sep 2017 13:16:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 699 Lines: 16 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. 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.) Thanks, Florian