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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/mm/mmu.c

between commit:

  bbd6ec605c0f ("arm64/mm: Enable memory hot remove")

from the arm64 tree and patch:

  37be0f08b1cc ("arm64/mm: implement unmap_hotplug_p4d_range")

from the akpm tree.

I fixed it up (I just dropped the latter (and its followup fix) for today)
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

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

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

[Catalin Marinas]

On Thu, Mar 05, 2020 at 04:50:46PM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   arch/arm64/mm/mmu.c
> 
> between commit:
> 
>   bbd6ec605c0f ("arm64/mm: Enable memory hot remove")
> 
> from the arm64 tree and patch:
> 
>   37be0f08b1cc ("arm64/mm: implement unmap_hotplug_p4d_range")
> 
> from the akpm tree.
> 
> I fixed it up (I just dropped the latter (and its followup fix) for today)

Thanks Stephen. Anshuman integrated those fixes in his memory hotremove
series.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/include/asm/page.h

between commits:

  92638b4e1b47 ("mm: arch: remove indirection level in alloc_zeroed_user_highpage_movable()")
  7a3b83537188 ("kasan: use separate (un)poison implementation for integrated init")
  013bb59dbb7c ("arm64: mte: handle tags zeroing at page allocation time")
  c275c5c6d50a ("kasan: disable freed user page poisoning with HW tags")

from the arm64 tree and (more or less) duplicated patches in the akpm tree.

I fixed it up (I dropped the patches form the akpm tree) 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

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

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

[Will Deacon]

On Mon, Jun 07, 2021 at 07:25:13PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/arm64/include/asm/page.h
> 
> between commits:
> 
>   92638b4e1b47 ("mm: arch: remove indirection level in alloc_zeroed_user_highpage_movable()")
>   7a3b83537188 ("kasan: use separate (un)poison implementation for integrated init")
>   013bb59dbb7c ("arm64: mte: handle tags zeroing at page allocation time")
>   c275c5c6d50a ("kasan: disable freed user page poisoning with HW tags")
> 
> from the arm64 tree and (more or less) duplicated patches in the akpm tree.
> 
> I fixed it up (I dropped the patches form the akpm tree) 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.

Thanks, Stephen.

Andrew -- you can drop your copies of these patches, as you suggested at:

https://lore.kernel.org/r/20210603200308.2a08d25db0dc92430a545b4c@linux-foundation.org

Will

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

[Stephen Rothwell]

[-- 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 --]

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

[Catalin Marinas]

On Mon, Mar 22, 2021 at 05:40:23PM +1100, Stephen Rothwell wrote:
> 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.

The resolution looks fine. Thanks Stephen.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  mm/filemap.c

between commit:

  f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() codepaths")

from the arm64 tree and patch:

  "secretmem: add memcg accounting"

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 mm/filemap.c
index 4d0b7a122850,4417fd15d633..000000000000
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@@ -42,7 -42,7 +42,8 @@@
  #include <linux/psi.h>
  #include <linux/ramfs.h>
  #include <linux/page_idle.h>
 +#include <asm/pgalloc.h>
+ #include <linux/secretmem.h>
  #include "internal.h"
  
  #define CREATE_TRACE_POINTS

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/mte.c

between commit:

  e710c29e0177 ("arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere")

from the arm64 tree and commit:

  44a7127eb3a4 ("arm64: mte: add in-kernel MTE helpers")

from the akpm tree.

I fixed it up (the former just removed some of the context for what the
latter added) 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

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

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

[Stephen Rothwell]

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

Hi all,

On Mon, 30 Nov 2020 18:28:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   arch/arm64/kernel/mte.c
> 
> between commit:
> 
>   e710c29e0177 ("arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere")
> 
> from the arm64 tree and commit:
> 
>   44a7127eb3a4 ("arm64: mte: add in-kernel MTE helpers")
> 
> from the akpm tree.
> 
> I fixed it up (the former just removed some of the context for what the
> latter added) 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.

