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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 12, 2022 at 07:13:18PM +0800, Baolin Wang wrote:
> On 5/12/2022 7:07 PM, Catalin Marinas wrote:
> > On Thu, May 12, 2022 at 07:38:55PM +1000, Stephen Rothwell wrote:
> > > After merging the mm tree, today's linux-next build (arm64 defconfig)
> > > failed like this:
> > > 
> > > arch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_clear_flush':
> > > arch/arm64/mm/hugetlbpage.c:493:16: error: implicit declaration of function 'get_clear_flush'; did you mean 'ptep_clear_flush'? [-Werror=implicit-function-declaration]
> > >    493 |         return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > >        |                ^~~~~~~~~~~~~~~
> > >        |                ptep_clear_flush
> > > arch/arm64/mm/hugetlbpage.c:493:16: error: incompatible types when returning type 'int' but 'pte_t' was expected
> > >    493 |         return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > >        |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > arch/arm64/mm/hugetlbpage.c:494:1: error: control reaches end of non-void function [-Werror=return-type]
> > >    494 | }
> > >        | ^
> > > 
> > > Caused by commit
> > > 
> > >    00df1f1a133b ("mm: change huge_ptep_clear_flush() to return the original pte")
> > > 
> > > interacting with commit
> > > 
> > >    fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
> > > 
> > > I have applied the following merg fix patch for today.
> > > 
> > > From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
> > > Date: Thu, 12 May 2022 19:33:11 +1000
> > > Subject: [PATCH] fixup for "mm: change huge_ptep_clear_flush() to return the original pte"
> > > 
> > > It interacts with commit
> > > 
> > >    fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
> > > 
> > > from the arm64 tree
> > > 
> > > Signed-off-by: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
> > > ---
> > >   arch/arm64/mm/hugetlbpage.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > > index 5bdf913dedc7..30f5b76aabe9 100644
> > > --- a/arch/arm64/mm/hugetlbpage.c
> > > +++ b/arch/arm64/mm/hugetlbpage.c
> > > @@ -490,7 +490,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> > >   		return ptep_clear_flush(vma, addr, ptep);
> > >   	ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> > > -	return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > > +	return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > >   }
> > 
> > Note that after the arm64 commit, get_clear_contig() no longer flushes
> > the TLB. So maybe something like:
> > 
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index 30f5b76aabe9..9a999550df8e 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -485,12 +485,15 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> >   {
> >   	size_t pgsize;
> >   	int ncontig;
> > +	pte_t orig_pte;
> > 
> >   	if (!pte_cont(READ_ONCE(*ptep)))
> >   		return ptep_clear_flush(vma, addr, ptep);
> > 
> >   	ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> > -	return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > +	orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > +	flush_tlb_range(vma, addr, addr + pgsize * ncontig);
> > +	return orig_pte;
> >   }
> 
> Yes, after checking this fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from
> get_clear_flush()"), I also realized it will miss TLB flush.
> 
> So I am not sure I need send a incremental patch to fix this issue? Or
> resend my patch set [1] with rebasing on the arm64 changes?
> 
> Catalin and Andrew, how do you think? Thanks.

Andrew folding the diff in is fine by me. I presume the mm patches are
applied on top of the rest of linux-next (and the arm64 commits).

-- 
Catalin



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux