Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2021-04-13  8:59 Stephen Rothwell
  2021-04-13  9:14 ` Catalin Marinas
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2021-04-13  8:59 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Andrey Konovalov, Andrey Konovalov, Linux Kernel Mailing List,
	Linux Next Mailing List, Vincenzo Frascino


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

Hi all,

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

  lib/test_kasan.c

between commits:

  2603f8a78dfb ("kasan: Add KASAN mode kernel parameter")
  e80a76aa1a91 ("kasan, arm64: tests supports for HW_TAGS async mode")

from the arm64 tree and commit:

  c616ba7e0d63 ("kasan: detect false-positives in tests")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc lib/test_kasan.c
index 785e724ce0d8,bf9225002a7e..000000000000
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@@ -78,33 -83,30 +83,35 @@@ static void kasan_test_exit(struct kuni
   * fields, it can reorder or optimize away the accesses to those fields.
   * Use READ/WRITE_ONCE() for the accesses and compiler barriers around the
   * expression to prevent that.
+  *
+  * In between KUNIT_EXPECT_KASAN_FAIL checks, fail_data.report_found is kept as
+  * false. This allows detecting KASAN reports that happen outside of the checks
+  * by asserting !fail_data.report_found at the start of KUNIT_EXPECT_KASAN_FAIL
+  * and in kasan_test_exit.
   */
- #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do {		\
- 	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&			\
- 	    !kasan_async_mode_enabled())			\
- 		migrate_disable();				\
- 	WRITE_ONCE(fail_data.report_expected, true);		\
- 	WRITE_ONCE(fail_data.report_found, false);		\
- 	kunit_add_named_resource(test,				\
- 				NULL,				\
- 				NULL,				\
- 				&resource,			\
- 				"kasan_data", &fail_data);	\
- 	barrier();						\
- 	expression;						\
- 	barrier();						\
- 	if (kasan_async_mode_enabled())				\
- 		kasan_force_async_fault();			\
- 	barrier();						\
- 	KUNIT_EXPECT_EQ(test,					\
- 			READ_ONCE(fail_data.report_expected),	\
- 			READ_ONCE(fail_data.report_found));	\
- 	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&			\
- 	    !kasan_async_mode_enabled()) {			\
- 		if (READ_ONCE(fail_data.report_found))		\
- 			kasan_enable_tagging_sync();		\
- 		migrate_enable();				\
- 	}							\
+ #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do {			\
 -	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS))				\
++	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&				\
++	    !kasan_async_mode_enabled())				\
+ 		migrate_disable();					\
+ 	KUNIT_EXPECT_FALSE(test, READ_ONCE(fail_data.report_found));	\
+ 	WRITE_ONCE(fail_data.report_expected, true);			\
+ 	barrier();							\
+ 	expression;							\
+ 	barrier();							\
++	if (kasan_async_mode_enabled())					\
++		kasan_force_async_fault();				\
++	barrier();							\
+ 	KUNIT_EXPECT_EQ(test,						\
+ 			READ_ONCE(fail_data.report_expected),		\
+ 			READ_ONCE(fail_data.report_found));		\
 -	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS)) {				\
++	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&				\
++	    !kasan_async_mode_enabled()) {				\
+ 		if (READ_ONCE(fail_data.report_found))			\
 -			kasan_enable_tagging();				\
++			kasan_enable_tagging_sync();			\
+ 		migrate_enable();					\
+ 	}								\
+ 	WRITE_ONCE(fail_data.report_found, false);			\
+ 	WRITE_ONCE(fail_data.report_expected, false);			\
  } while (0)
  
  #define KASAN_TEST_NEEDS_CONFIG_ON(test, config) do {			\

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2021-04-13  8:59 linux-next: manual merge of the akpm-current tree with the arm64 tree Stephen Rothwell
@ 2021-04-13  9:14 ` Catalin Marinas
  0 siblings, 0 replies; 29+ messages in thread
From: Catalin Marinas @ 2021-04-13  9:14 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Will Deacon, Andrey Konovalov, Andrey Konovalov,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Vincenzo Frascino

On Tue, Apr 13, 2021 at 06:59:36PM +1000, Stephen Rothwell wrote:
> diff --cc lib/test_kasan.c
> index 785e724ce0d8,bf9225002a7e..000000000000
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@@ -78,33 -83,30 +83,35 @@@ static void kasan_test_exit(struct kuni
>    * fields, it can reorder or optimize away the accesses to those fields.
>    * Use READ/WRITE_ONCE() for the accesses and compiler barriers around the
>    * expression to prevent that.
> +  *
> +  * In between KUNIT_EXPECT_KASAN_FAIL checks, fail_data.report_found is kept as
> +  * false. This allows detecting KASAN reports that happen outside of the checks
> +  * by asserting !fail_data.report_found at the start of KUNIT_EXPECT_KASAN_FAIL
> +  * and in kasan_test_exit.
>    */
> - #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do {		\
> - 	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&			\
> - 	    !kasan_async_mode_enabled())			\
> - 		migrate_disable();				\
> - 	WRITE_ONCE(fail_data.report_expected, true);		\
> - 	WRITE_ONCE(fail_data.report_found, false);		\
> - 	kunit_add_named_resource(test,				\
> - 				NULL,				\
> - 				NULL,				\
> - 				&resource,			\
> - 				"kasan_data", &fail_data);	\
> - 	barrier();						\
> - 	expression;						\
> - 	barrier();						\
> - 	if (kasan_async_mode_enabled())				\
> - 		kasan_force_async_fault();			\
> - 	barrier();						\
> - 	KUNIT_EXPECT_EQ(test,					\
> - 			READ_ONCE(fail_data.report_expected),	\
> - 			READ_ONCE(fail_data.report_found));	\
> - 	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&			\
> - 	    !kasan_async_mode_enabled()) {			\
> - 		if (READ_ONCE(fail_data.report_found))		\
> - 			kasan_enable_tagging_sync();		\
> - 		migrate_enable();				\
> - 	}							\
> + #define KUNIT_EXPECT_KASAN_FAIL(test, expression) do {			\
>  -	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS))				\
> ++	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&				\
> ++	    !kasan_async_mode_enabled())				\
> + 		migrate_disable();					\
> + 	KUNIT_EXPECT_FALSE(test, READ_ONCE(fail_data.report_found));	\
> + 	WRITE_ONCE(fail_data.report_expected, true);			\
> + 	barrier();							\
> + 	expression;							\
> + 	barrier();							\
> ++	if (kasan_async_mode_enabled())					\
> ++		kasan_force_async_fault();				\
> ++	barrier();							\
> + 	KUNIT_EXPECT_EQ(test,						\
> + 			READ_ONCE(fail_data.report_expected),		\
> + 			READ_ONCE(fail_data.report_found));		\
>  -	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS)) {				\
> ++	if (IS_ENABLED(CONFIG_KASAN_HW_TAGS) &&				\
> ++	    !kasan_async_mode_enabled()) {				\
> + 		if (READ_ONCE(fail_data.report_found))			\
>  -			kasan_enable_tagging();				\
> ++			kasan_enable_tagging_sync();			\
> + 		migrate_enable();					\
> + 	}								\
> + 	WRITE_ONCE(fail_data.report_found, false);			\
> + 	WRITE_ONCE(fail_data.report_expected, false);			\
>   } while (0)
>   
>   #define KASAN_TEST_NEEDS_CONFIG_ON(test, config) do {			\