A couple of the following patches in the akpm tree also conflicted with
the arm64 tree.

-- 
Cheers,
Stephen Rothwell

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

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

[Catalin Marinas]

On Mon, Nov 30, 2020 at 06:48:35PM +1100, Stephen Rothwell wrote:
> On Mon, 30 Nov 2020 18:28:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Today's linux-next merge of the akpm tree got a conflict in:
> > 
> >   arch/arm64/kernel/mte.c
> > 
> > between commit:
> > 
> >   e710c29e0177 ("arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere")
> > 
> > from the arm64 tree and commit:
> > 
> >   44a7127eb3a4 ("arm64: mte: add in-kernel MTE helpers")
> > 
> > from the akpm tree.
> > 
> > I fixed it up (the former just removed some of the context for what the
> > latter added) 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.
> 
> A couple of the following patches in the akpm tree also conflicted with
> the arm64 tree.

Thanks Stephen. While the conflicts are not too bad, the variable
renaming (e.g. gcr_incl -> gcr_excl) makes them look pretty messy. I'll
drop commit e710c29e0177 and the subsequent one from the arm64 tree and
either merge them via akpm or defer to 5.12.

-- 
Catalin

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/mm/proc.S

between commit:

  49b3cf035edc ("kasan: arm64: set TCR_EL1.TBID1 when enabled")

from the arm64 tree and commit:

  68cd215d6529 ("arm64: kasan: allow enabling in-kernel MTE")

from the akpm tree.

