| Message ID | 20220216121109.157605-1-wangkefeng.wang@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v4,1/2] Revert "powerpc: Set max_mapnr correctly" | expand |
Hi maintainers， I saw the patches has been reviewed[1], could they be merged? Many thanks. [1] https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=286464 On 2022/2/16 20:11, Kefeng Wang wrote: > This reverts commit 602946ec2f90d5bd965857753880db29d2d9a1e9. > > If CONFIG_HIGHMEM enabled, highmem will be disappeared with max_mapnr > set to max_low_pfn, see mem_init(), > > for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { > ... > free_highmem_page(); > } > > Revert it and will fix virt_addr_valid() check in the next patch. > > Cc: Christophe Leroy <christophe.leroy@csgroup.eu> > Fixes: 602946ec2f90 ("powerpc: Set max_mapnr correctly") > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > v4: > - new patch > arch/powerpc/mm/mem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c > index 8e301cd8925b..4d221d033804 100644 > --- a/arch/powerpc/mm/mem.c > +++ b/arch/powerpc/mm/mem.c > @@ -255,7 +255,7 @@ void __init mem_init(void) > #endif > > high_memory = (void *) __va(max_low_pfn * PAGE_SIZE); > - set_max_mapnr(max_low_pfn); > + set_max_mapnr(max_pfn); > > kasan_late_init(); >
Hi, Le 26/03/2022 à 08:55, Kefeng Wang a écrit : > Hi maintainers， > > I saw the patches has been reviewed[1], could they be merged? Thinking about it once more, I think the patches should go in reverse order. Patch 2 should go first and patch 1 should go after. Otherwise, once patch 1 is applied and patch 2 is not applied yet, virt_addr_valid() doesn't work anymore. Christophe > > Many thanks. > > [1] https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=286464 > > On 2022/2/16 20:11, Kefeng Wang wrote: >> This reverts commit 602946ec2f90d5bd965857753880db29d2d9a1e9. >> >> If CONFIG_HIGHMEM enabled, highmem will be disappeared with max_mapnr >> set to max_low_pfn, see mem_init(), >> >> for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { >> ... >> free_highmem_page(); >> } >> >> Revert it and will fix virt_addr_valid() check in the next patch. >> >> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> >> Fixes: 602946ec2f90 ("powerpc: Set max_mapnr correctly") >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> >> --- >> v4: >> - new patch >> arch/powerpc/mm/mem.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c >> index 8e301cd8925b..4d221d033804 100644 >> --- a/arch/powerpc/mm/mem.c >> +++ b/arch/powerpc/mm/mem.c >> @@ -255,7 +255,7 @@ void __init mem_init(void) >> #endif >> high_memory = (void *) __va(max_low_pfn * PAGE_SIZE); >> - set_max_mapnr(max_low_pfn); >> + set_max_mapnr(max_pfn); >> kasan_late_init();
On 2022/3/28 22:12, Christophe Leroy wrote: > Hi, > > Le 26/03/2022 à 08:55, Kefeng Wang a écrit : >> Hi maintainers， >> >> I saw the patches has been reviewed[1], could they be merged? > Thinking about it once more, I think the patches should go in reverse > order. Patch 2 should go first and patch 1 should go after. > > Otherwise, once patch 1 is applied and patch 2 is not applied yet, > virt_addr_valid() doesn't work anymore. Should I resend them or could the maintainer reverse order when merging them? > > Christophe > >> Many thanks. >> >> [1] https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=286464 >>
Kefeng Wang <wangkefeng.wang@huawei.com> writes: > On 2022/3/28 22:12, Christophe Leroy wrote: >> Hi, >> >> Le 26/03/2022 à 08:55, Kefeng Wang a écrit : >>> Hi maintainers， >>> >>> I saw the patches has been reviewed[1], could they be merged? >> Thinking about it once more, I think the patches should go in reverse >> order. Patch 2 should go first and patch 1 should go after. >> >> Otherwise, once patch 1 is applied and patch 2 is not applied yet, >> virt_addr_valid() doesn't work anymore. > > Should I resend them or could the maintainer reverse order when merging > them? I'll reverse them. I've found some breakage in other code while testing this, so I'll fix that up first before merging these. In patch 2 you didn't say what hardware you hit this on, what CPU does your system have? cheers
On 2022/4/4 20:31, Michael Ellerman wrote: > Kefeng Wang <wangkefeng.wang@huawei.com> writes: >> On 2022/3/28 22:12, Christophe Leroy wrote: >>> Hi, >>> >>> Le 26/03/2022 à 08:55, Kefeng Wang a écrit : >>>> Hi maintainers， >>>> >>>> I saw the patches has been reviewed[1], could they be merged? >>> Thinking about it once more, I think the patches should go in reverse >>> order. Patch 2 should go first and patch 1 should go after. >>> >>> Otherwise, once patch 1 is applied and patch 2 is not applied yet, >>> virt_addr_valid() doesn't work anymore. >> Should I resend them or could the maintainer reverse order when merging >> them? > I'll reverse them. I've found some breakage in other code while testing > this, so I'll fix that up first before merging these. Thanks. > > In patch 2 you didn't say what hardware you hit this on, what CPU does > your system have? CPU e5500 from fsl,P5040DS. > > cheers > .
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 8e301cd8925b..4d221d033804 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -255,7 +255,7 @@ void __init mem_init(void) #endif high_memory = (void *) __va(max_low_pfn * PAGE_SIZE); - set_max_mapnr(max_low_pfn); + set_max_mapnr(max_pfn); kasan_late_init();
This reverts commit 602946ec2f90d5bd965857753880db29d2d9a1e9. If CONFIG_HIGHMEM enabled, highmem will be disappeared with max_mapnr set to max_low_pfn, see mem_init(), for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) { ... free_highmem_page(); } Revert it and will fix virt_addr_valid() check in the next patch. Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Fixes: 602946ec2f90 ("powerpc: Set max_mapnr correctly") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- v4: - new patch arch/powerpc/mm/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)