Thanks Stephen. The resolution looks correct.

Andrew, if you'd rather I dropped the MTE async mode support from the
arm64 tree please let me know. Thanks.

https://lore.kernel.org/r/20210315132019.33202-1-vincenzo.frascino@arm.com/

-- 
Catalin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2020-12-03  8:06 Stephen Rothwell
@ 2020-12-03 11:16 ` Catalin Marinas
  0 siblings, 0 replies; 29+ messages in thread
From: Catalin Marinas @ 2020-12-03 11:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Will Deacon, Andrey Konovalov,
	Linux Kernel Mailing List, Linux Next Mailing List, Mark Rutland,
	Vincenzo Frascino

On Thu, Dec 03, 2020 at 07:06:01PM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/include/asm/uaccess.h
> index d841a560fae7,abb31aa1f8ca..000000000000
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@@ -186,64 -159,20 +159,43 @@@ static inline void __uaccess_enable_hw_
>   			CONFIG_ARM64_PAN));
>   }
>   
> - #define __uaccess_disable(alt)						\
> - do {									\
> - 	if (!uaccess_ttbr0_disable())					\
> - 		asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), alt,		\
> - 				CONFIG_ARM64_PAN));			\
> - } while (0)
> - 
> - #define __uaccess_enable(alt)						\
> - do {									\
> - 	if (!uaccess_ttbr0_enable())					\
> - 		asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt,		\
> - 				CONFIG_ARM64_PAN));			\
> - } while (0)
> - 
>  +/*
>  + * The Tag Check Flag (TCF) mode for MTE is per EL, hence TCF0
>  + * affects EL0 and TCF affects EL1 irrespective of which TTBR is
>  + * used.
>  + * The kernel accesses TTBR0 usually with LDTR/STTR instructions
>  + * when UAO is available, so these would act as EL0 accesses using
>  + * TCF0.
>  + * However futex.h code uses exclusives which would be executed as
>  + * EL1, this can potentially cause a tag check fault even if the
>  + * user disables TCF0.
>  + *
>  + * To address the problem we set the PSTATE.TCO bit in uaccess_enable()
>  + * and reset it in uaccess_disable().
>  + *
>  + * The Tag check override (TCO) bit disables temporarily the tag checking
>  + * preventing the issue.
>  + */
> - static inline void uaccess_disable(void)
> + static inline void uaccess_disable_privileged(void)
>   {
>  +	asm volatile(ALTERNATIVE("nop", SET_PSTATE_TCO(0),
>  +				 ARM64_MTE, CONFIG_KASAN_HW_TAGS));
>  +
> - 	__uaccess_disable(ARM64_HAS_PAN);
> + 	if (uaccess_ttbr0_disable())
> + 		return;
> + 
> + 	__uaccess_enable_hw_pan();
>   }
>   
> - static inline void uaccess_enable(void)
> + static inline void uaccess_enable_privileged(void)
>   {
>  +	asm volatile(ALTERNATIVE("nop", SET_PSTATE_TCO(1),
>  +				 ARM64_MTE, CONFIG_KASAN_HW_TAGS));
>  +
> - 	__uaccess_enable(ARM64_HAS_PAN);
> - }
> - 
> - /*
> -  * These functions are no-ops when UAO is present.
> -  */
> - static inline void uaccess_disable_not_uao(void)
> - {
> - 	__uaccess_disable(ARM64_ALT_PAN_NOT_UAO);
> - }
> + 	if (uaccess_ttbr0_enable())
> + 		return;
>   
> - static inline void uaccess_enable_not_uao(void)
> - {
> - 	__uaccess_enable(ARM64_ALT_PAN_NOT_UAO);
> + 	__uaccess_disable_hw_pan();
>   }
>   
>   /*

Thanks Stephen, it looks fine. I may clean it up a bit with dedicated
functions for the asm statements but after -rc1.

-- 
Catalin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2020-12-03  8:06 Stephen Rothwell
  2020-12-03 11:16 ` Catalin Marinas
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2020-12-03  8:06 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Andrey Konovalov, Linux Kernel Mailing List,
	Linux Next Mailing List, Mark Rutland, Vincenzo Frascino


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

Hi all,

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

  arch/arm64/include/asm/uaccess.h

between commits:

  923e1e7d8223 ("arm64: uaccess: rename privileged uaccess routines")
  7cf283c7bd62 ("arm64: uaccess: remove redundant PAN toggling")

from the arm64 tree and commit:

  9bc0016cc21a ("arm64: mte: add in-kernel tag fault handler")

from the akpm-current tree.

I fixed it up (as specified by Catalin (thanks) 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/include/asm/uaccess.h
index d841a560fae7,abb31aa1f8ca..000000000000
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@@ -186,64 -159,20 +159,43 @@@ static inline void __uaccess_enable_hw_
  			CONFIG_ARM64_PAN));
  }
  
- #define __uaccess_disable(alt)						\
- do {									\
- 	if (!uaccess_ttbr0_disable())					\
- 		asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), alt,		\
- 				CONFIG_ARM64_PAN));			\
- } while (0)
- 
- #define __uaccess_enable(alt)						\
- do {									\
- 	if (!uaccess_ttbr0_enable())					\
- 		asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt,		\
- 				CONFIG_ARM64_PAN));			\
- } while (0)
- 
 +/*
 + * The Tag Check Flag (TCF) mode for MTE is per EL, hence TCF0
 + * affects EL0 and TCF affects EL1 irrespective of which TTBR is
 + * used.
 + * The kernel accesses TTBR0 usually with LDTR/STTR instructions
 + * when UAO is available, so these would act as EL0 accesses using
 + * TCF0.
 + * However futex.h code uses exclusives which would be executed as
 + * EL1, this can potentially cause a tag check fault even if the
 + * user disables TCF0.
 + *
 + * To address the problem we set the PSTATE.TCO bit in uaccess_enable()
 + * and reset it in uaccess_disable().
 + *
 + * The Tag check override (TCO) bit disables temporarily the tag checking
 + * preventing the issue.
 + */
- static inline void uaccess_disable(void)
+ static inline void uaccess_disable_privileged(void)
  {
 +	asm volatile(ALTERNATIVE("nop", SET_PSTATE_TCO(0),
 +				 ARM64_MTE, CONFIG_KASAN_HW_TAGS));
 +
- 	__uaccess_disable(ARM64_HAS_PAN);
+ 	if (uaccess_ttbr0_disable())
+ 		return;
+ 
+ 	__uaccess_enable_hw_pan();
  }
  
