linux-next: manual merge of the akpm tree with the arm64 tree

From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>
Subject: linux-next: manual merge of the akpm tree with the arm64 tree
Date: Mon, 22 Mar 2021 17:40:23 +1100	[thread overview]
Message-ID: <20210322174023.602a110b@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

Hi all,

Today's linux-next merge of the akpm tree got a conflict in:

  arch/arm64/mm/mmu.c

between commit:

  87143f404f33 ("arm64: mm: use XN table mapping attributes for the linear region")

from the arm64 tree and commit:

  0a2634348ef8 ("set_memory: allow querying whether set_direct_map_*() is actually enabled")

from the akpm 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/mmu.c
index 4c2305cca6d2,fb675069a3b7..000000000000

--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@@ -503,20 -490,11 +504,20 @@@ static void __init map_mem(pgd_t *pgdp
  	phys_addr_t kernel_start = __pa_symbol(_stext);
  	phys_addr_t kernel_end = __pa_symbol(__init_begin);
  	phys_addr_t start, end;
 -	int flags = 0;
 +	int flags = NO_EXEC_MAPPINGS;
  	u64 i;
  
 +	/*
 +	 * Setting hierarchical PXNTable attributes on table entries covering
 +	 * the linear region is only possible if it is guaranteed that no table
 +	 * entries at any level are being shared between the linear region and
 +	 * the vmalloc region. Check whether this is true for the PGD level, in
 +	 * which case it is guaranteed to be true for all other levels as well.
 +	 */
 +	BUILD_BUG_ON(pgd_index(direct_map_end - 1) == pgd_index(direct_map_end));
 +
- 	if (rodata_full || crash_mem_map || debug_pagealloc_enabled())
+ 	if (can_set_direct_map() || crash_mem_map)
 -		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 +		flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
  
  	/*
  	 * Take care not to create a writable alias for the
@@@ -1468,9 -1446,8 +1469,8 @@@ int arch_add_memory(int nid, u64 start
  	 * KFENCE requires linear map to be mapped at page granularity, so that
  	 * it is possible to protect/unprotect single pages in the KFENCE pool.
  	 */
- 	if (rodata_full || debug_pagealloc_enabled() ||
- 	    IS_ENABLED(CONFIG_KFENCE))
+ 	if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE))
 -		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 +		flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
  
  	__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
  			     size, params->pgprot, __pgd_pgtable_alloc,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
