Hi, On Wed, Mar 21, 2012 at 03:47:21PM -0700, Andrew Morton wrote: > On Wed, 21 Mar 2012 18:07:41 -0400 > Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx> wrote: > > > On Mon, Mar 12, 2012 at 6:30 PM, Naoya Horiguchi > > <n-horiguchi@xxxxxxxxxxxxx> wrote: > > > These macros will be used in later patch, where all usage are expected > > > to be optimized away without #ifdef CONFIG_TRANSPARENT_HUGEPAGE. > > > But to detect unexpected usages, we convert existing BUG() to BUILD_BUG(). > > > > Just a heads up that this showed up in linux-next today as the > > cause of a new build failure for an ARM board: > > > > http://kisskb.ellerman.id.au/kisskb/buildresult/5930053/ > > The internet started working again. > > mm/pgtable-generic.c: In function 'pmdp_clear_flush_young': > mm/pgtable-generic.c:76: error: call to '__build_bug_failed' declared with attribute error: BUILD_BUG failed > > I guess we shouldn't be evaluating HPAGE_PMD_MASK at all if > !CONFIG_TRANSPARENT_HUGEPAGE, so... Yes. Either that or define __HAVE_ARCH_PMDP_CLEAR_YOUNG_FLUSH without actually implementing the function to flush it away of the .text (is it perhaps flushed away at vmlinux link time?). That function never could be called by ARM. The BUG() is actually correct even in the original position, just now it triggers at build time because it doesn't know it can't be called. > > --- a/mm/pgtable-generic.c~thp-add-hpage_pmd_-definitions-for-config_transparent_hugepage-fix > +++ a/mm/pgtable-generic.c > @@ -70,10 +70,11 @@ int pmdp_clear_flush_young(struct vm_are > unsigned long address, pmd_t *pmdp) > { > int young; > -#ifndef CONFIG_TRANSPARENT_HUGEPAGE > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE > + VM_BUG_ON(address & ~HPAGE_PMD_MASK); > +#else > BUG(); > #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > - VM_BUG_ON(address & ~HPAGE_PMD_MASK); > young = pmdp_test_and_clear_young(vma, address, pmdp); > if (young) > flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE); > _ > -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