- static inline void uaccess_enable(void)
+ static inline void uaccess_enable_privileged(void)
  {
 +	asm volatile(ALTERNATIVE("nop", SET_PSTATE_TCO(1),
 +				 ARM64_MTE, CONFIG_KASAN_HW_TAGS));
 +
- 	__uaccess_enable(ARM64_HAS_PAN);
- }
- 
- /*
-  * These functions are no-ops when UAO is present.
-  */
- static inline void uaccess_disable_not_uao(void)
- {
- 	__uaccess_disable(ARM64_ALT_PAN_NOT_UAO);
- }
+ 	if (uaccess_ttbr0_enable())
+ 		return;
  
- static inline void uaccess_enable_not_uao(void)
- {
- 	__uaccess_enable(ARM64_ALT_PAN_NOT_UAO);
+ 	__uaccess_disable_hw_pan();
  }
  
  /*

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2020-09-21  8:03 Stephen Rothwell
  2020-09-21  8:12 ` Catalin Marinas
@ 2020-10-13  7:34 ` Stephen Rothwell
  1 sibling, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2020-10-13  7:34 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Catalin Marinas, Will Deacon, Mike Rapoport,
	Linux Next Mailing List, Linux Kernel Mailing List


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

Hi all,

On Mon, 21 Sep 2020 18:03:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/arm64/mm/mmu.c
> 
> between commit:
> 
>   0178dc761368 ("arm64: mte: Use Normal Tagged attributes for the linear map")
> 
> from the arm64 tree and commit:
> 
>   8e19cbb9528f ("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.
> 
> diff --cc arch/arm64/mm/mmu.c
> index 087a844b4d26,64211436629d..000000000000
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@@ -493,21 -483,10 +494,15 @@@ static void __init map_mem(pgd_t *pgdp
>   #endif
>   
>   	/* map all the memory banks */
> - 	for_each_memblock(memory, reg) {
> - 		phys_addr_t start = reg->base;
> - 		phys_addr_t end = start + reg->size;
> - 
> + 	for_each_mem_range(i, &start, &end) {
>   		if (start >= end)
>   			break;
> - 		if (memblock_is_nomap(reg))
> - 			continue;
> - 
>  -		__map_memblock(pgdp, start, end, PAGE_KERNEL, flags);
>  +		/*
>  +		 * The linear map must allow allocation tags reading/writing
>  +		 * if MTE is present. Otherwise, it has the same attributes as
>  +		 * PAGE_KERNEL.
>  +		 */
>  +		__map_memblock(pgdp, start, end, PAGE_KERNEL_TAGGED, flags);
>   	}
>   
>   	/*

This is now a conflict between the akpm-current tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2020-09-21  8:03 Stephen Rothwell
@ 2020-09-21  8:12 ` Catalin Marinas
  2020-10-13  7:34 ` Stephen Rothwell
  1 sibling, 0 replies; 29+ messages in thread
From: Catalin Marinas @ 2020-09-21  8:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Will Deacon, Mike Rapoport,
	Linux Next Mailing List, Linux Kernel Mailing List

On Mon, Sep 21, 2020 at 06:03:53PM +1000, Stephen Rothwell wrote:
> diff --cc arch/arm64/mm/mmu.c
> index 087a844b4d26,64211436629d..000000000000
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@@ -493,21 -483,10 +494,15 @@@ static void __init map_mem(pgd_t *pgdp
>   #endif
>   
>   	/* map all the memory banks */
> - 	for_each_memblock(memory, reg) {
> - 		phys_addr_t start = reg->base;
> - 		phys_addr_t end = start + reg->size;
> - 
> + 	for_each_mem_range(i, &start, &end) {
>   		if (start >= end)
>   			break;
> - 		if (memblock_is_nomap(reg))
> - 			continue;
> - 
>  -		__map_memblock(pgdp, start, end, PAGE_KERNEL, flags);
>  +		/*
>  +		 * The linear map must allow allocation tags reading/writing
>  +		 * if MTE is present. Otherwise, it has the same attributes as
>  +		 * PAGE_KERNEL.
>  +		 */
>  +		__map_memblock(pgdp, start, end, PAGE_KERNEL_TAGGED, flags);
>   	}

It looks fine. Thanks Stephen.

-- 
Catalin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2020-09-21  8:03 Stephen Rothwell
  2020-09-21  8:12 ` Catalin Marinas
  2020-10-13  7:34 ` Stephen Rothwell
  0 siblings, 2 replies; 29+ messages in thread
From: Stephen Rothwell @ 2020-09-21  8:03 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Mike Rapoport, Linux Next Mailing List, Linux Kernel Mailing List


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

Hi all,


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

  arch/arm64/mm/mmu.c

between commit:

  0178dc761368 ("arm64: mte: Use Normal Tagged attributes for the linear map")

from the arm64 tree and commit:

  8e19cbb9528f ("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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/mmu.c
index 087a844b4d26,64211436629d..000000000000
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@@ -493,21 -483,10 +494,15 @@@ static void __init map_mem(pgd_t *pgdp
  #endif
  
  	/* map all the memory banks */
- 	for_each_memblock(memory, reg) {
- 		phys_addr_t start = reg->base;
- 		phys_addr_t end = start + reg->size;
- 
+ 	for_each_mem_range(i, &start, &end) {
  		if (start >= end)
  			break;
- 		if (memblock_is_nomap(reg))
- 			continue;
- 
 -		__map_memblock(pgdp, start, end, PAGE_KERNEL, flags);
 +		/*
 +		 * The linear map must allow allocation tags reading/writing
 +		 * if MTE is present. Otherwise, it has the same attributes as
 +		 * PAGE_KERNEL.
 +		 */
 +		__map_memblock(pgdp, start, end, PAGE_KERNEL_TAGGED, flags);
  	}
  
  	/*

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2020-07-16  8:00 Stephen Rothwell
@ 2020-07-16  8:23 ` Will Deacon
  0 siblings, 0 replies; 29+ messages in thread
From: Will Deacon @ 2020-07-16  8:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Catalin Marinas, Linux Next Mailing List,
	Linux Kernel Mailing List, Anshuman Khandual, Barry Song

On Thu, Jul 16, 2020 at 06:00:12PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/arm64/mm/init.c
> 
> between commit:
> 
>   abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs")
> 
> from the arm64 tree and commit:
> 
>   10d44973d8ab ("mm/hugetlb: split hugetlb_cma in nodes with memory")
> 
> from the akpm-current tree.

[...]

> diff --cc arch/arm64/mm/init.c
> index f8c19c6c8e71,ee551d71c4dd..000000000000
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@@ -421,22 -421,21 +421,21 @@@ void __init bootmem_init(void
>   	arm64_numa_init();
>   
>   	/*
> - 	 * must be done after arm64_numa_init() which calls numa_init() to
> - 	 * initialize node_online_map that gets used in hugetlb_cma_reserve()
> - 	 * while allocating required CMA size across online nodes.
> + 	 * sparse_init() tries to allocate memory from memblock, so must be
> + 	 * done after the fixed reservations
>   	 */
> - #if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_CMA)
> - 	arm64_hugetlb_cma_reserve();
> - #endif
> + 	sparse_init();
> + 	zone_sizes_init(min, max);
>   
>   	/*
> - 	 * Sparsemem tries to allocate bootmem in memory_present(), so must be
> - 	 * done after the fixed reservations.
> + 	 * must be done after zone_sizes_init() which calls free_area_init()
> + 	 * that calls node_set_state() to initialize node_states[N_MEMORY]
> + 	 * because hugetlb_cma_reserve() will scan over nodes with N_MEMORY
> + 	 * state
>   	 */
> - 	memblocks_present();
> - 
> - 	sparse_init();
> - 	zone_sizes_init(min, max);
>  -#ifdef CONFIG_ARM64_4K_PAGES
>  -	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> ++#if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_CMA)
> ++	arm64_hugetlb_cma_reserve();
> + #endif

Thanks, looks good to me, although we might be in for a hairier conflict
if the discussion at [1] ends up with a patch for merging.

Will

[1] https://lore.kernel.org/r/359ea1d0-b1fd-d09f-d28a-a44655834277@oracle.com

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2020-07-16  8:00 Stephen Rothwell
  2020-07-16  8:23 ` Will Deacon
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2020-07-16  8:00 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Anshuman Khandual, Barry Song


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

Hi all,

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

  arch/arm64/mm/init.c

between commit:

  abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs")

from the arm64 tree and commit:

  10d44973d8ab ("mm/hugetlb: split hugetlb_cma in nodes with memory")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/init.c
index f8c19c6c8e71,ee551d71c4dd..000000000000
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@@ -421,22 -421,21 +421,21 @@@ void __init bootmem_init(void
  	arm64_numa_init();
  
  	/*
- 	 * must be done after arm64_numa_init() which calls numa_init() to
- 	 * initialize node_online_map that gets used in hugetlb_cma_reserve()
- 	 * while allocating required CMA size across online nodes.
+ 	 * sparse_init() tries to allocate memory from memblock, so must be
+ 	 * done after the fixed reservations
  	 */
- #if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_CMA)
- 	arm64_hugetlb_cma_reserve();
- #endif
+ 	sparse_init();
+ 	zone_sizes_init(min, max);
  
  	/*
- 	 * Sparsemem tries to allocate bootmem in memory_present(), so must be
- 	 * done after the fixed reservations.
+ 	 * must be done after zone_sizes_init() which calls free_area_init()
+ 	 * that calls node_set_state() to initialize node_states[N_MEMORY]
+ 	 * because hugetlb_cma_reserve() will scan over nodes with N_MEMORY
+ 	 * state
  	 */
- 	memblocks_present();
- 
- 	sparse_init();
- 	zone_sizes_init(min, max);
 -#ifdef CONFIG_ARM64_4K_PAGES
 -	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
++#if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_CMA)
++	arm64_hugetlb_cma_reserve();
+ #endif
  
  	memblock_dump_all();
  }

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2020-04-30  6:26 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2020-04-30  6:26 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Zong Li,
	Dave Martin, Mark Brown


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

Hi all,

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

  arch/arm64/Kconfig

between commit:

  ab7876a98a21 ("arm64: elf: Enable BTI at exec based on ELF program properties")

from the arm64 tree and commit:

  03a534dd08f3 ("arm64: mm: use ARCH_HAS_DEBUG_WX instead of arch defined")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/Kconfig
index b5d91fab64b0,787b7202676b..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -9,8 -9,9 +9,10 @@@ config ARM6
  	select ACPI_MCFG if (ACPI && PCI)
  	select ACPI_SPCR_TABLE if ACPI
  	select ACPI_PPTT if ACPI
 +	select ARCH_BINFMT_ELF_STATE
+ 	select ARCH_HAS_DEBUG_WX
  	select ARCH_HAS_DEBUG_VIRTUAL
+ 	select ARCH_HAS_DEBUG_VM_PGTABLE
  	select ARCH_HAS_DEVMEM_IS_ALLOWED
  	select ARCH_HAS_DMA_PREP_COHERENT
  	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2020-04-29  6:53 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2020-04-29  6:53 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Gavin Shan,
	Mike Rapoport


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

Hi all,

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

  arch/arm64/include/asm/pgtable.h

between commit:

  68ecabd0e680 ("arm64/mm: Use phys_to_page() to access pgtable memory")

from the arm64 tree and commit:

  22998131ab33 ("arm64: add support for folded p4d page tables")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/pgtable.h
index 5caff09c6a3a,ef7145c3b96b..000000000000
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@@ -622,10 -632,10 +633,10 @@@ static inline phys_addr_t p4d_page_padd
  #define pud_offset(dir, addr)		((pud_t *)__va(pud_offset_phys((dir), (addr))))
  
  #define pud_set_fixmap(addr)		((pud_t *)set_fixmap_offset(FIX_PUD, addr))
- #define pud_set_fixmap_offset(pgd, addr)	pud_set_fixmap(pud_offset_phys(pgd, addr))
+ #define pud_set_fixmap_offset(p4d, addr)	pud_set_fixmap(pud_offset_phys(p4d, addr))
  #define pud_clear_fixmap()		clear_fixmap(FIX_PUD)
  
- #define pgd_page(pgd)			phys_to_page(__pgd_to_phys(pgd))
 -#define p4d_page(p4d)		pfn_to_page(__phys_to_pfn(__p4d_to_phys(p4d)))
++#define p4d_page(p4d)			phys_to_page(__p4d_to_phys(p4d))
  
  /* use ONLY for statically allocated translation tables */
  #define pud_offset_kimg(dir,addr)	((pud_t *)__phys_to_kimg(pud_offset_phys((dir), (addr))))

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2019-08-07  6:39 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2019-08-07  6:39 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mark Rutland,
	Alexandre Ghiti


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

Hi all,

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

  arch/arm64/include/asm/processor.h

between commit:

  b907b80d7ae7 ("arm64: remove pointless __KERNEL__ guards")

from the arm64 tree and commit:

  cd6ee3f76f64 ("arm64, mm: move generic mmap layout functions to mm")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/processor.h
index ec70762519df,65e2de00913f..000000000000
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@@ -280,8 -281,8 +280,6 @@@ static inline void spin_lock_prefetch(c
  		     "nop") : : "p" (ptr));
  }
  
- #define HAVE_ARCH_PICK_MMAP_LAYOUT
 -#endif
--
  extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
  extern void __init minsigstksz_setup(void);
  

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2018-12-13  6:01 Stephen Rothwell
@ 2018-12-13 11:12 ` Will Deacon
  0 siblings, 0 replies; 29+ messages in thread
From: Will Deacon @ 2018-12-13 11:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Catalin Marinas, Linux Next Mailing List,
	Linux Kernel Mailing List, Robin Murphy

On Thu, Dec 13, 2018 at 05:01:07PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/arm64/mm/mmu.c
> 
> between commit:
> 
>   4ab215061554 ("arm64: Add memory hotplug support")
> 
> from the arm64 tree and commit:
> 
>   232619fcc076 ("lib/ioremap: ensure break-before-make is used for huge p4d mappings")
> 
> 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm64/mm/mmu.c
> index da513a1facf4,cf9a26d3d7f5..000000000000
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@@ -1047,19 -1029,7 +1043,24 @@@ int pud_free_pmd_page(pud_t *pudp, unsi
>   	return 1;
>   }
>   
>  +#ifdef CONFIG_MEMORY_HOTPLUG
>  +int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
>  +		    bool want_memblock)
>  +{
>  +	int flags = 0;
>  +
>  +	if (rodata_full || debug_pagealloc_enabled())
>  +		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
>  +
>  +	__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
>  +			     size, PAGE_KERNEL, pgd_pgtable_alloc, flags);
>  +
>  +	return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
>  +			   altmap, want_memblock);
>  +}
>  +#endif
> ++
> + int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
> + {
> + 	return 0;	/* Don't attempt a block mapping */
> + }

Looks good to me, thanks.

Will

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2018-12-13  6:01 Stephen Rothwell
  2018-12-13 11:12 ` Will Deacon
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2018-12-13  6:01 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Robin Murphy


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

Hi all,

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

  arch/arm64/mm/mmu.c

between commit:

  4ab215061554 ("arm64: Add memory hotplug support")

from the arm64 tree and commit:

  232619fcc076 ("lib/ioremap: ensure break-before-make is used for huge p4d mappings")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/mmu.c
index da513a1facf4,cf9a26d3d7f5..000000000000
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@@ -1047,19 -1029,7 +1043,24 @@@ int pud_free_pmd_page(pud_t *pudp, unsi
  	return 1;
  }
  
 +#ifdef CONFIG_MEMORY_HOTPLUG
 +int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
 +		    bool want_memblock)
 +{
 +	int flags = 0;
 +
 +	if (rodata_full || debug_pagealloc_enabled())
 +		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 +
 +	__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
 +			     size, PAGE_KERNEL, pgd_pgtable_alloc, flags);
 +
 +	return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
 +			   altmap, want_memblock);
 +}
 +#endif
++
+ int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
+ {
+ 	return 0;	/* Don't attempt a block mapping */
+ }

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2018-12-11  6:12 ` linux-next: manual merge of the akpm-current tree with the arm64 tree Stephen Rothwell
@ 2018-12-11 10:39   ` Will Deacon
  0 siblings, 0 replies; 29+ messages in thread
From: Will Deacon @ 2018-12-11 10:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Catalin Marinas, Linux Next Mailing List,
	Linux Kernel Mailing List, Andrey Konovalov, Steve Capper

On Tue, Dec 11, 2018 at 05:12:30PM +1100, Stephen Rothwell wrote:
> On Tue, 11 Dec 2018 17:11:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> > 
> >   arch/arm64/mm/proc.S
> > 
> > between commits:
> > 
> >   67e7fdfcc682 ("arm64: mm: introduce 52-bit userspace support")
> >   68d23da4373a ("rm64: Kconfig: Re-jig CONFIG options for 52-bit VA")
> > 
> > from the arm64 tree and commit:
> > 
> >   089dc516f651 ("kasan, arm64: enable top byte ignore for the kernel")
> > 
> > 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.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc arch/arm64/mm/proc.S
> > index e05b3ce1db6b,d861f208eeb1..73886a5f1f30
> > --- a/arch/arm64/mm/proc.S
> > +++ b/arch/arm64/mm/proc.S
> > @@@ -449,16 -451,8 +455,16 @@@ ENTRY(__cpu_setup
> >   	 */
> >   	ldr	x10, =TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \
> >   			TCR_TG_FLAGS | TCR_KASLR_FLAGS | TCR_ASID16 | \
> > - 			TCR_TBI0 | TCR_A1
> > + 			TCR_TBI0 | TCR_A1 | TCR_KASAN_FLAGS
> >  -	tcr_set_idmap_t0sz	x10, x9
> >  +
> >  +#ifdef CONFIG_ARM64_USER_VA_BITS_52
> >  +	ldr_l		x9, vabits_user
> >  +	sub		x9, xzr, x9
> >  +	add		x9, x9, #64
> >  +#else
> >  +	ldr_l		x9, idmap_t0sz
> >  +#endif
> >  +	tcr_set_t0sz	x10, x9
> >   
> >   	/*
> >   	 * Set the IPS bits in TCR_EL1.

This looks good to me. Thanks, Stephen.

Will

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2018-12-11  6:11 linux-next: manual merge of the akpm-current tree with the FIXME tree Stephen Rothwell
@ 2018-12-11  6:12 ` Stephen Rothwell
  2018-12-11 10:39   ` Will Deacon
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2018-12-11  6:12 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Andrey Konovalov, Steve Capper


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

Hi all,

[Sent to early with people missing ...]

On Tue, 11 Dec 2018 17:11:02 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/arm64/mm/proc.S
> 
> between commits:
> 
>   67e7fdfcc682 ("arm64: mm: introduce 52-bit userspace support")
>   68d23da4373a ("rm64: Kconfig: Re-jig CONFIG options for 52-bit VA")
> 
> from the arm64 tree and commit:
> 
>   089dc516f651 ("kasan, arm64: enable top byte ignore for the kernel")
> 
> 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm64/mm/proc.S
> index e05b3ce1db6b,d861f208eeb1..73886a5f1f30
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@@ -449,16 -451,8 +455,16 @@@ ENTRY(__cpu_setup
>   	 */
>   	ldr	x10, =TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \
>   			TCR_TG_FLAGS | TCR_KASLR_FLAGS | TCR_ASID16 | \
> - 			TCR_TBI0 | TCR_A1
> + 			TCR_TBI0 | TCR_A1 | TCR_KASAN_FLAGS
>  -	tcr_set_idmap_t0sz	x10, x9
>  +
>  +#ifdef CONFIG_ARM64_USER_VA_BITS_52
>  +	ldr_l		x9, vabits_user
>  +	sub		x9, xzr, x9
>  +	add		x9, x9, #64
>  +#else
>  +	ldr_l		x9, idmap_t0sz
>  +#endif
>  +	tcr_set_t0sz	x10, x9
>   
>   	/*
>   	 * Set the IPS bits in TCR_EL1.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2018-12-11  6:02 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2018-12-11  6:02 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Qian Cai,
	Andrey Konovalov


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

Hi all,

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

  arch/arm64/include/asm/memory.h

between commit:

  6e8830674ea7 ("arm64: kasan: Increase stack size for KASAN_EXTRA")

from the arm64 tree and commit:

  2a4689e7f69c ("kasan, arm64: adjust shadow size for tag-based mode")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/memory.h
index f771452d08c4,1235fa492307..000000000000
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@@ -77,19 -65,13 +68,18 @@@
  #define KERNEL_END        _end
  
  /*
-  * KASAN requires 1/8th of the kernel virtual address space for the shadow
-  * region. KASAN can bloat the stack significantly, so double the (minimum)
-  * stack size when KASAN is in use, and then double it again if KASAN_EXTRA is
-  * on.
+  * Generic and tag-based KASAN require 1/8th and 1/16th of the kernel virtual
+  * address space for the shadow region respectively. They can bloat the stack
 - * significantly, so double the (minimum) stack size when they are in use.
++ * significantly, so double the (minimum) stack size when they are in use,
++ * and then double it again if KASAN_EXTRA is on.
   */
  #ifdef CONFIG_KASAN
- #define KASAN_SHADOW_SCALE_SHIFT 3
  #define KASAN_SHADOW_SIZE	(UL(1) << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
 +#ifdef CONFIG_KASAN_EXTRA
 +#define KASAN_THREAD_SHIFT	2
 +#else
  #define KASAN_THREAD_SHIFT	1
 +#endif /* CONFIG_KASAN_EXTRA */
  #else
  #define KASAN_SHADOW_SIZE	(0)
  #define KASAN_THREAD_SHIFT	0

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2018-09-24  4:38 Stephen Rothwell
@ 2018-09-24  9:32 ` Catalin Marinas
  0 siblings, 0 replies; 29+ messages in thread
From: Catalin Marinas @ 2018-09-24  9:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Will Deacon, Linux-Next Mailing List,
	Linux Kernel Mailing List, Jia He, James Morse

Hi Stephen,

On Mon, Sep 24, 2018 at 02:38:53PM +1000, Stephen Rothwell wrote:
> diff --cc arch/arm64/Kconfig
> index da5e6f085561,f8a618a292f4..000000000000
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@@ -785,7 -786,8 +785,8 @@@ config ARCH_FLATMEM_ENABL
>   	def_bool !NUMA
>   
>   config HAVE_ARCH_PFN_VALID
>  -	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
>  +	def_bool y
> + 	select HAVE_MEMBLOCK_PFN_VALID

It looks fine. Thanks.

-- 
Catalin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2018-09-24  4:38 Stephen Rothwell
  2018-09-24  9:32 ` Catalin Marinas
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2018-09-24  4:38 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jia He, James Morse


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

Hi all,

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

  arch/arm64/Kconfig

between commit:

  8a695a587333 ("arm64: Kconfig: Remove ARCH_HAS_HOLES_MEMORYMODEL")

from the arm64 tree and commit:

  e1405baa7db1 ("arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/Kconfig
index da5e6f085561,f8a618a292f4..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -785,7 -786,8 +785,8 @@@ config ARCH_FLATMEM_ENABL
  	def_bool !NUMA
  
  config HAVE_ARCH_PFN_VALID
 -	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 +	def_bool y
+ 	select HAVE_MEMBLOCK_PFN_VALID
  
  config HW_PERF_EVENTS
  	def_bool y

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2018-07-27 10:55 Stephen Rothwell
@ 2018-08-16  0:11 ` Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2018-08-16  0:11 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Catalin Marinas, Will Deacon, Linux-Next Mailing List,
	Linux Kernel Mailing List, Laura Abbott, Ard Biesheuvel


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

Hi all,

On Fri, 27 Jul 2018 20:55:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   drivers/firmware/efi/libstub/Makefile
> 
> between commit:
> 
>   0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")
> 
> from the arm64 tree and commit:
> 
>   08cc64a7109b ("module: allow symbol exports to be disabled")
> 
> 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/firmware/efi/libstub/Makefile
> index 25dd2a14560d,0d0d3483241c..000000000000
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@@ -21,7 -21,7 +21,8 @@@ KBUILD_CFLAGS			:= $(cflags-y) -DDISABL
>   				   -D__NO_FORTIFY \
>   				   $(call cc-option,-ffreestanding) \
>   				   $(call cc-option,-fno-stack-protector) \
> - 				   $(DISABLE_STACKLEAK_PLUGIN)
> ++				   $(DISABLE_STACKLEAK_PLUGIN) \
> + 				   -D__DISABLE_EXPORTS
>   
>   GCOV_PROFILE			:= n
>   KASAN_SANITIZE			:= n

This is now a conflict between Linus' tree and the akpm-current tree.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2018-07-27 10:55 Stephen Rothwell
  2018-08-16  0:11 ` Stephen Rothwell
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2018-07-27 10:55 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas, Will Deacon
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Laura Abbott,
	Ard Biesheuvel


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

Hi Andrew,

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

  drivers/firmware/efi/libstub/Makefile

between commit:

  0b3e336601b8 ("arm64: Add support for STACKLEAK gcc plugin")

from the arm64 tree and commit:

  08cc64a7109b ("module: allow symbol exports to be disabled")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/Makefile
index 25dd2a14560d,0d0d3483241c..000000000000
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@@ -21,7 -21,7 +21,8 @@@ KBUILD_CFLAGS			:= $(cflags-y) -DDISABL
  				   -D__NO_FORTIFY \
  				   $(call cc-option,-ffreestanding) \
  				   $(call cc-option,-fno-stack-protector) \
- 				   $(DISABLE_STACKLEAK_PLUGIN)
++				   $(DISABLE_STACKLEAK_PLUGIN) \
+ 				   -D__DISABLE_EXPORTS
  
  GCOV_PROFILE			:= n
  KASAN_SANITIZE			:= n

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2017-11-06  5:33 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2017-11-06  5:33 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Jürg Billeter, Dave Martin, Will Deacon

Hi Andrew,

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

  include/uapi/linux/prctl.h

between commit:

  7582e22038a2 ("arm64/sve: Backend logic for setting the vector length")
  2d2123bc7c7f ("arm64/sve: Add prctl controls for userspace vector length management")

from the arm64 tree and commit:

  4391ebaac0d6 ("prctl: add PR_[GS]ET_PDEATHSIG_PROC")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/prctl.h
index af5f8c2df87a,5e7068e45126..000000000000
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@@ -198,13 -198,8 +198,17 @@@ struct prctl_mm_map 
  # define PR_CAP_AMBIENT_LOWER		3
  # define PR_CAP_AMBIENT_CLEAR_ALL	4
  
+ /* Process-based variant of PDEATHSIG */
+ #define PR_SET_PDEATHSIG_PROC		48
+ #define PR_GET_PDEATHSIG_PROC		49
+ 
 +/* arm64 Scalable Vector Extension controls */
 +/* Flag values must be kept in sync with ptrace NT_ARM_SVE interface */
 +#define PR_SVE_SET_VL			50	/* set task vector length */
 +# define PR_SVE_SET_VL_ONEXEC		(1 << 18) /* defer effect until exec */
 +#define PR_SVE_GET_VL			51	/* get task vector length */
 +/* Bits common to PR_SVE_SET_VL and PR_SVE_GET_VL */
 +# define PR_SVE_VL_LEN_MASK		0xffff
 +# define PR_SVE_VL_INHERIT		(1 << 17) /* inherit across exec */
 +
  #endif /* _LINUX_PRCTL_H */

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2016-09-27  6:03 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2016-09-27  6:03 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas
  Cc: linux-next, linux-kernel, Scott Wood, Will Deacon, Vineet Gupta

Hi Andrew,

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

  arch/arm/Kconfig

between commit:

  1d8f51d41fc7 ("arm/arm64: arch_timer: Use archdata to indicate vdso suitability")

from the arm64 tree and commit:

  7b4d24d8c01d ("atomic64: no need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/Kconfig
index 125657b602a4,2a50957c7bfb..000000000000
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -1,8 -1,6 +1,7 @@@
  config ARM
  	bool
  	default y
 +	select ARCH_CLOCKSOURCE_DATA
- 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
  	select ARCH_HAS_DEVMEM_IS_ALLOWED
  	select ARCH_HAS_ELF_RANDOMIZE
  	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2016-06-22  4:54 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2016-06-22  4:54 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas
  Cc: linux-next, linux-kernel, Jisheng Zhang, Krzysztof Kozlowski

Hi Andrew,

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

  arch/arm64/mm/dma-mapping.c

between commit:

  b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")

from the arm64 tree and commit:

  29af59a63ef1 ("arm64: dma-mapping: constify attrs passed to internal functions")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/mm/dma-mapping.c
index 46a4157adc17,0ef620a34c4e..000000000000
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@@ -30,9 -29,7 +30,9 @@@
  
  #include <asm/cacheflush.h>
  
 +static int swiotlb __read_mostly;
 +
- static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
+ static pgprot_t __get_dma_pgprot(const struct dma_attrs *attrs, pgprot_t prot,
  				 bool coherent)
  {
  	if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2015-12-16  5:01 Stephen Rothwell
@ 2015-12-16 10:14 ` Will Deacon
  0 siblings, 0 replies; 29+ messages in thread
From: Will Deacon @ 2015-12-16 10:14 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Catalin Marinas, linux-next, linux-kernel,
	Ard Biesheuvel, Yaowei Bai

On Wed, Dec 16, 2015 at 04:01:43PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   include/linux/memblock.h
> 
> between commit:
> 
>   bf3d3cc580f9 ("mm/memblock: add MEMBLOCK_NOMAP attribute to memblock memory table")
> 
> from the arm64 tree and commit:
> 
>   f7e2bc7d46e9 ("mm/memblock.c: memblock_is_memory()/reserved() can be boolean")
> 
> from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc include/linux/memblock.h
> index fec66f86eeff,359871f2fedd..000000000000
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@@ -325,10 -318,9 +325,10 @@@ phys_addr_t memblock_mem_size(unsigned 
>   phys_addr_t memblock_start_of_DRAM(void);
>   phys_addr_t memblock_end_of_DRAM(void);
>   void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> - int memblock_is_memory(phys_addr_t addr);
> + bool memblock_is_memory(phys_addr_t addr);
>  +int memblock_is_map_memory(phys_addr_t addr);
>   int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> - int memblock_is_reserved(phys_addr_t addr);
> + bool memblock_is_reserved(phys_addr_t addr);
>   bool memblock_is_region_reserved(phys_addr_t base, phys_addr_t size);

Thanks, Steven. I guess we should apply similar int->bool treatment to
memblock_is_map_memory and memblock_is_region_memory, but it's all
cosmetic really.

Will

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2015-12-16  5:01 Stephen Rothwell
  2015-12-16 10:14 ` Will Deacon
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2015-12-16  5:01 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas
  Cc: linux-next, linux-kernel, Ard Biesheuvel, Will Deacon, Yaowei Bai

Hi Andrew,

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

  include/linux/memblock.h

between commit:

  bf3d3cc580f9 ("mm/memblock: add MEMBLOCK_NOMAP attribute to memblock memory table")

from the arm64 tree and commit:

  f7e2bc7d46e9 ("mm/memblock.c: memblock_is_memory()/reserved() can be boolean")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/memblock.h
index fec66f86eeff,359871f2fedd..000000000000
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@@ -325,10 -318,9 +325,10 @@@ phys_addr_t memblock_mem_size(unsigned 
  phys_addr_t memblock_start_of_DRAM(void);
  phys_addr_t memblock_end_of_DRAM(void);
  void memblock_enforce_memory_limit(phys_addr_t memory_limit);
- int memblock_is_memory(phys_addr_t addr);
+ bool memblock_is_memory(phys_addr_t addr);
 +int memblock_is_map_memory(phys_addr_t addr);
  int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
- int memblock_is_reserved(phys_addr_t addr);
+ bool memblock_is_reserved(phys_addr_t addr);
  bool memblock_is_region_reserved(phys_addr_t base, phys_addr_t size);
  
  extern void __memblock_dump_all(void);

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the arm64 tree
  2014-09-23  7:23 Stephen Rothwell
@ 2014-09-23  8:36 ` Catalin Marinas
  0 siblings, 0 replies; 29+ messages in thread
From: Catalin Marinas @ 2014-09-23  8:36 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Laura Abbott

On Tue, Sep 23, 2014 at 08:23:39AM +0100, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm-current tree got a conflict in
> arch/arm64/mm/dma-mapping.c between commit 2189064795dc ("arm64:
> Implement set_arch_dma_coherent_ops() to replace bus notifiers") from
> the arm64 tree and commit 50a477611cc9 ("arm64: add atomic pool for
> non-coherent and CMA allocations") from the akpm-current tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

It looks fine. Thanks.

-- 
Catalin

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2014-09-23  7:23 Stephen Rothwell
  2014-09-23  8:36 ` Catalin Marinas
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Rothwell @ 2014-09-23  7:23 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas; +Cc: linux-next, linux-kernel, Laura Abbott


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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/arm64/mm/dma-mapping.c between commit 2189064795dc ("arm64:
Implement set_arch_dma_coherent_ops() to replace bus notifiers") from
the arm64 tree and commit 50a477611cc9 ("arm64: add atomic pool for
non-coherent and CMA allocations") from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/mm/dma-mapping.c
index d6ceb3df0047,90bb7b34d058..000000000000
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@@ -22,8 -22,12 +22,9 @@@
  #include <linux/slab.h>
  #include <linux/dma-mapping.h>
  #include <linux/dma-contiguous.h>
 -#include <linux/of.h>
 -#include <linux/platform_device.h>
  #include <linux/vmalloc.h>
  #include <linux/swiotlb.h>
 -#include <linux/amba/bus.h>
+ #include <linux/genalloc.h>
  
  #include <asm/cacheflush.h>
  
@@@ -305,8 -363,91 +360,69 @@@ struct dma_map_ops coherent_swiotlb_dma
  };
  EXPORT_SYMBOL(coherent_swiotlb_dma_ops);
  
 -static int dma_bus_notifier(struct notifier_block *nb,
 -			    unsigned long event, void *_dev)
 -{
 -	struct device *dev = _dev;
 -
 -	if (event != BUS_NOTIFY_ADD_DEVICE)
 -		return NOTIFY_DONE;
 -
 -	if (of_property_read_bool(dev->of_node, "dma-coherent"))
 -		set_dma_ops(dev, &coherent_swiotlb_dma_ops);
 -
 -	return NOTIFY_OK;
 -}
 -
 -static struct notifier_block platform_bus_nb = {
 -	.notifier_call = dma_bus_notifier,
 -};
 -
 -static struct notifier_block amba_bus_nb = {
 -	.notifier_call = dma_bus_notifier,
 -};
 -
  extern int swiotlb_late_init_with_default_size(size_t default_size);
  
+ static int __init atomic_pool_init(void)
+ {
+ 	pgprot_t prot = __pgprot(PROT_NORMAL_NC);
+ 	unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
+ 	struct page *page;
+ 	void *addr;
+ 	unsigned int pool_size_order = get_order(atomic_pool_size);
+ 
+ 	if (dev_get_cma_area(NULL))
+ 		page = dma_alloc_from_contiguous(NULL, nr_pages,
+ 							pool_size_order);
+ 	else
+ 		page = alloc_pages(GFP_DMA, pool_size_order);
+ 
+ 	if (page) {
+ 		int ret;
+ 		void *page_addr = page_address(page);
+ 
+ 		memset(page_addr, 0, atomic_pool_size);
+ 		__dma_flush_range(page_addr, page_addr + atomic_pool_size);
+ 
+ 		atomic_pool = gen_pool_create(PAGE_SHIFT, -1);
+ 		if (!atomic_pool)
+ 			goto free_page;
+ 
+ 		addr = dma_common_contiguous_remap(page, atomic_pool_size,
+ 					VM_USERMAP, prot, atomic_pool_init);
+ 
+ 		if (!addr)
+ 			goto destroy_genpool;
+ 
+ 		ret = gen_pool_add_virt(atomic_pool, (unsigned long)addr,
+ 					page_to_phys(page),
+ 					atomic_pool_size, -1);
+ 		if (ret)
+ 			goto remove_mapping;
+ 
+ 		gen_pool_set_algo(atomic_pool,
+ 				  gen_pool_first_fit_order_align,
+ 				  (void *)PAGE_SHIFT);
+ 
+ 		pr_info("DMA: preallocated %zu KiB pool for atomic allocations\n",
+ 			atomic_pool_size / 1024);
+ 		return 0;
+ 	}
+ 	goto out;
+ 
+ remove_mapping:
+ 	dma_common_free_remap(addr, atomic_pool_size, VM_USERMAP);
+ destroy_genpool:
+ 	gen_pool_destroy(atomic_pool);
+ 	atomic_pool = NULL;
+ free_page:
+ 	if (!dma_release_from_contiguous(NULL, page, nr_pages))
+ 		__free_pages(page, pool_size_order);
+ out:
+ 	pr_err("DMA: failed to allocate %zu KiB pool for atomic coherent allocation\n",
+ 		atomic_pool_size / 1024);
+ 	return -ENOMEM;
+ }
+ 
  static int __init swiotlb_late_init(void)
  {
  	size_t swiotlb_size = min(SZ_64M, MAX_ORDER_NR_PAGES << PAGE_SHIFT);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* linux-next: manual merge of the akpm-current tree with the arm64 tree
@ 2014-07-24  8:42 Stephen Rothwell
  0 siblings, 0 replies; 29+ messages in thread
From: Stephen Rothwell @ 2014-07-24  8:42 UTC (permalink / raw)
  To: Andrew Morton, Catalin Marinas
  Cc: linux-next, linux-kernel, Laura Abbott, Mark Brown


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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/arm64/Kconfig between commit affeafbb8477 ("arm64: Remove stray
ARCH_HAS_OPP reference") from the arm64 tree and commit 0941368c8dd9
("lib/scatterlist: make ARCH_HAS_SG_CHAIN an actual Kconfig") from the
akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm64/Kconfig
index 555ad3cf3f0f,7bc7b7445774..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -1,6 -1,8 +1,7 @@@
  config ARM64
  	def_bool y
  	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 -	select ARCH_HAS_OPP
+ 	select ARCH_HAS_SG_CHAIN
  	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
  	select ARCH_USE_CMPXCHG_LOCKREF
  	select ARCH_SUPPORTS_ATOMIC_RMW

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, back to index

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-13  8:59 linux-next: manual merge of the akpm-current tree with the arm64 tree Stephen Rothwell
2021-04-13  9:14 ` Catalin Marinas
  -- strict thread matches above, loose matches on Subject: below --
2020-12-03  8:06 Stephen Rothwell
2020-12-03 11:16 ` Catalin Marinas
2020-09-21  8:03 Stephen Rothwell
2020-09-21  8:12 ` Catalin Marinas
2020-10-13  7:34 ` Stephen Rothwell
2020-07-16  8:00 Stephen Rothwell
2020-07-16  8:23 ` Will Deacon
2020-04-30  6:26 Stephen Rothwell
2020-04-29  6:53 Stephen Rothwell
2019-08-07  6:39 Stephen Rothwell
2018-12-13  6:01 Stephen Rothwell
2018-12-13 11:12 ` Will Deacon
2018-12-11  6:11 linux-next: manual merge of the akpm-current tree with the FIXME tree Stephen Rothwell
2018-12-11  6:12 ` linux-next: manual merge of the akpm-current tree with the arm64 tree Stephen Rothwell
2018-12-11 10:39   ` Will Deacon
2018-12-11  6:02 Stephen Rothwell
2018-09-24  4:38 Stephen Rothwell
2018-09-24  9:32 ` Catalin Marinas
2018-07-27 10:55 Stephen Rothwell
2018-08-16  0:11 ` Stephen Rothwell
2017-11-06  5:33 Stephen Rothwell
2016-09-27  6:03 Stephen Rothwell
2016-06-22  4:54 Stephen Rothwell
2015-12-16  5:01 Stephen Rothwell
2015-12-16 10:14 ` Will Deacon
2014-09-23  7:23 Stephen Rothwell
2014-09-23  8:36 ` Catalin Marinas
2014-07-24  8:42 Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git