| Message ID | 20240508173116.2866192-1-namcao@linutronix.de (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | riscv: Don't use hugepage mappings for vmemmap if it's not supported | expand |
Hi Nam, On 08/05/2024 19:31, Nam Cao wrote: > Commit ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") broke XIP > kernel, because huge pages are not supported on XIP kernel. I don't understand why XIP kernels can't support huge vmalloc mappings, so I think the right fix would be to enable such mappings on XIP. WDYT? Thanks, Alex > > Only use hugepage mapping if it is supported. > > Fixes: ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") > Signed-off-by: Nam Cao <namcao@linutronix.de> > Cc: Alexandre Ghiti <alexghiti@rivosinc.com> > Cc: <stable@vger.kernel.org> > --- > arch/riscv/mm/init.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 968761843203..c081e7d349b1 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -1414,6 +1414,8 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, > int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > struct vmem_altmap *altmap) > { > + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP)) > + return vmemmap_populate_basepages(start, end, node, NULL); > /* > * Note that SPARSEMEM_VMEMMAP is only selected for rv64 and that we > * can't use hugepage mappings for 2-level page table because in case of
On Wed, May 08, 2024 at 08:22:43PM +0200, Alexandre Ghiti wrote: > Hi Nam, Hi Alex, > > Commit ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") broke XIP > > kernel, because huge pages are not supported on XIP kernel. > > I don't understand why XIP kernels can't support huge vmalloc mappings, Me neither. > so I > think the right fix would be to enable such mappings on XIP. WDYT? I agree that is the ideal solution. But I don't want to send any new feature to the stable trees (stable folks may even reject such patch). So I intend that to be in another patch. Best regards, Nam
Hi Nam, On 08/05/2024 20:46, Nam Cao wrote: > On Wed, May 08, 2024 at 08:22:43PM +0200, Alexandre Ghiti wrote: >> Hi Nam, > Hi Alex, > >>> Commit ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") broke XIP >>> kernel, because huge pages are not supported on XIP kernel. >> I don't understand why XIP kernels can't support huge vmalloc mappings, > Me neither. > >> so I >> think the right fix would be to enable such mappings on XIP. WDYT? > I agree that is the ideal solution. But I don't want to send any new > feature to the stable trees (stable folks may even reject such patch). > So I intend that to be in another patch. I have been thinking about that, and I actually think that the real fix is enabling huge vmalloc mappings for XIP as it was an oversight/mistake in the first place. On 64-bit kernels, there are no reasons we can't use PMD mappings for vmalloc. So I'd rather not go with this fix. Thanks, Alex > > Best regards, > Nam
On Fri, May 24, 2024 at 10:07:40PM +0200, Alexandre Ghiti wrote: > Hi Nam, Hi Alex, > On 08/05/2024 20:46, Nam Cao wrote: > > On Wed, May 08, 2024 at 08:22:43PM +0200, Alexandre Ghiti wrote: > > > > Commit ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") broke XIP > > > > kernel, because huge pages are not supported on XIP kernel. > > > I don't understand why XIP kernels can't support huge vmalloc mappings, > > Me neither. > > > > > so I > > > think the right fix would be to enable such mappings on XIP. WDYT? > > I agree that is the ideal solution. But I don't want to send any new > > feature to the stable trees (stable folks may even reject such patch). > > So I intend that to be in another patch. > > > I have been thinking about that, and I actually think that the real fix is > enabling huge vmalloc mappings for XIP as it was an oversight/mistake in the > first place. On 64-bit kernels, there are no reasons we can't use PMD > mappings for vmalloc. So I'd rather not go with this fix. If you have strong preference for that approach, then we can go that way. I don't like this patch that much anyway. The only upside is that it is safer to backport, because it is obvious that it won't break anything else. I will do some testing with PMD mapping on XIP, and come back later. Best regards, Nam
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 968761843203..c081e7d349b1 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -1414,6 +1414,8 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, struct vmem_altmap *altmap) { + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP)) + return vmemmap_populate_basepages(start, end, node, NULL); /* * Note that SPARSEMEM_VMEMMAP is only selected for rv64 and that we * can't use hugepage mappings for 2-level page table because in case of
Commit ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") broke XIP kernel, because huge pages are not supported on XIP kernel. Only use hugepage mapping if it is supported. Fixes: ff172d4818ad ("riscv: Use hugepage mappings for vmemmap") Signed-off-by: Nam Cao <namcao@linutronix.de> Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Cc: <stable@vger.kernel.org> --- arch/riscv/mm/init.c | 2 ++ 1 file changed, 2 insertions(+)