| Message ID | 20190514025512.9670-1-aneesh.kumar@linux.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | mm/nvdimm: Use correct alignment when looking at first pfnfrom a region | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch next (8150a153c013aa2dd1ffae43370b89ac1347a7fb) |
| snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
| snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 11 lines checked |
On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> wrote: > > We already add the start_pad to the resource->start but fails to section > align the start. This make sure with altmap we compute the right first > pfn when start_pad is zero and we are doing an align down of start address. > > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> > --- > kernel/memremap.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/memremap.c b/kernel/memremap.c > index a856cb5ff192..23d77b60e728 100644 > --- a/kernel/memremap.c > +++ b/kernel/memremap.c > @@ -59,9 +59,9 @@ static unsigned long pfn_first(struct dev_pagemap *pgmap) > { > const struct resource *res = &pgmap->res; > struct vmem_altmap *altmap = &pgmap->altmap; > - unsigned long pfn; > + unsigned long pfn = PHYS_PFN(res->start); > > - pfn = res->start >> PAGE_SHIFT; > + pfn = SECTION_ALIGN_DOWN(pfn); This does not seem right to me it breaks the assumptions of where the first expected valid pfn occurs in the passed in range.
On 5/14/19 9:59 AM, Dan Williams wrote: > On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V > <aneesh.kumar@linux.ibm.com> wrote: >> >> We already add the start_pad to the resource->start but fails to section >> align the start. This make sure with altmap we compute the right first >> pfn when start_pad is zero and we are doing an align down of start address. >> >> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> >> --- >> kernel/memremap.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/memremap.c b/kernel/memremap.c >> index a856cb5ff192..23d77b60e728 100644 >> --- a/kernel/memremap.c >> +++ b/kernel/memremap.c >> @@ -59,9 +59,9 @@ static unsigned long pfn_first(struct dev_pagemap *pgmap) >> { >> const struct resource *res = &pgmap->res; >> struct vmem_altmap *altmap = &pgmap->altmap; >> - unsigned long pfn; >> + unsigned long pfn = PHYS_PFN(res->start); >> >> - pfn = res->start >> PAGE_SHIFT; >> + pfn = SECTION_ALIGN_DOWN(pfn); > > This does not seem right to me it breaks the assumptions of where the > first expected valid pfn occurs in the passed in range. > How do we define the first valid pfn? Isn't that at pfn_sb->dataoff ? -aneesh
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes: > On 5/14/19 9:59 AM, Dan Williams wrote: >> On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V >> <aneesh.kumar@linux.ibm.com> wrote: >>> >>> We already add the start_pad to the resource->start but fails to section >>> align the start. This make sure with altmap we compute the right first >>> pfn when start_pad is zero and we are doing an align down of start address. >>> >>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> >>> --- >>> kernel/memremap.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/kernel/memremap.c b/kernel/memremap.c >>> index a856cb5ff192..23d77b60e728 100644 >>> --- a/kernel/memremap.c >>> +++ b/kernel/memremap.c >>> @@ -59,9 +59,9 @@ static unsigned long pfn_first(struct dev_pagemap *pgmap) >>> { >>> const struct resource *res = &pgmap->res; >>> struct vmem_altmap *altmap = &pgmap->altmap; >>> - unsigned long pfn; >>> + unsigned long pfn = PHYS_PFN(res->start); >>> >>> - pfn = res->start >> PAGE_SHIFT; >>> + pfn = SECTION_ALIGN_DOWN(pfn); >> >> This does not seem right to me it breaks the assumptions of where the >> first expected valid pfn occurs in the passed in range. >> > > How do we define the first valid pfn? Isn't that at pfn_sb->dataoff ? for altmap the pfn_first should be pfn_first = altmap->base_pfn + vmem_altmap_offset(altmap); ? -aneesh
diff --git a/kernel/memremap.c b/kernel/memremap.c index a856cb5ff192..23d77b60e728 100644 --- a/kernel/memremap.c +++ b/kernel/memremap.c @@ -59,9 +59,9 @@ static unsigned long pfn_first(struct dev_pagemap *pgmap) { const struct resource *res = &pgmap->res; struct vmem_altmap *altmap = &pgmap->altmap; - unsigned long pfn; + unsigned long pfn = PHYS_PFN(res->start); - pfn = res->start >> PAGE_SHIFT; + pfn = SECTION_ALIGN_DOWN(pfn); if (pgmap->altmap_valid) pfn += vmem_altmap_offset(altmap); return pfn;
We already add the start_pad to the resource->start but fails to section align the start. This make sure with altmap we compute the right first pfn when start_pad is zero and we are doing an align down of start address. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> --- kernel/memremap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)