From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17A9DC432C3 for ; Tue, 3 Dec 2019 00:50:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA927206F0 for ; Tue, 3 Dec 2019 00:50:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="MTvaMflR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA927206F0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A88216B0003; Mon, 2 Dec 2019 19:50:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A386F6B0006; Mon, 2 Dec 2019 19:50:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9274A6B0007; Mon, 2 Dec 2019 19:50:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7C8106B0003 for ; Mon, 2 Dec 2019 19:50:56 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 2E4FF180AD806 for ; Tue, 3 Dec 2019 00:50:56 +0000 (UTC) X-FDA: 76222000512.24.arch95_2510e0118c11c X-HE-Tag: arch95_2510e0118c11c X-Filterd-Recvd-Size: 6142 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Dec 2019 00:50:54 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id 14so1598528oir.12 for ; Mon, 02 Dec 2019 16:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+KYwlF63SvVl9zvd7kjkiyaaPgfwW7BR11F8RXtCdLo=; b=MTvaMflRHI4pLeqCbUeYDfLDz6DWAEDVTfpR79PDYXX7x6WtPjswiiMDHng89WW4bR kk6fpeQUA8XDt7465M2Vcba0SHU9DJjO/ttcmBQziw5Ge57Qz3ydsShP7zXLQfVM7pVC cFygzBSGRe1oz5txdb/JfSVxt2FzltaHFbNIp3KPKcHBKgEn4/bW8rJOcqpRJW+Id6B+ 5O0hiycA6Ftwi1V7HgVapDFQZpsTjp7/dggJ5TLf9tCFG7TJUJfzOgd13HlMtFbOuxvp wvgrhzCnr0I4FjxX/YUIWoZElA1ZVuAojFBzfiryQDvxZbM1PzNUWy0TSfUPYEhqt9pq ighw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+KYwlF63SvVl9zvd7kjkiyaaPgfwW7BR11F8RXtCdLo=; b=LD/QD9c6lqkmRsoWZFr0zbBFS0SAEAJprv78/Huo6ima3gnx2wlIsNxhUNGHgAmjVA 5kjlqqlHcxmquneyvLi3unau+rs4qtQOLUy87WQHLLO5H/DpqJgS8EMHyqNRZ8G6nwo6 H+EPRWsHmyK0Ye95Oc01pQC99bRgvwzXMMIeP66kWb1r6Z9NkEe76lNByWxdcjPFzAOE OkAGg+ZbONY+M7OLsUoJVm5oucjkYgOlXguvayPnkP9osZtO8+39T0+v0LUu0aziqZqZ ct0bPT62OAG8oGTW5Z7DKqG1+L574kVKsngb8AQfiAOBMCuD3DooBysJ5ivfY7wjBUSG hj/Q== X-Gm-Message-State: APjAAAV2g6Ff29RlALIwswiMFCUe5e+Ch3lUOoE2bGfTIuqHtP9jDrnj PqywFrdo4uX6mfaj0kzalQZ+RTwCCYd2iWumo7jhOQ== X-Google-Smtp-Source: APXvYqy+HCMWGNkXsjIVg/HdulhTmdEkI1QVsTFxrTgd36u7R3e/SzRv39SSgSOa9AYRp7RxNhy6wgYdYja/ukTZ/OA= X-Received: by 2002:a05:6808:1da:: with SMTP id x26mr1635236oic.149.1575334253642; Mon, 02 Dec 2019 16:50:53 -0800 (PST) MIME-Version: 1.0 References: <20190917153129.12905-1-aneesh.kumar@linux.ibm.com> <20190919122501.df660f0d23806a3f46d11b61@linux-foundation.org> <8736glowyh.fsf@linux.ibm.com> <20191130151317.26c69ef711dba28ff642cca3@linux-foundation.org> In-Reply-To: <20191130151317.26c69ef711dba28ff642cca3@linux-foundation.org> From: Dan Williams Date: Mon, 2 Dec 2019 16:50:42 -0800 Message-ID: Subject: Re: [PATCH v6] mm/pgmap: Use correct alignment when looking at first pfn from a region To: Andrew Morton Cc: "Aneesh Kumar K.V" , linux-nvdimm , Linux MM Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Nov 30, 2019 at 3:13 PM Andrew Morton wrote: > > On Wed, 25 Sep 2019 09:21:02 +0530 "Aneesh Kumar K.V" wrote: > > > Andrew Morton writes: > > > > > On Tue, 17 Sep 2019 21:01:29 +0530 "Aneesh Kumar K.V" wrote: > > > > > >> vmem_altmap_offset() adjust the section aligned base_pfn offset. > > >> So we need to make sure we account for the same when computing base_pfn. > > >> > > >> ie, for altmap_valid case, our pfn_first should be: > > >> > > >> pfn_first = altmap->base_pfn + vmem_altmap_offset(altmap); > > > > > > What are the user-visible runtime effects of this change? > > > > This was found by code inspection. If the pmem region is not correctly > > section aligned we can skip pfns while iterating device pfn using > > for_each_device_pfn(pfn, pgmap) > > > > > > I still would want Dan to ack the change though. > > > > Dan? > > > From: "Aneesh Kumar K.V" > Subject: mm/pgmap: use correct alignment when looking at first pfn from a region > > vmem_altmap_offset() adjusts the section aligned base_pfn offset. So we > need to make sure we account for the same when computing base_pfn. > > ie, for altmap_valid case, our pfn_first should be: > > pfn_first = altmap->base_pfn + vmem_altmap_offset(altmap); > > This was found by code inspection. If the pmem region is not correctly > section aligned we can skip pfns while iterating device pfn using > > for_each_device_pfn(pfn, pgmap) > > [akpm@linux-foundation.org: coding style fixes] > Link: http://lkml.kernel.org/r/20190917153129.12905-1-aneesh.kumar@linux.ibm.com > Signed-off-by: Aneesh Kumar K.V > Cc: Ralph Campbell > Cc: Dan Williams > Signed-off-by: Andrew Morton > --- > > mm/memremap.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > --- a/mm/memremap.c~mm-pgmap-use-correct-alignment-when-looking-at-first-pfn-from-a-region > +++ a/mm/memremap.c > @@ -55,8 +55,16 @@ static void pgmap_array_delete(struct re > > static unsigned long pfn_first(struct dev_pagemap *pgmap) > { > - return PHYS_PFN(pgmap->res.start) + > - vmem_altmap_offset(pgmap_altmap(pgmap)); > + const struct resource *res = &pgmap->res; > + struct vmem_altmap *altmap = pgmap_altmap(pgmap); > + unsigned long pfn; > + > + if (altmap) > + pfn = altmap->base_pfn + vmem_altmap_offset(altmap); > + else > + pfn = PHYS_PFN(res->start); This would only be a problem if res->start is not subsection aligned. Is that bug triggering in your case, or is this just inspection. Now that the subsections can be assumed as the minimum mapping granularity I'd rather see a cleanup I'd rather cleanup the implementation to eliminate altmap->base_pfn or at least assert that PHYS_PFN(res->start) and altmap->base_pfn are always identical. Otherwise ->base_pfn is supposed to be just a convenient way to recall the bounds of the memory hotplug operation deeper in the vmemmap setup.