From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>,
Keith Busch <keith.busch@intel.com>
Cc: Linux MM <linux-mm@kvack.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [RFC PATCH] mm/nvdimm: Fix kernel crash on devm_mremap_pages_release
Date: Wed, 22 May 2019 18:42:19 +0530 [thread overview]
Message-ID: <875zq2k4zw.fsf@linux.ibm.com> (raw)
In-Reply-To: <b775d65b-30e3-aceb-f2f8-f2413b129f52@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> On 5/14/19 9:45 AM, Dan Williams wrote:
>> [ add Keith who was looking at something similar ]
>>
...
>>
>> If it's reserved then we should not be accessing, even if the above
>> works in practice. Isn't the fix something more like this to fix up
>> the assumptions at release time?
>>
>> diff --git a/kernel/memremap.c b/kernel/memremap.c
>> index a856cb5ff192..9074ba14572c 100644
>> --- a/kernel/memremap.c
>> +++ b/kernel/memremap.c
>> @@ -90,6 +90,7 @@ static void devm_memremap_pages_release(void *data)
>> struct device *dev = pgmap->dev;
>> struct resource *res = &pgmap->res;
>> resource_size_t align_start, align_size;
>> + struct vmem_altmap *altmap = pgmap->altmap_valid ? &pgmap->altmap : NULL;
>> unsigned long pfn;
>> int nid;
>>
>> @@ -102,7 +103,10 @@ static void devm_memremap_pages_release(void *data)
>> align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
>> - align_start;
>>
>> - nid = page_to_nid(pfn_to_page(align_start >> PAGE_SHIFT));
>> + pfn = align_start >> PAGE_SHIFT;
>> + if (altmap)
>> + pfn += vmem_altmap_offset(altmap);
>> + nid = page_to_nid(pfn_to_page(pfn));
>>
>> mem_hotplug_begin();
>> if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
>> @@ -110,8 +114,7 @@ static void devm_memremap_pages_release(void *data)
>> __remove_pages(page_zone(pfn_to_page(pfn)), pfn,
>> align_size >> PAGE_SHIFT, NULL);
>> } else {
>> - arch_remove_memory(nid, align_start, align_size,
>> - pgmap->altmap_valid ? &pgmap->altmap : NULL);
>> + arch_remove_memory(nid, align_start, align_size, altmap);
>> kasan_remove_zero_shadow(__va(align_start), align_size);
>> }
>> mem_hotplug_done();
>>
> I did try that first. I was not sure about that. From the memory add vs
> remove perspective.
>
> devm_memremap_pages:
>
> align_start = res->start & ~(SECTION_SIZE - 1);
> align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
> - align_start;
> align_end = align_start + align_size - 1;
>
> error = arch_add_memory(nid, align_start, align_size, altmap,
> false);
>
>
> devm_memremap_pages_release:
>
> /* pages are dead and unused, undo the arch mapping */
> align_start = res->start & ~(SECTION_SIZE - 1);
> align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
> - align_start;
>
> arch_remove_memory(nid, align_start, align_size,
> pgmap->altmap_valid ? &pgmap->altmap : NULL);
>
>
> Now if we are fixing the memremap_pages_release, shouldn't we adjust
> alig_start w.r.t memremap_pages too? and I was not sure what that means
> w.r.t add/remove alignment requirements.
>
> What is the intended usage of reserve area? I guess we want that part to
> be added? if so shouldn't we remove them?
We need to intialize the struct page backing the reserve area too right?
Where should we do that?
-aneesh
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Dan Williams <dan.j.williams@intel.com>,
Keith Busch <keith.busch@intel.com>
Cc: Linux MM <linux-mm@kvack.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [RFC PATCH] mm/nvdimm: Fix kernel crash on devm_mremap_pages_release
Date: Wed, 22 May 2019 18:42:19 +0530 [thread overview]
Message-ID: <875zq2k4zw.fsf@linux.ibm.com> (raw)
In-Reply-To: <b775d65b-30e3-aceb-f2f8-f2413b129f52@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> On 5/14/19 9:45 AM, Dan Williams wrote:
>> [ add Keith who was looking at something similar ]
>>
...
>>
>> If it's reserved then we should not be accessing, even if the above
>> works in practice. Isn't the fix something more like this to fix up
>> the assumptions at release time?
>>
>> diff --git a/kernel/memremap.c b/kernel/memremap.c
>> index a856cb5ff192..9074ba14572c 100644
>> --- a/kernel/memremap.c
>> +++ b/kernel/memremap.c
>> @@ -90,6 +90,7 @@ static void devm_memremap_pages_release(void *data)
>> struct device *dev = pgmap->dev;
>> struct resource *res = &pgmap->res;
>> resource_size_t align_start, align_size;
>> + struct vmem_altmap *altmap = pgmap->altmap_valid ? &pgmap->altmap : NULL;
>> unsigned long pfn;
>> int nid;
>>
>> @@ -102,7 +103,10 @@ static void devm_memremap_pages_release(void *data)
>> align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
>> - align_start;
>>
>> - nid = page_to_nid(pfn_to_page(align_start >> PAGE_SHIFT));
>> + pfn = align_start >> PAGE_SHIFT;
>> + if (altmap)
>> + pfn += vmem_altmap_offset(altmap);
>> + nid = page_to_nid(pfn_to_page(pfn));
>>
>> mem_hotplug_begin();
>> if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
>> @@ -110,8 +114,7 @@ static void devm_memremap_pages_release(void *data)
>> __remove_pages(page_zone(pfn_to_page(pfn)), pfn,
>> align_size >> PAGE_SHIFT, NULL);
>> } else {
>> - arch_remove_memory(nid, align_start, align_size,
>> - pgmap->altmap_valid ? &pgmap->altmap : NULL);
>> + arch_remove_memory(nid, align_start, align_size, altmap);
>> kasan_remove_zero_shadow(__va(align_start), align_size);
>> }
>> mem_hotplug_done();
>>
> I did try that first. I was not sure about that. From the memory add vs
> remove perspective.
>
> devm_memremap_pages:
>
> align_start = res->start & ~(SECTION_SIZE - 1);
> align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
> - align_start;
> align_end = align_start + align_size - 1;
>
> error = arch_add_memory(nid, align_start, align_size, altmap,
> false);
>
>
> devm_memremap_pages_release:
>
> /* pages are dead and unused, undo the arch mapping */
> align_start = res->start & ~(SECTION_SIZE - 1);
> align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
> - align_start;
>
> arch_remove_memory(nid, align_start, align_size,
> pgmap->altmap_valid ? &pgmap->altmap : NULL);
>
>
> Now if we are fixing the memremap_pages_release, shouldn't we adjust
> alig_start w.r.t memremap_pages too? and I was not sure what that means
> w.r.t add/remove alignment requirements.
>
> What is the intended usage of reserve area? I guess we want that part to
> be added? if so shouldn't we remove them?
We need to intialize the struct page backing the reserve area too right?
Where should we do that?
-aneesh
next prev parent reply other threads:[~2019-05-22 13:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 2:53 [RFC PATCH] mm/nvdimm: Fix kernel crash on devm_mremap_pages_release Aneesh Kumar K.V
2019-05-14 2:53 ` Aneesh Kumar K.V
2019-05-14 4:05 ` Anshuman Khandual
2019-05-14 4:05 ` Anshuman Khandual
2019-05-14 4:05 ` Anshuman Khandual
2019-05-14 4:15 ` Dan Williams
2019-05-14 4:15 ` Dan Williams
2019-05-14 4:15 ` Dan Williams
2019-05-14 4:40 ` Aneesh Kumar K.V
2019-05-14 4:40 ` Aneesh Kumar K.V
2019-05-14 4:40 ` Aneesh Kumar K.V
2019-05-22 13:12 ` Aneesh Kumar K.V [this message]
2019-05-22 13:12 ` Aneesh Kumar K.V
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=875zq2k4zw.fsf@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=keith.busch@intel.com \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linuxppc-dev@lists.ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.