Subject: Re: linux-next: build failure after merge of the akpm tree

From: Ingo Molnar <[email-masked]>
Date: Mon, 10 Dec 2012 11:43:27 +0100

* Stephen Rothwell <[email-masked]> wrote:

> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/migrate.c: In function 'migrate_misplaced_transhuge_page_put':
> mm/migrate.c:1666:2: error: incompatible type for argument 3 of 'update_mmu_cache_pmd'
> arch/x86/include/asm/pgtable.h:792:20: note: expected 'struct pmd_t *' but argument is of type 'pmd_t'
> 
> Caused by commit 7f7f03ce3820 ("mm, numa: Implement migrate-on-fault lazy
> NUMA strategy for regular and THP pages") from the tip tree and expose by
> commit "x86: convert update_mmu_cache() and update_mmu_cache_pmd() to
> functions" from the akpm tree.
> 
> I applied the following patch for today:
> 
> From: Stephen Rothwell <[email-masked]>
> Date: Mon, 10 Dec 2012 19:50:57 +1100
> Subject: [PATCH] mm,numa: fix update_mmu_cache_pmd call
> 
> Fixes this build error:
> 
> mm/migrate.c: In function 'migrate_misplaced_transhuge_page_put':
> mm/migrate.c:1666:2: error: incompatible type for argument 3 of 'update_mmu_cache_pmd'
> arch/x86/include/asm/pgtable.h:792:20: note: expected 'struct pmd_t *' but argument is of type 'pmd_t'
> 
> Signed-off-by: Stephen Rothwell <[email-masked]>
> ---
>  mm/migrate.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 5be98e5..964a8c1 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1663,7 +1663,7 @@ int migrate_misplaced_transhuge_page_put(struct mm_struct *mm,
>  	page_add_new_anon_rmap(new_page, vma, haddr);
>  
>  	set_pmd_at(mm, haddr, pmd, entry);
> -	update_mmu_cache_pmd(vma, address, entry);
> +	update_mmu_cache_pmd(vma, address, &entry);
>  	page_remove_rmap(page);
>  	/*
>  	 * Finish the charge transaction under the page table lock to

I think the real bug is not in the akpm but in the -tip tree: we 
copy & pasted a pre-existing buggy upstream place that also 
called update_mmu_cache_pmd() with a pmd value, not by address. 
akpm's patch fixed the original buggy place, but not our copy of 
it.

Practically this does not truly matter at the moment as only 
Sparc64 appears to be a real user of that function, and Sparc64 
does not turn on the NUMA feature (yet) - but nevertheless the 
change in akpm's tree which introduces correct typing for this 
method exposed the latent bug.

I'll pick up your fix.

Thanks,

	Ingo