linux-next: manual merge of the tip tree with the mm tree

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/kernel/vdso.c

between commit:

  6742f72d084b ("mseal sysmap: enable arm64")

from the mm tree and commit:

  0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")

from the tip tree.

I didn't fix it up - couldn't figure it out, so just reverted the former
for today as it was simpler.

It looks like VM_SEALED_SYSMAP needs to be added to
vdso_install_vvar_mapping(), but that is generic across all the
architectures using GENERIC_VDSO_DATA_STORE.

and we have the same between commit

  035f34159d61 ("mseal sysmap: enable x86-64")

from the mm tre and commit

  dafde29605eb ("x86/vdso: Switch to generic storage implementation")

So I have reverted 035f34159d61 as well.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the tip tree with the mm tree

[Thomas Weißschuh]

Hi Stephen,

On Fri, Mar 07, 2025 at 03:14:26PM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/kernel/vdso.c
> 
> between commit:
> 
>   6742f72d084b ("mseal sysmap: enable arm64")
> 
> from the mm tree and commit:
> 
>   0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")
> 
> from the tip tree.
> 
> I didn't fix it up - couldn't figure it out, so just reverted the former
> for today as it was simpler.
> 
> It looks like VM_SEALED_SYSMAP needs to be added to
> vdso_install_vvar_mapping(), but that is generic across all the
> architectures using GENERIC_VDSO_DATA_STORE.

This resolution should be correct.
VM_SEALED_SYSMAP only does something if CONFIG_MSEAL_SYSTEM_MAPPINGS is set.

<snip>

Thomas

Re: linux-next: manual merge of the tip tree with the mm tree

[Andrew Morton]

On Fri, 7 Mar 2025 15:14:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm64/kernel/vdso.c
> 
> between commit:
> 
>   6742f72d084b ("mseal sysmap: enable arm64")
> 
> from the mm tree and commit:
> 
>   0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")
> 
> from the tip tree.
> 
> I didn't fix it up - couldn't figure it out, so just reverted the former
> for today as it was simpler.
> 
> It looks like VM_SEALED_SYSMAP needs to be added to
> vdso_install_vvar_mapping(), but that is generic across all the
> architectures using GENERIC_VDSO_DATA_STORE.
> 
> and we have the same between commit
> 
>   035f34159d61 ("mseal sysmap: enable x86-64")
> 
> from the mm tre and commit
> 
>   dafde29605eb ("x86/vdso: Switch to generic storage implementation")
> 
> So I have reverted 035f34159d61 as well.

Thanks.

How about this?  I scooped Thomas's series into mm.git and merged
Peter's mseal series on top.  I'll sort this out during the merge
window, after the tip tree has merged.

Pushed out now.  Peter, please check my handiwork.

Re: linux-next: manual merge of the tip tree with the mm tree

[Jeff Xu]

On Thu, Mar 6, 2025 at 11:58 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 7 Mar 2025 15:14:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> >   arch/arm64/kernel/vdso.c
> >
> > between commit:
> >
> >   6742f72d084b ("mseal sysmap: enable arm64")
> >
> > from the mm tree and commit:
> >
> >   0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")
> >
> > from the tip tree.
> >
> > I didn't fix it up - couldn't figure it out, so just reverted the former
> > for today as it was simpler.
> >
> > It looks like VM_SEALED_SYSMAP needs to be added to
> > vdso_install_vvar_mapping(), but that is generic across all the
> > architectures using GENERIC_VDSO_DATA_STORE.
> >
> > and we have the same between commit
> >
> >   035f34159d61 ("mseal sysmap: enable x86-64")
> >
> > from the mm tre and commit
> >
> >   dafde29605eb ("x86/vdso: Switch to generic storage implementation")
> >
> > So I have reverted 035f34159d61 as well.
>
> Thanks.
>
> How about this?  I scooped Thomas's series into mm.git and merged
> Peter's mseal series on top.  I'll sort this out during the merge
> window, after the tip tree has merged.
>
> Pushed out now.  Peter, please check my handiwork.

In case this helps, I checked mm-unstable and the merge looks good to
me, thanks Andrew !

-Jeff

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  arch/riscv/include/asm/io.h

between commit:

  85731f537aaf ("mm/ioremap: pass pgprot_t to ioremap_prot() instead of unsigned long")

from th mm-unstable breanch of the mm tree and commit:

  a9ebcb88136c ("mm/memremap: Pass down MEMREMAP_* flags to arch_memremap_wb()")

