* Re: linux-next: Tree for Apr 6 (arch/x86/mm/init_64.c) [not found] <20210406223109.50ebe35a@canb.auug.org.au> @ 2021-04-06 18:32 ` Randy Dunlap 2021-04-06 18:39 ` Randy Dunlap 0 siblings, 1 reply; 4+ messages in thread From: Randy Dunlap @ 2021-04-06 18:32 UTC (permalink / raw) To: Stephen Rothwell, Linux Next Mailing List Cc: Linux Kernel Mailing List, Oscar Salvador, X86 ML, Andrew Morton, Linux MM On 4/6/21 5:31 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20210401: > on x86_64: # CONFIG_SPARSEMEM_VMEMMAP is not set gcc (SUSE Linux) 7.5.0 ../arch/x86/mm/init_64.c: In function 'remove_pmd_table': ../arch/x86/mm/init_64.c:1127:8: error: implicit declaration of function 'vmemmap_pmd_is_unused'; did you mean 'vmemmap_pmd_populate'? [-Werror=implicit-function-declaration] vmemmap_pmd_is_unused(addr, next)) { ^~~~~~~~~~~~~~~~~~~~~ vmemmap_pmd_populate Looks like that compound "if" is too much for gcc 7.5.0 to handle: } else if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) && vmemmap_pmd_is_unused(addr, next)) { free_hugepage_table(pmd_page(*pmd), altmap); spin_lock(&init_mm.page_table_lock); pmd_clear(pmd); spin_unlock(&init_mm.page_table_lock); } -- ~Randy Reported-by: Randy Dunlap <rdunlap@infradead.org> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: linux-next: Tree for Apr 6 (arch/x86/mm/init_64.c) 2021-04-06 18:32 ` linux-next: Tree for Apr 6 (arch/x86/mm/init_64.c) Randy Dunlap @ 2021-04-06 18:39 ` Randy Dunlap 2021-04-06 19:57 ` Oscar Salvador 0 siblings, 1 reply; 4+ messages in thread From: Randy Dunlap @ 2021-04-06 18:39 UTC (permalink / raw) To: Stephen Rothwell, Linux Next Mailing List Cc: Linux Kernel Mailing List, Oscar Salvador, X86 ML, Andrew Morton, Linux MM On 4/6/21 11:32 AM, Randy Dunlap wrote: > On 4/6/21 5:31 AM, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20210401: >> > > on x86_64: > # CONFIG_SPARSEMEM_VMEMMAP is not set > > > gcc (SUSE Linux) 7.5.0 > > > ../arch/x86/mm/init_64.c: In function 'remove_pmd_table': > ../arch/x86/mm/init_64.c:1127:8: error: implicit declaration of function 'vmemmap_pmd_is_unused'; did you mean 'vmemmap_pmd_populate'? [-Werror=implicit-function-declaration] > vmemmap_pmd_is_unused(addr, next)) { > ^~~~~~~~~~~~~~~~~~~~~ > vmemmap_pmd_populate > > > Looks like that compound "if" is too much for gcc 7.5.0 to handle: > > } else if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) && > vmemmap_pmd_is_unused(addr, next)) { > free_hugepage_table(pmd_page(*pmd), > altmap); > spin_lock(&init_mm.page_table_lock); > pmd_clear(pmd); > spin_unlock(&init_mm.page_table_lock); > } > > This is what I am using for now: --- --- arch/x86/mm/init_64.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- linux-next-20210406.orig/arch/x86/mm/init_64.c +++ linux-next-20210406/arch/x86/mm/init_64.c @@ -1123,14 +1123,16 @@ remove_pmd_table(pmd_t *pmd_start, unsig pmd_clear(pmd); spin_unlock(&init_mm.page_table_lock); pages++; - } else if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) && - vmemmap_pmd_is_unused(addr, next)) { + } +#ifdef CONFIG_SPARSEMEM_VMEMMAP + else if (vmemmap_pmd_is_unused(addr, next)) { free_hugepage_table(pmd_page(*pmd), altmap); spin_lock(&init_mm.page_table_lock); pmd_clear(pmd); spin_unlock(&init_mm.page_table_lock); } +#endif continue; } ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: linux-next: Tree for Apr 6 (arch/x86/mm/init_64.c) 2021-04-06 18:39 ` Randy Dunlap @ 2021-04-06 19:57 ` Oscar Salvador 2021-04-06 22:25 ` Matthew Wilcox 0 siblings, 1 reply; 4+ messages in thread From: Oscar Salvador @ 2021-04-06 19:57 UTC (permalink / raw) To: Randy Dunlap Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, X86 ML, Andrew Morton, Linux MM On Tue, Apr 06, 2021 at 11:39:47AM -0700, Randy Dunlap wrote: > > Looks like that compound "if" is too much for gcc 7.5.0 to handle: > > > > } else if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) && > > vmemmap_pmd_is_unused(addr, next)) { > > free_hugepage_table(pmd_page(*pmd), > > altmap); > > spin_lock(&init_mm.page_table_lock); > > pmd_clear(pmd); > > spin_unlock(&init_mm.page_table_lock); > > } > > > > > > This is what I am using for now: Hi Randy Yeah, that is what v4 was using [1]. We decided to get rid of the ifdef for costimetic reasons but it seems it does not do the trick. I will ask Andrew to squash that on top. [1] https://patchwork.kernel.org/project/linux-mm/patch/20210301083230.30924-4-osalvador@suse.de/ Thanks > > --- > --- > arch/x86/mm/init_64.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > --- linux-next-20210406.orig/arch/x86/mm/init_64.c > +++ linux-next-20210406/arch/x86/mm/init_64.c > @@ -1123,14 +1123,16 @@ remove_pmd_table(pmd_t *pmd_start, unsig > pmd_clear(pmd); > spin_unlock(&init_mm.page_table_lock); > pages++; > - } else if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) && > - vmemmap_pmd_is_unused(addr, next)) { > + } > +#ifdef CONFIG_SPARSEMEM_VMEMMAP > + else if (vmemmap_pmd_is_unused(addr, next)) { > free_hugepage_table(pmd_page(*pmd), > altmap); > spin_lock(&init_mm.page_table_lock); > pmd_clear(pmd); > spin_unlock(&init_mm.page_table_lock); > } > +#endif > > continue; > } > -- Oscar Salvador SUSE L3 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: linux-next: Tree for Apr 6 (arch/x86/mm/init_64.c) 2021-04-06 19:57 ` Oscar Salvador @ 2021-04-06 22:25 ` Matthew Wilcox 0 siblings, 0 replies; 4+ messages in thread From: Matthew Wilcox @ 2021-04-06 22:25 UTC (permalink / raw) To: Oscar Salvador Cc: Randy Dunlap, Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List, X86 ML, Andrew Morton, Linux MM On Tue, Apr 06, 2021 at 09:57:03PM +0200, Oscar Salvador wrote: > On Tue, Apr 06, 2021 at 11:39:47AM -0700, Randy Dunlap wrote: > > > > Looks like that compound "if" is too much for gcc 7.5.0 to handle: > > > > > > } else if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) && > > > vmemmap_pmd_is_unused(addr, next)) { > > > free_hugepage_table(pmd_page(*pmd), > > > altmap); > > > spin_lock(&init_mm.page_table_lock); > > > pmd_clear(pmd); > > > spin_unlock(&init_mm.page_table_lock); > > > } > > > > > > > > > > This is what I am using for now: > > Hi Randy > > Yeah, that is what v4 was using [1]. > We decided to get rid of the ifdef for costimetic reasons but it seems > it does not do the trick. > > I will ask Andrew to squash that on top. This is pretty ugly. What I was doing was this: +++ b/arch/x86/mm/init_64.c @@ -862,6 +862,9 @@ static bool __meminit vmemmap_pmd_is_unused(unsigned long addr, unsigned long en return !memchr_inv((void *)start, PAGE_UNUSED, PMD_SIZE); } +#else +static inline bool vmemmap_pmd_is_unused(unsigned long addr, unsigned long end) +{ return false; } #endif static void __meminit __vmemmap_use_sub_pmd(unsigned long start) @@ -924,6 +927,9 @@ static void __meminit vmemmap_use_new_sub_pmd(unsigned long start, unsigned long if (!IS_ALIGNED(end, PMD_SIZE)) unused_pmd_start = end; } +#else +static inline bool vmemmap_pmd_is_unused(unsigned long addr, unsigned long end) +{ return false; } #endif /* (whitespace damaged, but ...) ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-04-06 22:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20210406223109.50ebe35a@canb.auug.org.au>
2021-04-06 18:32 ` linux-next: Tree for Apr 6 (arch/x86/mm/init_64.c) Randy Dunlap
2021-04-06 18:39 ` Randy Dunlap
2021-04-06 19:57 ` Oscar Salvador
2021-04-06 22:25 ` Matthew Wilcox
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).