* [PATCH] powerepc/book3s64/hash: Align start address correctly with bolt mapping
@ 2019-10-28 9:51 Aneesh Kumar K.V
2019-10-29 11:08 ` Michael Ellerman
0 siblings, 1 reply; 3+ messages in thread
From: Aneesh Kumar K.V @ 2019-10-28 9:51 UTC (permalink / raw)
To: mpe; +Cc: Aneesh Kumar K.V, linuxppc-dev
Without this we can miss mapping the last page covering the end address passed
BUG: Unable to handle kernel data access at 0xc001000406000000
Faulting instruction address: 0xc000000000090790
NIP [c000000000090790] arch_add_memory+0xc0/0x130
LR [c000000000090744] arch_add_memory+0x74/0x130
Call Trace:
arch_add_memory+0x74/0x130 (unreliable)
memremap_pages+0x74c/0xa30
devm_memremap_pages+0x3c/0xa0
pmem_attach_disk+0x188/0x770
nvdimm_bus_probe+0xd8/0x470
really_probe+0x148/0x570
driver_probe_device+0x19c/0x1d0
device_driver_attach+0xcc/0x100
bind_store+0x134/0x1c0
drv_attr_store+0x44/0x60
sysfs_kf_write+0x74/0xc0
kernfs_fop_write+0x1b4/0x290
__vfs_write+0x3c/0x70
vfs_write+0xd0/0x260
ksys_write+0xdc/0x130
system_call+0x5c/0x68
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/book3s64/hash_utils.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index 6c123760164e..f66a1c6922d6 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -257,8 +257,10 @@ int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
DBG("htab_bolt_mapping(%lx..%lx -> %lx (%lx,%d,%d)\n",
vstart, vend, pstart, prot, psize, ssize);
- for (vaddr = vstart, paddr = pstart; vaddr < vend;
- vaddr += step, paddr += step) {
+ vaddr = ALIGN_DOWN(vstart, step);
+ paddr = ALIGN_DOWN(pstart, step);
+
+ for (; vaddr < vend; vaddr += step, paddr += step) {
unsigned long hash, hpteg;
unsigned long vsid = get_kernel_vsid(vaddr, ssize);
unsigned long vpn = hpt_vpn(vaddr, vsid, ssize);
--
2.21.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] powerepc/book3s64/hash: Align start address correctly with bolt mapping
2019-10-28 9:51 [PATCH] powerepc/book3s64/hash: Align start address correctly with bolt mapping Aneesh Kumar K.V
@ 2019-10-29 11:08 ` Michael Ellerman
0 siblings, 0 replies; 3+ messages in thread
From: Michael Ellerman @ 2019-10-29 11:08 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Aneesh Kumar K.V, linuxppc-dev
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> Without this we can miss mapping the last page covering the end address passed
>
> BUG: Unable to handle kernel data access at 0xc001000406000000
> Faulting instruction address: 0xc000000000090790
> NIP [c000000000090790] arch_add_memory+0xc0/0x130
> LR [c000000000090744] arch_add_memory+0x74/0x130
> Call Trace:
> arch_add_memory+0x74/0x130 (unreliable)
> memremap_pages+0x74c/0xa30
> devm_memremap_pages+0x3c/0xa0
> pmem_attach_disk+0x188/0x770
> nvdimm_bus_probe+0xd8/0x470
> really_probe+0x148/0x570
> driver_probe_device+0x19c/0x1d0
> device_driver_attach+0xcc/0x100
> bind_store+0x134/0x1c0
> drv_attr_store+0x44/0x60
> sysfs_kf_write+0x74/0xc0
> kernfs_fop_write+0x1b4/0x290
> __vfs_write+0x3c/0x70
> vfs_write+0xd0/0x260
> ksys_write+0xdc/0x130
> system_call+0x5c/0x68
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/book3s64/hash_utils.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
Presumably you want this backported to kernels that have any nvdimm
support on powerpc?
cheers
> diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
> index 6c123760164e..f66a1c6922d6 100644
> --- a/arch/powerpc/mm/book3s64/hash_utils.c
> +++ b/arch/powerpc/mm/book3s64/hash_utils.c
> @@ -257,8 +257,10 @@ int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
> DBG("htab_bolt_mapping(%lx..%lx -> %lx (%lx,%d,%d)\n",
> vstart, vend, pstart, prot, psize, ssize);
>
> - for (vaddr = vstart, paddr = pstart; vaddr < vend;
> - vaddr += step, paddr += step) {
> + vaddr = ALIGN_DOWN(vstart, step);
> + paddr = ALIGN_DOWN(pstart, step);
> +
> + for (; vaddr < vend; vaddr += step, paddr += step) {
> unsigned long hash, hpteg;
> unsigned long vsid = get_kernel_vsid(vaddr, ssize);
> unsigned long vpn = hpt_vpn(vaddr, vsid, ssize);
> --
> 2.21.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH] powerepc/book3s64/hash: Align start address correctly with bolt mapping
@ 2019-12-02 6:40 Aneesh Kumar K.V
0 siblings, 0 replies; 3+ messages in thread
From: Aneesh Kumar K.V @ 2019-12-02 6:40 UTC (permalink / raw)
To: mpe; +Cc: Aneesh Kumar K.V, linuxppc-dev
This ensures we don't do a partial mapping of memory. With nvdimm, when creating
namespaces with size not aligned to 16MB, kernel ends up partially mapping the pages.
This results in a crash when a namespace is removed. This is due to kernel doing
unmap of a page that was part of both the namespace.
Another patch series will make sure we always create namespaces aligned to 16MB.
But we can do better by avoiding mapping pages that are not aligned. This helps
to catch access to these partially mapped pages early.
A kernel crash will look like below:
BUG: Unable to handle kernel data access at 0xc001000406000000
Faulting instruction address: 0xc000000000090790
NIP [c000000000090790] arch_add_memory+0xc0/0x130
LR [c000000000090744] arch_add_memory+0x74/0x130
Call Trace:
arch_add_memory+0x74/0x130 (unreliable)
memremap_pages+0x74c/0xa30
devm_memremap_pages+0x3c/0xa0
pmem_attach_disk+0x188/0x770
nvdimm_bus_probe+0xd8/0x470
really_probe+0x148/0x570
driver_probe_device+0x19c/0x1d0
device_driver_attach+0xcc/0x100
bind_store+0x134/0x1c0
drv_attr_store+0x44/0x60
sysfs_kf_write+0x74/0xc0
kernfs_fop_write+0x1b4/0x290
__vfs_write+0x3c/0x70
vfs_write+0xd0/0x260
ksys_write+0xdc/0x130
system_call+0x5c/0x68
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/book3s64/hash_utils.c | 12 +++++++++---
arch/powerpc/mm/book3s64/radix_pgtable.c | 1 +
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index b30435c7d804..51fb4a4df57b 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -257,8 +257,12 @@ int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
DBG("htab_bolt_mapping(%lx..%lx -> %lx (%lx,%d,%d)\n",
vstart, vend, pstart, prot, psize, ssize);
- for (vaddr = vstart, paddr = pstart; vaddr < vend;
- vaddr += step, paddr += step) {
+ /* Carefully map only the possible range */
+ vaddr = _ALIGN_UP(vstart, step);
+ paddr = _ALIGN_UP(pstart, step);
+ vend = _ALIGN_DOWN(vend, step);
+
+ for (; vaddr < vend; vaddr += step, paddr += step) {
unsigned long hash, hpteg;
unsigned long vsid = get_kernel_vsid(vaddr, ssize);
unsigned long vpn = hpt_vpn(vaddr, vsid, ssize);
@@ -340,7 +344,9 @@ int htab_remove_mapping(unsigned long vstart, unsigned long vend,
if (!mmu_hash_ops.hpte_removebolted)
return -ENODEV;
- for (vaddr = vstart; vaddr < vend; vaddr += step) {
+ /* Unmap the full reange specificied */
+ vaddr = _ALIGN_DOWN(vstart, step);
+ for (;vaddr < vend; vaddr += step) {
rc = mmu_hash_ops.hpte_removebolted(vaddr, psize, ssize);
if (rc == -ENOENT) {
ret = -ENOENT;
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 6ee17d09649c..e40d2f923d4d 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -260,6 +260,7 @@ static int __meminit create_physical_mapping(unsigned long start,
int psize;
start = _ALIGN_UP(start, PAGE_SIZE);
+ end = _ALIGN_DOWN(end, PAGE_SIZE);
for (addr = start; addr < end; addr += mapping_size) {
unsigned long gap, previous_size;
int rc;
--
2.23.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-02 6:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-28 9:51 [PATCH] powerepc/book3s64/hash: Align start address correctly with bolt mapping Aneesh Kumar K.V
2019-10-29 11:08 ` Michael Ellerman
2019-12-02 6:40 Aneesh Kumar K.V
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.