I fixed it up (I think, 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/proc.S
index a0831bf8a018,0d85e6df42bc..000000000000
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@@ -40,9 -40,15 +40,15 @@@
  #define TCR_CACHE_FLAGS	TCR_IRGN_WBWA | TCR_ORGN_WBWA
  
  #ifdef CONFIG_KASAN_SW_TAGS
- #define TCR_KASAN_FLAGS TCR_TBI1 | TCR_TBID1
 -#define TCR_KASAN_SW_FLAGS TCR_TBI1
++#define TCR_KASAN_SW_FLAGS TCR_TBI1 | TCR_TBID1
  #else
- #define TCR_KASAN_FLAGS 0
+ #define TCR_KASAN_SW_FLAGS 0
+ #endif
+ 
+ #ifdef CONFIG_KASAN_HW_TAGS
 -#define TCR_KASAN_HW_FLAGS SYS_TCR_EL1_TCMA1 | TCR_TBI1
++#define TCR_KASAN_HW_FLAGS SYS_TCR_EL1_TCMA1 | TCR_TBI1 | TCR_TBID1
+ #else
+ #define TCR_KASAN_HW_FLAGS 0
  #endif
  
  /*

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

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

[Peter Collingbourne]

On Wed, Nov 25, 2020 at 11:06 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
>   arch/arm64/mm/proc.S
>
> between commit:
>
>   49b3cf035edc ("kasan: arm64: set TCR_EL1.TBID1 when enabled")
>
> from the arm64 tree and commit:
>
>   68cd215d6529 ("arm64: kasan: allow enabling in-kernel MTE")
>
> from the akpm tree.
>
> I fixed it up (I think, 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/proc.S
> index a0831bf8a018,0d85e6df42bc..000000000000
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@@ -40,9 -40,15 +40,15 @@@
>   #define TCR_CACHE_FLAGS       TCR_IRGN_WBWA | TCR_ORGN_WBWA
>
>   #ifdef CONFIG_KASAN_SW_TAGS
> - #define TCR_KASAN_FLAGS TCR_TBI1 | TCR_TBID1
>  -#define TCR_KASAN_SW_FLAGS TCR_TBI1
> ++#define TCR_KASAN_SW_FLAGS TCR_TBI1 | TCR_TBID1
>   #else
> - #define TCR_KASAN_FLAGS 0
> + #define TCR_KASAN_SW_FLAGS 0
> + #endif
> +
> + #ifdef CONFIG_KASAN_HW_TAGS
>  -#define TCR_KASAN_HW_FLAGS SYS_TCR_EL1_TCMA1 | TCR_TBI1
> ++#define TCR_KASAN_HW_FLAGS SYS_TCR_EL1_TCMA1 | TCR_TBI1 | TCR_TBID1
> + #else
> + #define TCR_KASAN_HW_FLAGS 0
>   #endif
>
>   /*

Thanks Stephen, that resolution looks correct to me.

Peter

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/Kconfig

between commit:

  983460233659 ("arm64: Kconfig: select HAVE_FUTEX_CMPXCHG")

from the arm64 tree and commit:

  2a6e68c2d781 ("asm-generic/tlb: rename HAVE_RCU_TABLE_FREE")

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/Kconfig
index 21de6ffc3652,c050d2393610..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -164,8 -164,7 +164,8 @@@ config ARM6
  	select HAVE_PERF_USER_STACK_DUMP
  	select HAVE_REGS_AND_STACK_ACCESS_API
  	select HAVE_FUNCTION_ARG_ACCESS_API
 +	select HAVE_FUTEX_CMPXCHG if FUTEX
- 	select HAVE_RCU_TABLE_FREE
+ 	select MMU_GATHER_RCU_TABLE_FREE
  	select HAVE_RSEQ
  	select HAVE_STACKPROTECTOR
  	select HAVE_SYSCALL_TRACEPOINTS

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

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

[Stephen Rothwell]

Hi Andrew,

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

  arch/arm64/include/asm/cacheflush.h

between commit:

  9b0aa14e3155 ("arm64: mm: add set_memory_valid()")

from the arm64 tree and patch:

  "treewide: move set_memory_* functions away from cacheflush.h"

from the akpm tree.

I fixed it up (see below - not ideal ...) 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/include/asm/cacheflush.h
index 728f933cef8c,7db6962fc4b4..000000000000
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@@ -150,10 -151,4 +151,6 @@@ static inline void flush_cache_vunmap(u
  {
  }
  
- int set_memory_ro(unsigned long addr, int numpages);
- int set_memory_rw(unsigned long addr, int numpages);
- int set_memory_x(unsigned long addr, int numpages);
- int set_memory_nx(unsigned long addr, int numpages);
 +int set_memory_valid(unsigned long addr, unsigned long size, int enable);
 +
  #endif

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

[Catalin Marinas]

Hi Stephen,

On Fri, Apr 07, 2017 at 05:41:20PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm tree got a conflict in:
> 
>   arch/arm64/include/asm/cacheflush.h
> 
> between commit:
> 
>   9b0aa14e3155 ("arm64: mm: add set_memory_valid()")
> 
> from the arm64 tree and patch:
> 
>   "treewide: move set_memory_* functions away from cacheflush.h"
> 
> from the akpm tree.
> 
> I fixed it up (see below - not ideal ...) and can carry the fix as
> necessary.

Thanks for fixing this up. Not ideal, indeed, but I can push a clean-up
patch after -rc1 to move set_memory_valid() to an arm64-specific
set_memory.h (which would include asm-generic/set_memory.h). Given that
my for-next branch is based on 4.11-rc3, I can't do this now without
risking breaking other things.

-- 
Catalin

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

[Stephen Rothwell]

Hi Catalin,

On Fri, 7 Apr 2017 09:48:35 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Thanks for fixing this up. Not ideal, indeed, but I can push a clean-up
> patch after -rc1 to move set_memory_valid() to an arm64-specific
> set_memory.h (which would include asm-generic/set_memory.h). Given that
> my for-next branch is based on 4.11-rc3, I can't do this now without
> risking breaking other things.

Actually, I suspect that the patch in Andrew's series will be updated
to do that.  This part of Andrew's patch series is applied on top of
all the other linux-next trees and is sent to Linus fairly late in the
merge window.
-- 
Cheers,
Stephen Rothwell