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;
From:   Steve MacLean <Steve.MacLean@microsoft.com>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@redhat.com>,
        Namhyung Kim <namhyung@kernel.org>,
        Changbin Du <changbin.du@intel.com>,
        Eric Saint-Etienne <eric.saint.etienne@oracle.com>,
        John Keeping <john@metanate.com>,
        Andi Kleen <ak@linux.intel.com>,
        Song Liu <songliubraving@fb.com>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Leo Yan <leo.yan@linaro.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Brian Robbins <brianrob@microsoft.com>,
        Tom McDonald <Thomas.McDonald@microsoft.com>,
        John Salem <josalem@microsoft.com>
Subject: RE: [PATCH] perf map: fix overlapped map handling
Thread-Topic: [PATCH] perf map: fix overlapped map handling
Thread-Index: AdVv5y6SzPv23L21QnSQJe3E6wWQgAAA9l0AAAMWwpA=
Date:   Fri, 20 Sep 2019 21:46:15 +0000
Message-ID: <BN8PR21MB1362B1921DF8ABF3A19B43A5F7880@BN8PR21MB1362.namprd21.prod.outlook.com>
References: <BN8PR21MB136261C1A4BB2C884F10FCECF7880@BN8PR21MB1362.namprd21.prod.outlook.com>
 <20190920193852.GI4865@kernel.org>
In-Reply-To: <20190920193852.GI4865@kernel.org>
Accept-Language: en-US, en-GB
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=stmaclea@microsoft.com;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-09-20T21:46:14.0220960Z;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure
 Information Protection;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=fab38c1b-ef3a-4dc9-9413-1c4e641f36af;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=Steve.MacLean@microsoft.com; 
x-originating-ip: [24.163.126.65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9b7fd220-3cfc-4819-9695-08d73e13f6a9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020);SRVR:BN8PR21MB1267;
x-ms-traffictypediagnostic: BN8PR21MB1267:|BN8PR21MB1267:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN8PR21MB126789DFCAE4FA3295D463A7F7880@BN8PR21MB1267.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0166B75B74
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(4636009)(396003)(376002)(366004)(39860400002)(346002)(136003)(189003)(199004)(5660300002)(8936002)(55016002)(99286004)(74316002)(66476007)(2906002)(66066001)(76176011)(6506007)(7416002)(9686003)(229853002)(6916009)(33656002)(10090500001)(54906003)(8676002)(8990500004)(4326008)(81156014)(81166006)(22452003)(256004)(6246003)(7696005)(316002)(107886003)(64756008)(52536014)(3846002)(4744005)(26005)(86362001)(446003)(66446008)(66556008)(186003)(66946007)(6116002)(76116006)(486006)(11346002)(7736002)(102836004)(71200400001)(14454004)(71190400001)(6436002)(10290500003)(305945005)(25786009)(478600001)(476003);DIR:OUT;SFP:1102;SCL:1;SRVR:BN8PR21MB1267;H:BN8PR21MB1362.namprd21.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hIlV3jSG/NDW9wTdFO1w3ahcSRQLhAl7LKNxBNRDaAUFTO6e01tXVpdmJGg+IKSwWM42vSQycOjphlYt+hq3HXFHkn7oV/qEl6OO8xq2pirIuz4etcKC1uNx1q+5SC6kdAyS5w5zMPr93Z65TpmBW0fmKG9G+wgddkx1eCQ113ime+PRz84kMHBL3oxbRHnbDCQNY1eiKT8Ye3R+LEbpEFEDVeIW7SAPbfFDbp1Z1TxnrrnlG+eQVnHzP+te9+MMso7STbtbP1SlcbIq1QHShnyG+ewtwj9YKvNgezsXqJNQtt0+9TbIgZFSr5TFa6OS50XN4kkFQ88Swl1oqm0Ww9qFzMbeHYInO0zpBaPtOZaP/TpndLJeKNRta4nfEERK/6ItTUNrku28/Ghj979PlUHPkaVLbSOqbnVotOfwrTw=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b7fd220-3cfc-4819-9695-08d73e13f6a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2019 21:46:15.7156
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 25W/HFk5lFeXPItOrI/f76lHccEczAdJllyU+G7HbZalbERMf4diEKxLJTTGHKBEitS/kDC/DOob6RBsrs9jfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR21MB1267
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>>  			after->start =3D map->end;
>> +			after->pgoff =3D pos->map_ip(pos, map->end);
>
> So is this equivalent to what __split_vma() does in the kernel, i.e.:
>
>        if (new_below)
>                new->vm_end =3D addr;
>        else {
>                new->vm_start =3D addr;
>                new->vm_pgoff +=3D ((addr - vma->vm_start) >> PAGE_SHIFT);
>        }
>
> where new->vm_pgoff starts equal to the vm_pgoff of the mmap being split?

It is roughly equivalent.  The pgoff in struct map is stored in bytes not i=
n pages, so it doesn't include the shift.

An earlier version of this patch used:
  			after->start =3D map->end;
+			after->pgoff +=3D map->end - pos->start;

Instead of the newer Functionally equivalent:
  			after->start =3D map->end;
+			after->pgoff =3D pos->map_ip(pos, map->end);

I preferred the latter form as it made more sense with the assertion that t=
he mapping of map->end should match in pos and after.

Steve