from the tip 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/riscv/include/asm/io.h
index 0536846db9b6,0257f4aa7ff4..000000000000
--- a/arch/riscv/include/asm/io.h
+++ b/arch/riscv/include/asm/io.h
@@@ -136,8 -136,8 +136,8 @@@ __io_writes_outs(outs, u64, q, __io_pbr
  #include <asm-generic/io.h>
  
  #ifdef CONFIG_MMU
- #define arch_memremap_wb(addr, size)	\
+ #define arch_memremap_wb(addr, size, flags)	\
 -	((__force void *)ioremap_prot((addr), (size), _PAGE_KERNEL))
 +	((__force void *)ioremap_prot((addr), (size), __pgprot(_PAGE_KERNEL)))
  #endif
  
  #endif /* _ASM_RISCV_IO_H */

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

Re: linux-next: manual merge of the tip tree with the mm tree

[Anshuman Khandual]

The fix for the merge-conflict looks good.

On 2/24/25 09:12, Stephen Rothwell wrote:
> diff --cc arch/riscv/include/asm/io.h
> index 0536846db9b6,0257f4aa7ff4..000000000000
> --- a/arch/riscv/include/asm/io.h
> +++ b/arch/riscv/include/asm/io.h
> @@@ -136,8 -136,8 +136,8 @@@ __io_writes_outs(outs, u64, q, __io_pbr
>   #include <asm-generic/io.h>
>   
>   #ifdef CONFIG_MMU
> - #define arch_memremap_wb(addr, size)	\
> + #define arch_memremap_wb(addr, size, flags)	\
>  -	((__force void *)ioremap_prot((addr), (size), _PAGE_KERNEL))
>  +	((__force void *)ioremap_prot((addr), (size), __pgprot(_PAGE_KERNEL)))
>   #endif
>   
>   #endif /* _ASM_RISCV_IO_H */

Re: linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Mon, 24 Feb 2025 14:42:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/riscv/include/asm/io.h
> 
> between commit:
> 
>   85731f537aaf ("mm/ioremap: pass pgprot_t to ioremap_prot() instead of unsigned long")
> 
> from th mm-unstable breanch of the mm tree and commit:
> 
>   a9ebcb88136c ("mm/memremap: Pass down MEMREMAP_* flags to arch_memremap_wb()")
> 
> from the tip 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/riscv/include/asm/io.h
> index 0536846db9b6,0257f4aa7ff4..000000000000
> --- a/arch/riscv/include/asm/io.h
> +++ b/arch/riscv/include/asm/io.h
> @@@ -136,8 -136,8 +136,8 @@@ __io_writes_outs(outs, u64, q, __io_pbr
>   #include <asm-generic/io.h>
>   
>   #ifdef CONFIG_MMU
> - #define arch_memremap_wb(addr, size)	\
> + #define arch_memremap_wb(addr, size, flags)	\
>  -	((__force void *)ioremap_prot((addr), (size), _PAGE_KERNEL))
>  +	((__force void *)ioremap_prot((addr), (size), __pgprot(_PAGE_KERNEL)))
>   #endif
>   
>   #endif /* _ASM_RISCV_IO_H */

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

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  include/linux/mm.h

between commits:

  0562d49197b9 ("mm: prepare lock_vma_under_rcu() for vma reuse possibility")
  db691d64f393 ("mm: convert mm_lock_seq to a proper seqcount")

from the mm-unstable branch of the mm tree and commit:

  eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")

from the tip tree.

I fixed it up (I just used the mm tree version) 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 --]

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  include/linux/mm.h
  include/linux/mm_types.h
  kernel/fork.c
  tools/testing/vma/vma_internal.h

between commits:

  5f0d64389e1f ("mm: convert mm_lock_seq to a proper seqcount")
  062111898568 ("mm: move per-vma lock into vm_area_struct")
  85ad413389ae ("mm: make vma cache SLAB_TYPESAFE_BY_RCU")

from the mm-unstable branch of the mm tree and commit:

  eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")

from the tip tree.

Note that commits 5f0d64389e1f and eb449bd96954 are identical patches.

I fixed it up (I used the mm tree version) 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 tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Mon, 9 Dec 2024 13:24:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   include/linux/mm.h
>   include/linux/mm_types.h
>   kernel/fork.c
>   tools/testing/vma/vma_internal.h
> 
> between commits:
> 
>   5f0d64389e1f ("mm: convert mm_lock_seq to a proper seqcount")
>   062111898568 ("mm: move per-vma lock into vm_area_struct")
>   85ad413389ae ("mm: make vma cache SLAB_TYPESAFE_BY_RCU")
> 
> from the mm-unstable branch of the mm tree and commit:
> 
>   eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")
> 
> from the tip tree.
> 
> Note that commits 5f0d64389e1f and eb449bd96954 are identical patches.
> 
> I fixed it up (I used the mm tree version) 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.

I got 2 more conflicts today due to the duplicate patch above.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the tip tree with the mm tree

[Suren Baghdasaryan]

On Sun, Jan 5, 2025 at 7:09 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 9 Dec 2024 13:24:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the tip tree got conflicts in:
> >
> >   include/linux/mm.h
> >   include/linux/mm_types.h
> >   kernel/fork.c
> >   tools/testing/vma/vma_internal.h
> >
> > between commits:
> >
> >   5f0d64389e1f ("mm: convert mm_lock_seq to a proper seqcount")
> >   062111898568 ("mm: move per-vma lock into vm_area_struct")
> >   85ad413389ae ("mm: make vma cache SLAB_TYPESAFE_BY_RCU")
> >
> > from the mm-unstable branch of the mm tree and commit:
> >
> >   eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")
> >
> > from the tip tree.
> >
> > Note that commits 5f0d64389e1f and eb449bd96954 are identical patches.
> >
> > I fixed it up (I used the mm tree version) 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.
>
> I got 2 more conflicts today due to the duplicate patch above.

Hi Stephen,
Have you been able to resolve the conflicts? Can I help with that?
Thanks,
Suren.

>
> --
> Cheers,
> Stephen Rothwell

Re: linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi Suren,

On Mon, 6 Jan 2025 12:21:14 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Sun, Jan 5, 2025 at 7:09 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I got 2 more conflicts today due to the duplicate patch above.  
> 
> Have you been able to resolve the conflicts? Can I help with that?

I just use the version from the mm tree.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the tip tree with the mm tree

[Suren Baghdasaryan]

On Mon, Jan 6, 2025 at 1:14 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Suren,
>
> On Mon, 6 Jan 2025 12:21:14 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > On Sun, Jan 5, 2025 at 7:09 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > I got 2 more conflicts today due to the duplicate patch above.
> >
> > Have you been able to resolve the conflicts? Can I help with that?
>
> I just use the version from the mm tree.

That should work. Thanks!

>
> --
> Cheers,
> Stephen Rothwell

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/Kconfig

between commit:

  02b4dd56f5ba ("mm/arm64: support large pfn mappings")

from the mm tree and commit:

  699fd9104967 ("arm64: Allow to enable PREEMPT_RT.")

from the tip 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.

I wonder how this would have gone if the "select" statements had been
sorted?
-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/Kconfig
index 3943898f62c9,e68ea648e085..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -101,7 -99,7 +101,8 @@@ config ARM6
  	select ARCH_SUPPORTS_NUMA_BALANCING
  	select ARCH_SUPPORTS_PAGE_TABLE_CHECK
  	select ARCH_SUPPORTS_PER_VMA_LOCK
 +	select ARCH_SUPPORTS_HUGE_PFNMAP if TRANSPARENT_HUGEPAGE
+ 	select ARCH_SUPPORTS_RT
  	select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
  	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION if COMPAT
  	select ARCH_WANT_DEFAULT_BPF_JIT

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

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  kernel/events/uprobes.c

between commit:

  c67907222c56 ("uprobes: use vm_special_mapping close() functionality")

from the mm-unstable branch of the mm tree and commit:

  e240b0fde52f ("uprobes: Use kzalloc to allocate xol area")

from the tip 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 kernel/events/uprobes.c
index 6eddf4352ebb,cac45ea4c284..000000000000
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@@ -1518,8 -1480,6 +1499,7 @@@ static struct xol_area *__create_xol_ar
  		goto free_area;
  
  	area->xol_mapping.name = "[uprobes]";
- 	area->xol_mapping.fault = NULL;
 +	area->xol_mapping.close = uprobe_clear_state;
  	area->xol_mapping.pages = area->pages;
  	area->pages[0] = alloc_page(GFP_HIGHUSER);
  	if (!area->pages[0])

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

Re: linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Thu, 5 Sep 2024 15:35:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   kernel/events/uprobes.c
> 
> between commit:
> 
>   c67907222c56 ("uprobes: use vm_special_mapping close() functionality")
> 
> from the mm-unstable branch of the mm tree and commit:
> 
>   e240b0fde52f ("uprobes: Use kzalloc to allocate xol area")
> 
> from the tip 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 kernel/events/uprobes.c
> index 6eddf4352ebb,cac45ea4c284..000000000000
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@@ -1518,8 -1480,6 +1499,7 @@@ static struct xol_area *__create_xol_ar
>   		goto free_area;
>   
>   	area->xol_mapping.name = "[uprobes]";
> - 	area->xol_mapping.fault = NULL;
>  +	area->xol_mapping.close = uprobe_clear_state;
>   	area->xol_mapping.pages = area->pages;
>   	area->pages[0] = alloc_page(GFP_HIGHUSER);
>   	if (!area->pages[0])

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

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  include/linux/cacheinfo.h

between commit:

  f6a9651bfd74 ("cpumask: make core headers including cpumask_types.h where possible")

from the mm-nonmm-unstable branch of the mm tree and commit:

  685cb1674060 ("cacheinfo: Add function to get cacheinfo for a given CPU and cache level")

from the tip 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/linux/cacheinfo.h
index 286db104e054,3dde175f4108..000000000000
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@@ -3,7 -3,8 +3,8 @@@
  #define _LINUX_CACHEINFO_H
  
  #include <linux/bitops.h>
+ #include <linux/cpuhplock.h>
 -#include <linux/cpumask.h>
 +#include <linux/cpumask_types.h>
  #include <linux/smp.h>
  
  struct device_node;

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

Re: linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Wed, 12 Jun 2024 11:27:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   include/linux/cacheinfo.h
> 
> between commit:
> 
>   f6a9651bfd74 ("cpumask: make core headers including cpumask_types.h where possible")
> 
> from the mm-nonmm-unstable branch of the mm tree and commit:
> 
>   685cb1674060 ("cacheinfo: Add function to get cacheinfo for a given CPU and cache level")
> 
> from the tip 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/linux/cacheinfo.h
> index 286db104e054,3dde175f4108..000000000000
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@@ -3,7 -3,8 +3,8 @@@
>   #define _LINUX_CACHEINFO_H
>   
>   #include <linux/bitops.h>
> + #include <linux/cpuhplock.h>
>  -#include <linux/cpumask.h>
>  +#include <linux/cpumask_types.h>
>   #include <linux/smp.h>
>   
>   struct device_node;

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

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/mm/numa_32.c

between commit:

  d82a37ff6b88 ("fixup! fix missing vmalloc.h includes")

from the mm-unstable branch of the mm tree and commit:

  9852b1dc6a14 ("x86/numa/32: Include missing <asm/pgtable_areas.h>")

from the tip 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/x86/mm/numa_32.c
index e25e08ba4531,025fd7ea5d69..000000000000
--- a/arch/x86/mm/numa_32.c
+++ b/arch/x86/mm/numa_32.c
@@@ -24,7 -24,7 +24,8 @@@
  
  #include <linux/memblock.h>
  #include <linux/init.h>
 +#include <linux/vmalloc.h>
+ #include <asm/pgtable_areas.h>
  
  #include "numa_internal.h"
  

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

Re: linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

On Fri, 5 Apr 2024 11:51:11 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/mm/numa_32.c
> 
> between commit:
> 
>   d82a37ff6b88 ("fixup! fix missing vmalloc.h includes")
> 
> from the mm-unstable branch of the mm tree and commit:
> 
>   9852b1dc6a14 ("x86/numa/32: Include missing <asm/pgtable_areas.h>")
> 
> from the tip tree.
> 
> diff --cc arch/x86/mm/numa_32.c
> index e25e08ba4531,025fd7ea5d69..000000000000
> --- a/arch/x86/mm/numa_32.c
> +++ b/arch/x86/mm/numa_32.c
> @@@ -24,7 -24,7 +24,8 @@@
>   
>   #include <linux/memblock.h>
>   #include <linux/init.h>
>  +#include <linux/vmalloc.h>
> + #include <asm/pgtable_areas.h>
>   
>   #include "numa_internal.h"
>   

This is now a conflict between commit

   9852b1dc6a14 ("x86/numa/32: Include missing <asm/pgtable_areas.h>")

in Linus' tree and commit

  a800a5095942 ("fixup! fix missing vmalloc.h includes")

from the mm-unstable branch of the mm tree.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the tip tree with the mm tree

[Stephen Rothwell]

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

Hi all,

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

  mm/userfaultfd.c

between commit:

  a3b8390c1550 ("mm: userfaultfd: combine 'mode' and 'wp_copy' arguments")

from the mm tree and commit:

  74fd30bd28e4 ("mm: Make pte_mkwrite() take a VMA")

from the tip 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/userfaultfd.c
index 7f1b5f8b712c,3db6f87c0aca..000000000000
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@@ -76,8 -75,8 +76,8 @@@ int mfill_atomic_install_pte(pmd_t *dst
  	if (page_in_cache && !vm_shared)
  		writable = false;
  	if (writable)
- 		_dst_pte = pte_mkwrite(_dst_pte);
+ 		_dst_pte = pte_mkwrite(_dst_pte, dst_vma);
 -	if (wp_copy)
 +	if (flags & MFILL_ATOMIC_WP)
  		_dst_pte = pte_mkuffd_wp(_dst_pte);
  
  	dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, &ptl);

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