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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <944718b60797f69628110db590dd0e6d350fc600.camel@wdc.com>
Date:   Wed, 7 Oct 2020 04:48:04 +0000
From:   Atish Patra <Atish.Patra@....com>
To:     "sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
        "palmer@...belt.com" <palmer@...belt.com>
CC:     "linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
        "paul@...an.com" <paul@...an.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "rppt@...ux.ibm.com" <rppt@...ux.ibm.com>
Subject: Re: linux-next: manual merge of the akpm-current tree with the risc-v
 tree

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.

-- 
Regards,
Atish