Received: by 10.192.165.156 with SMTP id m28csp2353096imm; Thu, 12 Apr 2018 12:52:11 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+20LlGvyVzTmzaimQMujZGBN0lnN13K57Jerrocx1gWqWfD1jeNWIpUdGGipm0horvnyTM X-Received: by 10.98.201.15 with SMTP id k15mr8810205pfg.184.1523562731112; Thu, 12 Apr 2018 12:52:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523562731; cv=none; d=google.com; s=arc-20160816; b=RX5fxJp2WGmS7C2w5+gPTz2hVa2v2BXEu7lMM5+t43Jy/4TDbkWJUsT9+nG7EnTGJJ BtCuErgbOh6a0NRESwsXgifWZknkahBA7hiqq/OTs9lQJtUH+YZTwGmUkgr9mSw2ZGvB ehIsZJW7031XM9gC8fFDCK8ZBUm8R3+nySRqYtBLd97lvGyaPHfx/dhfnPQEW/AYX9af DkOy61U0W3nRqs8DSzAJ5qc14AqzVTg7SsVHgxSdUr+6CMg0PnynNWWzhzJ10/xmUJ69 e1fhBa7Sga6SqrHr7iVicWsVcPpZZYmZ0bDtNYMZDNpV0fToMnz2sfzYo1phM6HsVGiG 4WRA== 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=t+Dr31AIhPs5Pt8uEc2talrrVen/AKhy1yJIaSucJSE=; b=DwnXJ9fFPga/TLvX7CYUNpYnvmjDg/bA/qzR5S53SFApZwJiTxHtH/RM8+NXQnXz2c TSFxMrgQ6ONu2JnCjWCOALTUsVxc5WXQfSH2mbXzHVq9meWFw+K5me9Qi4sMm0aAC/wZ UWHJnWvkFue8Zy6zj7ALvVVYn6dvK9YZm9AXEu3HyMxt9/UT6byP7aTCkJHQV7dFUgKD 8pyvk8znnW802Kb2KYOaOQxitVhH83zD/a0QSellX2kHbAtvUl4CnyQuJWMFj6vyDqZg 88a+02Ip2JaYsn2kX6RpKuf7QhwAqWcYfdid4sPn15R5f+BLWS7bgsQCtPiqq8uxkbvE OnSA== 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 s12si2701595pgs.164.2018.04.12.12.51.55; Thu, 12 Apr 2018 12:52:11 -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 S1753318AbeDLTYk (ORCPT + 99 others); Thu, 12 Apr 2018 15:24:40 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:7677 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753279AbeDLTYh (ORCPT ); Thu, 12 Apr 2018 15:24:37 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com id ; Thu, 12 Apr 2018 12:24:49 -0700 Received: from HQMAIL107.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Thu, 12 Apr 2018 12:24:27 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Thu, 12 Apr 2018 12:24:27 -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 19:24:36 +0000 Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved To: Jann Horn CC: Michael Kerrisk-manpages , linux-man , Michal Hocko , Andrew Morton , Linux-MM , lkml , Linux API References: <20180412153941.170849-1-jannh@google.com>

<13801e2a-c44d-e940-f872-890a0612a483@nvidia.com> X-Nvconfidentiality: public From: John Hubbard Message-ID: Date: Thu, 12 Apr 2018 12:24:36 -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 12:18 PM, Jann Horn wrote: > On Thu, Apr 12, 2018 at 8:59 PM, John Hubbard wrote: >> 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... > > The manpage patch you and mhocko wrote mentioned MAP_FIXED_NOREPLACE > in the MAP_FIXED section - I was trying to avoid undoing a change you > had just explicitly made. heh. So I've succeeding in getting my own wording removed, then? Progress! :) > >> 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.) > > I'd be fine with removing the paragraph. As you rightly pointed out, > it doesn't really describe MAP_FIXED. > OK, that's probably the simplest fix. thanks, -- John Hubbard NVIDIA