Hi all,

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

  kernel/resource.c

between commit:

  ea72ce5da228 ("x86/kaslr: Expose and use the end of the physical memory address space")

from Linus' tree and commit:

  e2941fe697c8 ("resource, kunit: add test case for region_intersects()")

from the mm-unstable branch of the mm tree.

I fixed it up (I just used the former - and 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 kernel/resource.c
index 1ac30110b5b3,2ee143fff1af..000000000000
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@@ -1817,8 -1859,18 +1859,12 @@@ EXPORT_SYMBOL(resource_list_free)
  #ifdef CONFIG_GET_FREE_REGION
  #define GFR_DESCENDING		(1UL << 0)
  #define GFR_REQUEST_REGION	(1UL << 1)
- #define GFR_DEFAULT_ALIGN (1UL << PA_SECTION_SHIFT)
+ #ifdef PA_SECTION_SHIFT
+ #define GFR_DEFAULT_ALIGN	(1UL << PA_SECTION_SHIFT)
+ #else
+ #define GFR_DEFAULT_ALIGN	PAGE_SIZE
+ #endif
  
 -#ifdef MAX_PHYSMEM_BITS
 -#define MAX_PHYS_ADDR		((1ULL << MAX_PHYSMEM_BITS) - 1)
 -#else
 -#define MAX_PHYS_ADDR		(-1ULL)
 -#endif
 -
  static resource_size_t gfr_start(struct resource *base, resource_size_t size,
  				 resource_size_t align, unsigned long flags)
  {

Hi all,

On Mon, 9 Sep 2024 10:00:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   kernel/resource.c
> 
> between commit:
> 
>   ea72ce5da228 ("x86/kaslr: Expose and use the end of the physical memory address space")
> 
> from Linus' tree and commit:
> 
>   e2941fe697c8 ("resource, kunit: add test case for region_intersects()")
> 
> from the mm-unstable branch of the mm tree.
> 
> I fixed it up (I just used the former - and 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 kernel/resource.c
> index 1ac30110b5b3,2ee143fff1af..000000000000
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@@ -1817,8 -1859,18 +1859,12 @@@ EXPORT_SYMBOL(resource_list_free)
>   #ifdef CONFIG_GET_FREE_REGION
>   #define GFR_DESCENDING		(1UL << 0)
>   #define GFR_REQUEST_REGION	(1UL << 1)
> - #define GFR_DEFAULT_ALIGN (1UL << PA_SECTION_SHIFT)
> + #ifdef PA_SECTION_SHIFT
> + #define GFR_DEFAULT_ALIGN	(1UL << PA_SECTION_SHIFT)
> + #else
> + #define GFR_DEFAULT_ALIGN	PAGE_SIZE
> + #endif
>   
>  -#ifdef MAX_PHYSMEM_BITS
>  -#define MAX_PHYS_ADDR		((1ULL << MAX_PHYSMEM_BITS) - 1)
>  -#else
>  -#define MAX_PHYS_ADDR		(-1ULL)
>  -#endif
>  -
>   static resource_size_t gfr_start(struct resource *base, resource_size_t size,
>   				 resource_size_t align, unsigned long flags)
>   {

This is now a conflict between the mm-stable tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi all,
>
> Today's linux-next merge of the mm tree got a conflict in:
>
>   kernel/resource.c
>
> between commit:
>
>   ea72ce5da228 ("x86/kaslr: Expose and use the end of the physical memory address space")
>
> from Linus' tree and commit:
>
>   e2941fe697c8 ("resource, kunit: add test case for region_intersects()")
>
> from the mm-unstable branch of the mm tree.
>
> I fixed it up (I just used the former - and 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 fix looks good to me.  Thanks for your help!

--
Best Regards,
Huang, Ying