linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

[Mark Brown]

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

Hi all,

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

  mm/secretmem.c

between commits:

  0d171c47f2be6 ("mm/secretmem: properly account locked pages")
  a31a4988ca3e8 ("set_memory: add number of pages parameter to set_direct_map APIs")

from the mm,mm-fixes tree and commit:

  d2c5e077cbeaf ("mm/secretmem: properly account locked pages")

from the mm-nonmm-unstable 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 --combined mm/secretmem.c
index 6cbb8efc994a4,384f5cfc457f9..0000000000000
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@@ -139,7 -139,7 +139,7 @@@ retry
  			goto out;
  		}
  
 -		err = set_direct_map_invalid_noflush(folio_page(folio, 0));
 +		err = set_direct_map_invalid_noflush(folio_page(folio, 0), 1);
  		if (err) {
  			secretmem_unaccount_folio(state, folio);
  			folio_put(folio);
@@@ -156,7 -156,7 +156,7 @@@
  			 * already happened when we marked the page invalid
  			 * which guarantees that this call won't fail
  			 */
 -			set_direct_map_default_noflush(folio_page(folio, 0));
 +			set_direct_map_default_noflush(folio_page(folio, 0), 1);
  			folio_put(folio);
  			if (err == -EEXIST)
  				goto retry;
@@@ -228,7 -228,7 +228,7 @@@ static int secretmem_migrate_folio(stru
  
  static void secretmem_free_folio(struct folio *folio)
  {
 -	set_direct_map_default_noflush(folio_page(folio, 0));
 +	set_direct_map_default_noflush(folio_page(folio, 0), 1);
  	folio_zero_segment(folio, 0, folio_size(folio));
  }
  

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

Re: linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

[Lorenzo Stoakes (ARM)]

On Wed, Sep 02, 2026 at 11:20:09AM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the mm-nonmm-unstable tree got a conflict in:
>
>   mm/secretmem.c
>
> between commits:
>
>   0d171c47f2be6 ("mm/secretmem: properly account locked pages")
>   a31a4988ca3e8 ("set_memory: add number of pages parameter to set_direct_map APIs")
>
> from the mm,mm-fixes tree and commit:
>
>   d2c5e077cbeaf ("mm/secretmem: properly account locked pages")
>
> from the mm-nonmm-unstable 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.

LGTM, thanks!

>
> diff --combined mm/secretmem.c
> index 6cbb8efc994a4,384f5cfc457f9..0000000000000
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@@ -139,7 -139,7 +139,7 @@@ retry
>   			goto out;
>   		}
>
>  -		err = set_direct_map_invalid_noflush(folio_page(folio, 0));
>  +		err = set_direct_map_invalid_noflush(folio_page(folio, 0), 1);
>   		if (err) {
>   			secretmem_unaccount_folio(state, folio);
>   			folio_put(folio);
> @@@ -156,7 -156,7 +156,7 @@@
>   			 * already happened when we marked the page invalid
>   			 * which guarantees that this call won't fail
>   			 */
>  -			set_direct_map_default_noflush(folio_page(folio, 0));
>  +			set_direct_map_default_noflush(folio_page(folio, 0), 1);
>   			folio_put(folio);
>   			if (err == -EEXIST)
>   				goto retry;
> @@@ -228,7 -228,7 +228,7 @@@ static int secretmem_migrate_folio(stru
>
>   static void secretmem_free_folio(struct folio *folio)
>   {
>  -	set_direct_map_default_noflush(folio_page(folio, 0));
>  +	set_direct_map_default_noflush(folio_page(folio, 0), 1);
>   	folio_zero_segment(folio, 0, folio_size(folio));
>   }
>



--
Cheers, Lorenzo

Re: linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

[Mark Brown]

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

On Wed, Sep 02, 2026 at 12:12:22PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Wed, Sep 02, 2026 at 11:20:09AM +0100, Mark Brown wrote:

> > between commits:
> >
> >   0d171c47f2be6 ("mm/secretmem: properly account locked pages")

> > from the mm,mm-fixes tree and commit:
> >
> >   d2c5e077cbeaf ("mm/secretmem: properly account locked pages")
> >
> > from the mm-nonmm-unstable tree.

> LGTM, thanks!

BTW note the above duplicate commits.

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

Re: linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

[Mike Rapoport]

On Wed, Sep 02, 2026 at 11:20:09AM +0100, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the mm-nonmm-unstable tree got a conflict in:
> 
>   mm/secretmem.c
> 
> between commits:
> 
>   0d171c47f2be6 ("mm/secretmem: properly account locked pages")
>   a31a4988ca3e8 ("set_memory: add number of pages parameter to set_direct_map APIs")
> 
> from the mm,mm-fixes tree and commit:
> 
>   d2c5e077cbeaf ("mm/secretmem: properly account locked pages")
> 
> from the mm-nonmm-unstable 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.

Thanks, Mark!
 
-- 
Sincerely yours,
Mike.

Re: linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

[Mike Rapoport]

On Wed, Sep 02, 2026 at 12:19:30PM +0100, Mark Brown wrote:
> On Wed, Sep 02, 2026 at 12:12:22PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Wed, Sep 02, 2026 at 11:20:09AM +0100, Mark Brown wrote:
> 
> > > between commits:
> > >
> > >   0d171c47f2be6 ("mm/secretmem: properly account locked pages")
> 
> > > from the mm,mm-fixes tree and commit:
> > >
> > >   d2c5e077cbeaf ("mm/secretmem: properly account locked pages")
> > >
> > > from the mm-nonmm-unstable tree.
> 
> > LGTM, thanks!
> 
> BTW note the above duplicate commits.

This is a transition artifact :)

-- 
Sincerely yours,
Mike.

Re: linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

[Mark Brown]

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

On Wed, Sep 02, 2026 at 03:06:09PM +0300, Mike Rapoport wrote:
> On Wed, Sep 02, 2026 at 11:20:09AM +0100, Mark Brown wrote:

> > between commits:

> >   0d171c47f2be6 ("mm/secretmem: properly account locked pages")

> > from the mm,mm-fixes tree and commit:

> >   d2c5e077cbeaf ("mm/secretmem: properly account locked pages")

> > from the mm-nonmm-unstable tree.

> Thanks, Mark!

There's some more duplicated commits here BTW.

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

Re: linux-next: manual merge of the mm-nonmm-unstable tree with the mm,mm-fixes tree

[Andrew Morton]

On Wed, 2 Sep 2026 13:13:47 +0100 Mark Brown <broonie@kernel.org> wrote:

> On Wed, Sep 02, 2026 at 03:06:09PM +0300, Mike Rapoport wrote:
> > On Wed, Sep 02, 2026 at 11:20:09AM +0100, Mark Brown wrote:
> 
> > > between commits:
> 
> > >   0d171c47f2be6 ("mm/secretmem: properly account locked pages")
> 
> > > from the mm,mm-fixes tree and commit:
> 
> > >   d2c5e077cbeaf ("mm/secretmem: properly account locked pages")
> 
> > > from the mm-nonmm-unstable tree.
> 
> > Thanks, Mark!
> 
> There's some more duplicated commits here BTW.

I'm not sure what's going on here.

Yesterday I rebuilt/rebased mm-hotfixes-stable because stupidhead had
gone and put a merge commit in there (this triggers Linus).  Rebuilt
all branches based on that.  Then at some point (when?) this was all
moved into mm-next.

So shudder.  Hopefully it'll all sort itself out tomorrow.