linux-next: manual merge of the memblock tree with the origin tree

linux-next: manual merge of the memblock tree with the origin tree

[Mark Brown]

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

Hi all,

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

  mm/memblock.c

between commit:

  e0eec24e2e199 ("memblock: make memblock_set_node() also warn about use of MAX_NUMNODES")

from the origin tree and commit:

  94ff46de4a738 ("memblock: Move late alloc warning down to phys alloc")

from the memblock 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 mm/memblock.c
index e81fb68f7f888,692dc551c0fde..0000000000000
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@@ -1441,6 -1446,20 +1439,9 @@@ phys_addr_t __init memblock_alloc_range
  	enum memblock_flags flags = choose_memblock_flags();
  	phys_addr_t found;
  
+ 	if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
+ 		nid = NUMA_NO_NODE;
+ 
 -	/*
 -	 * Detect any accidental use of these APIs after slab is ready, as at
 -	 * this moment memblock may be deinitialized already and its
 -	 * internal data may be destroyed (after execution of memblock_free_all)
 -	 */
 -	if (WARN_ON_ONCE(slab_is_available())) {
 -		void *vaddr = kzalloc_node(size, GFP_NOWAIT, nid);
 -
 -		return vaddr ? virt_to_phys(vaddr) : 0;
 -	}
 -
  	if (!align) {
  		/* Can't use WARNs this early in boot on powerpc */
  		dump_stack();

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

Re: linux-next: manual merge of the memblock tree with the origin tree

[Gowans, James]

Hi Mark,

On Thu, 2024-06-20 at 16:54 +0100, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the memblock tree got a conflict in:
> 
>   mm/memblock.c
> 
> between commit:
> 
>   e0eec24e2e199 ("memblock: make memblock_set_node() also warn about use of MAX_NUMNODES")
> 
> from the origin tree and commit:
> 
>   94ff46de4a738 ("memblock: Move late alloc warning down to phys alloc")
> 
> from the memblock 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 mm/memblock.c
> index e81fb68f7f888,692dc551c0fde..0000000000000
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@@ -1441,6 -1446,20 +1439,9 @@@ phys_addr_t __init memblock_alloc_range
>   	enum memblock_flags flags = choose_memblock_flags();
>   	phys_addr_t found;
>   
> + 	if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
> + 		nid = NUMA_NO_NODE;
> + 
>  -	/*
>  -	 * Detect any accidental use of these APIs after slab is ready, as at
>  -	 * this moment memblock may be deinitialized already and its
>  -	 * internal data may be destroyed (after execution of memblock_free_all)
>  -	 */
>  -	if (WARN_ON_ONCE(slab_is_available())) {
>  -		void *vaddr = kzalloc_node(size, GFP_NOWAIT, nid);
>  -
>  -		return vaddr ? virt_to_phys(vaddr) : 0;
>  -	}
>  -

This looks like you're deleting the check from the
memblock_alloc_range()? The intention of
commit 94ff46de4a738 ("memblock: Move late alloc warning down to phys alloc")
was to *add* this check here.

Do you have a link where I can see the final repo?
I'm not seeing it here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/mm/memblock.c

JG
>   	if (!align) {
>   		/* Can't use WARNs this early in boot on powerpc */
>   		dump_stack();

Re: linux-next: manual merge of the memblock tree with the origin tree

[Mark Brown]

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

On Thu, Jun 20, 2024 at 04:07:45PM +0000, Gowans, James wrote:
> On Thu, 2024-06-20 at 16:54 +0100, Mark Brown wrote:

> > + 	if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
> > + 		nid = NUMA_NO_NODE;
> > + 
> >  -	/*
> >  -	 * Detect any accidental use of these APIs after slab is ready, as at
> >  -	 * this moment memblock may be deinitialized already and its
> >  -	 * internal data may be destroyed (after execution of memblock_free_all)
> >  -	 */

> This looks like you're deleting the check from the
> memblock_alloc_range()? The intention of
> commit 94ff46de4a738 ("memblock: Move late alloc warning down to phys alloc")
> was to *add* this check here.

Huh, git showed the add/add conflict weirdly then (it looked like an
add/remove) and I wasn't paying enough attention.  Sorry about that.

> Do you have a link where I can see the final repo?
> I'm not seeing it here:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/mm/memblock.c

The merge is still running, it'll appear whenever -next is released
today.

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

Re: linux-next: manual merge of the memblock tree with the origin tree

[Gowans, James]

On Thu, 2024-06-20 at 17:13 +0100, Mark Brown wrote:
> On Thu, Jun 20, 2024 at 04:07:45PM +0000, Gowans, James wrote:
> > On Thu, 2024-06-20 at 16:54 +0100, Mark Brown wrote:
> 
> > > + 	if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
> > > + 		nid = NUMA_NO_NODE;
> > > + 
> > >  -	/*
> > >  -	 * Detect any accidental use of these APIs after slab is ready, as at
> > >  -	 * this moment memblock may be deinitialized already and its
> > >  -	 * internal data may be destroyed (after execution of memblock_free_all)
> > >  -	 */
> 
> > This looks like you're deleting the check from the
> > memblock_alloc_range()? The intention of
> > commit 94ff46de4a738 ("memblock: Move late alloc warning down to phys alloc")
> > was to *add* this check here.
> 
> Huh, git showed the add/add conflict weirdly then (it looked like an
> add/remove) and I wasn't paying enough attention.  Sorry about that.
> 
> > Do you have a link where I can see the final repo?
> > I'm not seeing it here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/mm/memblock.c
> 
> The merge is still running, it'll appear whenever -next is released
> today.

Looking at today's -next:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/mm/memblock.c?h=next-20240620#n1434
I think this check did indeed accidentally get deleted in the merge.

We're expecting the diff in this commit to be present:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/memblock.c?h=next-20240620&id=94ff46de4a738e7916b68ab5cc0b0380729f02af

... but the merge commit appears to have the deleting part but not the
adding part:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/memblock.c?h=next-20240620&id=42781bf9ef85d3d259ec345f3c4e6a5a8b8add64

Correct me if I'm wrong, but it looks like the if statement only got
deleted and not moved, so this would need to be re-worked.

JG

Re: linux-next: manual merge of the memblock tree with the origin tree

[Mark Brown]

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

On Thu, Jun 20, 2024 at 05:59:05PM +0000, Gowans, James wrote:

> Correct me if I'm wrong, but it looks like the if statement only got
> deleted and not moved, so this would need to be re-worked.

Yes, the merge in -next is wrong.

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

Re: linux-next: manual merge of the memblock tree with the origin tree

[Gowans, James]

Hi Mark,

On Thu, 2024-06-20 at 19:00 +0100, Mark Brown wrote:
> On Thu, Jun 20, 2024 at 05:59:05PM +0000, Gowans, James wrote:
> 
> > Correct me if I'm wrong, but it looks like the if statement only got
> > deleted and not moved, so this would need to be re-worked.
> 
> Yes, the merge in -next is wrong.

What's the next step to fix the incorrect merge commit?
Looking at today's -next I see the same issue:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/memblock.c?h=next-20240621&id=f689ee4c062317a0831fbffeeb30d7816608b2e7

JG

Re: linux-next: manual merge of the memblock tree with the origin tree

[Mark Brown]

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

On Fri, Jun 21, 2024 at 08:08:53PM +0000, Gowans, James wrote:
> On Thu, 2024-06-20 at 19:00 +0100, Mark Brown wrote:

> > Yes, the merge in -next is wrong.

> What's the next step to fix the incorrect merge commit?
> Looking at today's -next I see the same issue:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/memblock.c?h=next-20240621&id=f689ee4c062317a0831fbffeeb30d7816608b2e7

It's remembered by rerere, hopefully I'll convince rerere to forget it
on Monday.

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

Re: linux-next: manual merge of the memblock tree with the origin tree

[Mike Rapoport]

Hi,

On Fri, Jun 21, 2024 at 09:30:51PM +0100, Mark Brown wrote:
> On Fri, Jun 21, 2024 at 08:08:53PM +0000, Gowans, James wrote:
> > On Thu, 2024-06-20 at 19:00 +0100, Mark Brown wrote:
> 
> > > Yes, the merge in -next is wrong.
> 
> > What's the next step to fix the incorrect merge commit?
> > Looking at today's -next I see the same issue:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/memblock.c?h=next-20240621&id=f689ee4c062317a0831fbffeeb30d7816608b2e7
> 
> It's remembered by rerere, hopefully I'll convince rerere to forget it
> on Monday.

Just in case this is the resolution for merge conflict

diff --cc mm/memblock.c
index e81fb68f7f88,692dc551c0fd..000000000000
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@@ -1441,6 -1446,20 +1439,17 @@@ phys_addr_t __init memblock_alloc_range
  	enum memblock_flags flags = choose_memblock_flags();
  	phys_addr_t found;
  
 -	if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
 -		nid = NUMA_NO_NODE;
 -
+ 	/*
+ 	 * Detect any accidental use of these APIs after slab is ready, as at
+ 	 * this moment memblock may be deinitialized already and its
+ 	 * internal data may be destroyed (after execution of memblock_free_all)
+ 	 */
+ 	if (WARN_ON_ONCE(slab_is_available())) {
+ 		void *vaddr = kzalloc_node(size, GFP_NOWAIT, nid);
+ 
+ 		return vaddr ? virt_to_phys(vaddr) : 0;
+ 	}
+ 
  	if (!align) {
  		/* Can't use WARNs this early in boot on powerpc */
  		dump_stack();

-- 
Sincerely yours,
Mike.