Re: linux-next: manual merge of the akpm-current tree with the risc-v tree

[Atish Patra <Atish.Patra@wdc.com>]

On Tue, 2020-10-06 at 21:48 -0700, Atish Patra wrote:
> On Tue, 2020-10-06 at 21:32 -0700, Palmer Dabbelt wrote:
> > On Tue, 06 Oct 2020 03:39:06 PDT (-0700), Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the akpm-current tree got a conflict
> > > in:
> > > 
> > >   arch/riscv/mm/init.c
> > > 
> > > between commit:
> > > 
> > >   c29c38fa2a8b ("RISC-V: Remove any memblock representing
> > > unusable
> > > memory area")
> > > 
> > > from the risc-v tree and commits:
> > > 
> > >   3520eeb79142 ("arch, drivers: replace for_each_membock() with
> > > for_each_mem_range()")
> > > 
> > > from the akpm-current tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > > This
> > > is now fixed as far as linux-next is concerned, but any non
> > > trivial
> > > conflicts should be mentioned to your upstream maintainer when
> > > your
> > > tree
> > > is submitted for merging.  You may also want to consider
> > > cooperating
> > > with the maintainer of the conflicting tree to minimise any
> > > particularly
> > > complex conflicts.
> > > 
> > > It also looks like there is a bug in that risc-v tree patch:
> > > mem_start
> > > is used uninitialised in setup_bootmem().
> > > -- 
> > > Cheers,
> > > Stephen Rothwell
> > > 
> > > diff --cc arch/riscv/mm/init.c
> > > index 812a48c91a95,bc72bb6b5fe0..000000000000
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> > > @@@ -152,20 -141,25 +152,20 @@@ disable
> > >   }
> > >   #endif /* CONFIG_BLK_DEV_INITRD */
> > >   
> > >  -static phys_addr_t dtb_early_pa __initdata;
> > >  -
> > >   void __init setup_bootmem(void)
> > >   {
> > > - 	struct memblock_region *reg;
> > > - 	phys_addr_t mem_start, end = 0;
> > >  -	phys_addr_t mem_size = 0;
> > >  -	phys_addr_t total_mem = 0;
> > > + 	phys_addr_t mem_start, start, end = 0;
> > >   	phys_addr_t vmlinux_end = __pa_symbol(&_end);
> > >   	phys_addr_t vmlinux_start = __pa_symbol(&_start);
> > > + 	u64 i;
> > >   
> > >   	/* Find the memory region containing the kernel */
> > > - 	for_each_memblock(memory, reg) {
> > > - 		end = reg->base + reg->size;
> > > + 	for_each_mem_range(i, &start, &end) {
> > > + 		phys_addr_t size = end - start;
> > >  -		if (!total_mem)
> > >  +		if (!mem_start)
> > > - 			mem_start = reg->base;
> > > - 		if (reg->base <= vmlinux_start && vmlinux_end
> > > <= end)
> > > - 			BUG_ON(reg->size == 0);
> > > + 			mem_start = start;
> > > + 		if (start <= vmlinux_start && vmlinux_end <=
> > > end)
> > > + 			BUG_ON(size == 0);
> > >  -		total_mem = total_mem + size;
> > >   	}
> > >   
> > >   	/*
> > > @@@ -542,18 -455,11 +533,18 @@@ static void __init
> > > setup_vm_final(void
> > >   {
> > >   	uintptr_t va, map_size;
> > >   	phys_addr_t pa, start, end;
> > > - 	struct memblock_region *reg;
> > > + 	u64 i;
> > >   
> > >  -	/* Set mmu_enabled flag */
> > >  -	mmu_enabled = true;
> > >  -
> > >  +	/**
> > >  +	 * MMU is enabled at this point. But page table setup
> > > is not
> > > complete yet.
> > >  +	 * fixmap page table alloc functions should be used at
> > > this
> > > point
> > >  +	 */
> > >  +	pt_ops.alloc_pte = alloc_pte_fixmap;
> > >  +	pt_ops.get_pte_virt = get_pte_virt_fixmap;
> > >  +#ifndef __PAGETABLE_PMD_FOLDED
> > >  +	pt_ops.alloc_pmd = alloc_pmd_fixmap;
> > >  +	pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
> > >  +#endif
> > >   	/* Setup swapper PGD for fixmap */
> > >   	create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
> > >   			   __pa_symbol(fixmap_pgd_next),
> > 
> > Thanks for pointing this out.  Given that this is the tip of my
> > for-
> > next I'm
> > just going to drop it, we'll sort out the bug and the conflict.
> 
> Thanks. I will rebase on top of next after fixing the bug and resend.
> 

Done. I have rebased the memblock patch(c29c38fa2a8b) and sent it to
the mailing list.

Some of the other conflicts are due to the patches in UEFI series. As
the series is going through multiple shared tree, I am not sure what is
the best course of action.

I also noticed that linux-next/master has an older version of UEFI
patches while for-next in riscv tree has the latest version. 

Please let me know if I need to resend the UEFI series.

-- 
Regards,
Atish