Received: by 10.192.165.156 with SMTP id m28csp2305200imm; Thu, 12 Apr 2018 12:00:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx48Mn2qny1LDYNrtJJr547+fUj6NaTxQB/LAVdizXVf74gim/wLMQDEyd8+Eq7RgncEmemds X-Received: by 2002:a17:902:64d7:: with SMTP id y23-v6mr2242548pli.349.1523559649834; Thu, 12 Apr 2018 12:00:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523559649; cv=none; d=google.com; s=arc-20160816; b=slFqWY98A+ThGth/ZMzbi/8HeeK6C1uV9fvPn1qXw26AUwaV4pS5Phz3atzTyV4AR0 y7WSZ7Xz713alyQTO7X4w3MoEEeeiD7gTbImURVxHriFHKloUye/9I6RrLhbKz9VadkL RrizN6c3ckJndXyTfCiRzKdtAvFq0dpEXGEHFs+Vn73VKiTnHmPf5sfxsEC/8SWJIYvR s0auLI8R1Nwu+Eo7+ff+XMPkbuB3nVDouHRI+71BaDscvbum+LTS+Kg8tBhTk6LB2C8g L4mVBSYPC3NCp3Uf1OnwTvYaKaCcVSTOw0L99NDOYXUlT8LdKcqILCR0zQNLi0enj+l+ 4Cgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=V9MdO1vi/quM6Owg8gpCXotag1voSQ0LfpafXHQvu1A=; b=D4bHFRHjYywRXJRS++dWVmSnNhbm03tM8cI4PjpiCsP7bRrdQQ5zHeLqq+alQbNAN9 AAPqTFV8WBWrkh0QK7OePRDnWz8MREPOZC5OxkgNyIJMIEeuEgiB9oJv7vLjMIEBbKsX ADum1gYMlFJTOIYT0+lYfgl2x74VRkLn7D61JdEEPfykVKsscFeQetn81DM4QRYWZEZU KN1daztM94/sIXjU2dQWf+fcLp8WjCwQOwQvWzQcp2wt8/sjPeTeo2AY4EX/sgtRZdfX uqP+Mg9jHY7oSTuU4XYhLo1R+OoYlEU/2Hi2gzGPHospyMq8u3z8BdK9Z7uWE0GuKH4b qeBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v7si2620263pgr.443.2018.04.12.12.00.34; Thu, 12 Apr 2018 12:00:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753359AbeDLS71 (ORCPT + 99 others); Thu, 12 Apr 2018 14:59:27 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:6542 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752775AbeDLS7Z (ORCPT ); Thu, 12 Apr 2018 14:59:25 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com id ; Thu, 12 Apr 2018 11:59:37 -0700 Received: from HQMAIL107.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Thu, 12 Apr 2018 11:59:14 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Thu, 12 Apr 2018 11:59:14 -0700 Received: from [10.110.48.28] (10.110.48.28) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Apr 2018 18:59:24 +0000 Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved To: Jann Horn , Michael Kerrisk-manpages CC: linux-man , Michal Hocko , Andrew Morton , Linux-MM , lkml , Linux API References: <20180412153941.170849-1-jannh@google.com>

X-Nvconfidentiality: public From: John Hubbard Message-ID: <13801e2a-c44d-e940-f872-890a0612a483@nvidia.com> Date: Thu, 12 Apr 2018 11:59:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.110.48.28] X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/12/2018 11:49 AM, Jann Horn wrote: > On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages) > wrote: >> Hi John, >> >> On 12 April 2018 at 20:33, John Hubbard wrote: >>> On 04/12/2018 08:39 AM, Jann Horn wrote: >>>> Clarify that MAP_FIXED is appropriate if the specified address range has >>>> been reserved using an existing mapping, but shouldn't be used otherwise. >>>> >>>> Signed-off-by: Jann Horn >>>> --- >>>> man2/mmap.2 | 19 +++++++++++-------- >>>> 1 file changed, 11 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/man2/mmap.2 b/man2/mmap.2 > [...] >>>> .IP >>>> For example, suppose that thread A looks through >>>> @@ -284,13 +285,15 @@ and the PAM libraries >>>> .UR http://www.linux-pam.org >>>> .UE . >>>> .IP >>>> -Newer kernels >>>> -(Linux 4.17 and later) have a >>>> +For cases in which the specified memory region has not been reserved using an >>>> +existing mapping, newer kernels (Linux 4.17 and later) provide an option >>>> .B MAP_FIXED_NOREPLACE >>>> -option that avoids the corruption problem; if available, >>>> -.B MAP_FIXED_NOREPLACE >>>> -should be preferred over >>>> -.BR MAP_FIXED . >>>> +that should be used instead; older kernels require the caller to use >>>> +.I addr >>>> +as a hint (without >>>> +.BR MAP_FIXED ) >>> >>> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED >>> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and >>> possibly omit non-MAP_FIXED discussion, it will help. >> >> Hmmm -- true. That piece could be a little clearer. > > How about something like this? > > For cases in which MAP_FIXED can not be used because > the specified memory > region has not been reserved using an existing mapping, > newer kernels > (Linux 4.17 and later) provide an option > MAP_FIXED_NOREPLACE that > should be used instead. Older kernels require the > caller to use addr as a hint and take appropriate action if > the kernel places the new mapping at a different address. > > John, Michael, what do you think? I'm still having difficulty with it, because this is in the MAP_FIXED section, but I think you're documenting the behavior that you get if you do *not* specify MAP_FIXED, right? Also, the hint behavior is true of both older and new kernels... So, if that's your intent (you want to sort of document by contrast to what would happen if this option were not used), then how about something like this: Without the MAP_FIXED option, the kernel would treat addr as a hint, rather than a requirement, and the caller would need to take appropriate action if the kernel placed the mapping at a different address. (For example, munmap and try again.) thanks, -- John Hubbard NVIDIA