linux-nvdimm.lists.01.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>, Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH v6] mm/pgmap: Use correct alignment when looking at first pfn from a region
Date: Tue, 3 Dec 2019 15:42:28 +0530	[thread overview]
Message-ID: <f7a1b3f7-bfbb-e13c-7e8b-c76316bae8e4@linux.ibm.com> (raw)
In-Reply-To: <CAPcyv4i_ZsSKpYADbT46_9ab3GuRf=z3DzVCjkSdswF8PgG4dg@mail.gmail.com>

On 12/3/19 6:20 AM, Dan Williams wrote:
> On Sat, Nov 30, 2019 at 3:13 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> On Wed, 25 Sep 2019 09:21:02 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
>>
>>> Andrew Morton <akpm@linux-foundation.org> writes:
>>>
>>>> On Tue, 17 Sep 2019 21:01:29 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> 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" <aneesh.kumar@linux.ibm.com>
>> 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 <aneesh.kumar@linux.ibm.com>
>> Cc: Ralph Campbell <rcampbell@nvidia.com>
>> Cc: Dan Williams <dan.j.williams@intel.com>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> ---
>>
>>   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.

Kernel is not enforcing this right? ie, If i create multiple namespace
as below

ndctl create-namespace -s 16908288 --align 64K

I can get base_pfn different from res->start PHYS_PFN

Yes that results in other error as below with the current upstream.

[   17.491097] memory add fail, invalid altmap



> 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.
> 

Is the right fix to ensure that we always make sure res->start is 
subsection aligned ? If so we may need the patch series
https://patchwork.kernel.org/project/linux-nvdimm/list/?series=209373

And enforce that to be multiple of subsection size?

-aneesh
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

  reply	other threads:[~2019-12-03 10:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 15:31 [PATCH v6] mm/pgmap: Use correct alignment when looking at first pfn from a region Aneesh Kumar K.V
2019-09-17 21:57 ` Ralph Campbell
2019-09-19 19:25 ` Andrew Morton
2019-09-25  3:51   ` Aneesh Kumar K.V
2019-11-30 23:13     ` Andrew Morton
2019-12-03  0:50       ` Dan Williams
2019-12-03 10:12         ` Aneesh Kumar K.V [this message]
2020-01-31  4:26           ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7a1b3f7-bfbb-e13c-7e8b-c76316bae8e4@linux.ibm.com \
    --to=aneesh.kumar@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).