linux-next: duplicate patches in the tip tree

linux-next: duplicate patches in the tip tree

[Stephen Rothwell]

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

Hi all,

The following commits are also in the mm tree as different commits
(but the same patches):

  0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")
  127b0e05c166 ("vdso: Rename included Makefile")
  30533a55ec8e ("parisc: Remove unused symbol vdso_data")
  31e9fa2ba9ad ("arm: vdso: Switch to generic storage implementation")
  365841e1557a ("vdso: Add generic architecture-specific data storage")
  3ef32d90cdaa ("x86/vdso: Fix latent bug in vclock_pages calculation")
  46fe55b204bf ("riscv: vdso: Switch to generic storage implementation")
  51d6ca373f45 ("vdso: Add generic random data storage")
  5b47aba85810 ("vdso: Introduce vdso/align.h")
  69896119dc9d ("MIPS: vdso: Switch to generic storage implementation")
  9729dceab17b ("x86/vdso/vdso2c: Remove page handling")
  998a8a260819 ("vdso: Remove remnants of architecture-specific random state storage")
  ac1a42f4e4e2 ("vdso: Remove remnants of architecture-specific time storage")
  d2862bb9d9ca ("LoongArch: vDSO: Switch to generic storage implementation")
  dafde29605eb ("x86/vdso: Switch to generic storage implementation")
  df7fcbefa710 ("vdso: Add generic time data storage")

These are causing the following conflicts:

CONFLICT (content): Merge conflict in arch/arm64/include/asm/vdso/compat_gettim
ofday.h
CONFLICT (content): Merge conflict in arch/arm64/include/asm/vdso/vsyscall.h
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/vdso/gettimeofday.h
CONFLICT (content): Merge conflict in arch/s390/kernel/time.c
CONFLICT (content): Merge conflict in arch/x86/include/asm/vdso/gettimeofday.h
CONFLICT (content): Merge conflict in include/asm-generic/vdso/vsyscall.h
CONFLICT (content): Merge conflict in include/vdso/datapage.h
CONFLICT (content): Merge conflict in include/vdso/helpers.h
CONFLICT (content): Merge conflict in kernel/time/namespace.c
CONFLICT (content): Merge conflict in kernel/time/vsyscall.c
CONFLICT (add/add): Merge conflict in lib/vdso/datastore.c
CONFLICT (content): Merge conflict in lib/vdso/gettimeofday.c

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: duplicate patches in the tip tree

[Andrew Morton]

On Tue, 11 Mar 2025 15:08:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> The following commits are also in the mm tree as different commits
> (but the same patches):
> 
>   0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")
>   127b0e05c166 ("vdso: Rename included Makefile")
>   30533a55ec8e ("parisc: Remove unused symbol vdso_data")
>   31e9fa2ba9ad ("arm: vdso: Switch to generic storage implementation")
>   365841e1557a ("vdso: Add generic architecture-specific data storage")
>   3ef32d90cdaa ("x86/vdso: Fix latent bug in vclock_pages calculation")
>   46fe55b204bf ("riscv: vdso: Switch to generic storage implementation")
>   51d6ca373f45 ("vdso: Add generic random data storage")
>   5b47aba85810 ("vdso: Introduce vdso/align.h")
>   69896119dc9d ("MIPS: vdso: Switch to generic storage implementation")
>   9729dceab17b ("x86/vdso/vdso2c: Remove page handling")
>   998a8a260819 ("vdso: Remove remnants of architecture-specific random state storage")
>   ac1a42f4e4e2 ("vdso: Remove remnants of architecture-specific time storage")
>   d2862bb9d9ca ("LoongArch: vDSO: Switch to generic storage implementation")
>   dafde29605eb ("x86/vdso: Switch to generic storage implementation")
>   df7fcbefa710 ("vdso: Add generic time data storage")
> 
> These are causing the following conflicts:
> 
> CONFLICT (content): Merge conflict in arch/arm64/include/asm/vdso/compat_gettim
> ofday.h
> CONFLICT (content): Merge conflict in arch/arm64/include/asm/vdso/vsyscall.h
> CONFLICT (content): Merge conflict in arch/powerpc/include/asm/vdso/gettimeofday.h
> CONFLICT (content): Merge conflict in arch/s390/kernel/time.c
> CONFLICT (content): Merge conflict in arch/x86/include/asm/vdso/gettimeofday.h
> CONFLICT (content): Merge conflict in include/asm-generic/vdso/vsyscall.h
> CONFLICT (content): Merge conflict in include/vdso/datapage.h
> CONFLICT (content): Merge conflict in include/vdso/helpers.h
> CONFLICT (content): Merge conflict in kernel/time/namespace.c
> CONFLICT (content): Merge conflict in kernel/time/vsyscall.c
> CONFLICT (add/add): Merge conflict in lib/vdso/datastore.c
> CONFLICT (content): Merge conflict in lib/vdso/gettimeofday.c

Yup, thanks.  I trust it's not too much effort to simply skip the
mm.git copies?

There's presumably a better way of doing this, but it's really the
first time it has happened in N years so it isn't obviously worth
investing in setting something up.

Re: linux-next: duplicate patches in the tip tree

[Stephen Rothwell]

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

Hi Andrew,

On Tue, 11 Mar 2025 02:02:40 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Yup, thanks.  I trust it's not too much effort to simply skip the
> mm.git copies?

Not now that I have done it once ("git rerere" remembers my previous
merge resolutions).  Unless, of course, more changes are made to the
files involved ...

> There's presumably a better way of doing this, but it's really the
> first time it has happened in N years so it isn't obviously worth
> investing in setting something up.

This is why we have shared stable branches.  If the tip guys have all
those commits in a branch that they guarantee will not rebase (or be
rewritten), then you could fetch that branch and merge it into your
tree somewhere.  In this case, since we are beyond -rc6 and I presume
you are starting to think about your stable branches, you could start
mm-stable and merge it in there.  I assume that mm-unstable is always
based on top of mm-stable, right?  So the patches that depend on (or
clash with) the common commits will be rebased on top of the common
branch.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: duplicate patches in the tip tree

[Thomas Gleixner]

On Tue, Mar 11 2025 at 22:43, Stephen Rothwell wrote:
> On Tue, 11 Mar 2025 02:02:40 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>> There's presumably a better way of doing this, but it's really the
>> first time it has happened in N years so it isn't obviously worth
>> investing in setting something up.
>
> This is why we have shared stable branches.  If the tip guys have all
> those commits in a branch that they guarantee will not rebase (or be
> rewritten), then you could fetch that branch and merge it into your
> tree somewhere.

tip timers/vdso is stable and won't be rebased. It might get delta fixes
on top, but that should be not a problem.

Andrew, feel free to pull that in.

Thanks,

        tglx

Re: linux-next: duplicate patches in the tip tree

[Stephen Rothwell]

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

Hi all,

On Tue, 11 Mar 2025 15:08:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> The following commits are also in the mm tree as different commits
> (but the same patches):
> 
>   0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")
>   127b0e05c166 ("vdso: Rename included Makefile")
>   30533a55ec8e ("parisc: Remove unused symbol vdso_data")
>   31e9fa2ba9ad ("arm: vdso: Switch to generic storage implementation")
>   365841e1557a ("vdso: Add generic architecture-specific data storage")
>   3ef32d90cdaa ("x86/vdso: Fix latent bug in vclock_pages calculation")
>   46fe55b204bf ("riscv: vdso: Switch to generic storage implementation")
>   51d6ca373f45 ("vdso: Add generic random data storage")
>   5b47aba85810 ("vdso: Introduce vdso/align.h")
>   69896119dc9d ("MIPS: vdso: Switch to generic storage implementation")
>   9729dceab17b ("x86/vdso/vdso2c: Remove page handling")
>   998a8a260819 ("vdso: Remove remnants of architecture-specific random state storage")
>   ac1a42f4e4e2 ("vdso: Remove remnants of architecture-specific time storage")
>   d2862bb9d9ca ("LoongArch: vDSO: Switch to generic storage implementation")
>   dafde29605eb ("x86/vdso: Switch to generic storage implementation")
>   df7fcbefa710 ("vdso: Add generic time data storage")

Those patches are now in Linus' tree.

> These are causing the following conflicts:
> 
> CONFLICT (content): Merge conflict in arch/arm64/include/asm/vdso/compat_gettim
> ofday.h
> CONFLICT (content): Merge conflict in arch/arm64/include/asm/vdso/vsyscall.h
> CONFLICT (content): Merge conflict in arch/powerpc/include/asm/vdso/gettimeofday.h
> CONFLICT (content): Merge conflict in arch/s390/kernel/time.c
> CONFLICT (content): Merge conflict in arch/x86/include/asm/vdso/gettimeofday.h
> CONFLICT (content): Merge conflict in include/asm-generic/vdso/vsyscall.h
> CONFLICT (content): Merge conflict in include/vdso/datapage.h
> CONFLICT (content): Merge conflict in include/vdso/helpers.h
> CONFLICT (content): Merge conflict in kernel/time/namespace.c
> CONFLICT (content): Merge conflict in kernel/time/vsyscall.c
> CONFLICT (add/add): Merge conflict in lib/vdso/datastore.c
> CONFLICT (content): Merge conflict in lib/vdso/gettimeofday.c

The duplicates in the mm-unstable branch of the mm tree are

  93b9079e691e ("vdso: remove remnants of architecture-specific time storage")
  82d8b6446a79 ("vdso: remove remnants of architecture-specific random state storage")
  f37aec9ec784 ("x86/vdso/vdso2c: remove page handling")
  dd2e8659933d ("x86/vdso: switch to generic storage implementation")
  9ac741560b0b ("powerpc/vdso: switch to generic storage implementation")
  4ca30cfeffb7 ("MIPS: vdso: switch to generic storage implementation")
  b9e3ec578ed5 ("s390/vdso: switch to generic storage implementation")
  64ed071644a8 ("arm: vdso: switch to generic storage implementation")
  af0452ad92f5 ("LoongArch: vDSO: switch to generic storage implementation")
  f3f0b0bb602e ("riscv: vdso: switch to generic storage implementation")
  74100951337a ("arm64: vdso: switch to generic storage implementation")
  08652b7a1b59 ("vdso: add generic architecture-specific data storage")
  0ab86f7ece6f ("vdso: add generic random data storage")
  f3b11eb27436 ("vdso: add generic time data storage")
  4559a06ae7c1 ("vdso: rename included Makefile")
  0f187d7ac318 ("vdso: introduce vdso/align.h")
  2d1b4965384c ("parisc: remove unused symbol vdso_data")
  837f2f1a07ad ("x86/vdso: fix latent bug in vclock_pages calculation")

-- 
Cheers,
Stephen Rothwell

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

linux-next: duplicate patches in the tip tree

[Stephen Rothwell]

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

Hi all,

The following commits are also in the sound-asoc tree as different commits
(but the same patches):

  4476e7f81467 ("x86/amd_node: Add a smn_read_register() helper")
  9c19cc1f5f57 ("x86/amd_node: Add support for debugfs access to SMN registers")
  83518453074d ("x86/amd_node: Add SMN offsets to exclusive region access")
  8a3dc0f7c4cc ("x86/amd_node, platform/x86/amd/hsmp: Have HSMP use SMN through AMD_NODE")
  ad5a3a8f41aa ("x86/mtrr: Use str_enabled_disabled() helper in print_mtrr_state()")
  d55f31e29047 ("x86/entry: Add __init to ia32_emulation_override_cmdline()")

These are commits

  c893ee3f95f1 ("x86/amd_node: Add a smn_read_register() helper")
  6b06755af667 ("x86/amd_node: Add support for debugfs access to SMN registers")
  bebe0afb7451 ("x86/amd_node: Add SMN offsets to exclusive region access")
  735049b801cf ("x86/amd_node, platform/x86/amd/hsmp: Have HSMP use SMN through AMD_NODE")
  e3cd85963a20 ("x86/mtrr: Use str_enabled_disabled() helper in print_mtrr_state()")
  b2f10aa2eb18 ("x86/entry: Add __init to ia32_emulation_override_cmdline()")

in the sound-asoc tree.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: duplicate patches in the tip tree

[Mark Brown]

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

On Thu, Mar 20, 2025 at 08:46:17PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> The following commits are also in the sound-asoc tree as different commits
> (but the same patches):
> 
>   4476e7f81467 ("x86/amd_node: Add a smn_read_register() helper")
>   9c19cc1f5f57 ("x86/amd_node: Add support for debugfs access to SMN registers")
>   83518453074d ("x86/amd_node: Add SMN offsets to exclusive region access")
>   8a3dc0f7c4cc ("x86/amd_node, platform/x86/amd/hsmp: Have HSMP use SMN through AMD_NODE")
>   ad5a3a8f41aa ("x86/mtrr: Use str_enabled_disabled() helper in print_mtrr_state()")
>   d55f31e29047 ("x86/entry: Add __init to ia32_emulation_override_cmdline()")
> 
> These are commits
> 
>   c893ee3f95f1 ("x86/amd_node: Add a smn_read_register() helper")
>   6b06755af667 ("x86/amd_node: Add support for debugfs access to SMN registers")
>   bebe0afb7451 ("x86/amd_node: Add SMN offsets to exclusive region access")
>   735049b801cf ("x86/amd_node, platform/x86/amd/hsmp: Have HSMP use SMN through AMD_NODE")
>   e3cd85963a20 ("x86/mtrr: Use str_enabled_disabled() helper in print_mtrr_state()")
>   b2f10aa2eb18 ("x86/entry: Add __init to ia32_emulation_override_cmdline()")
> 
> in the sound-asoc tree.

This was a branch I was given by the AMD people to base some work that
uses SMNs on - looks like it's been rebased?

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

linux-next: duplicate patches in the tip tree

[Stephen Rothwell]

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

Hi all,

The following commits are also in the mm tree as different commits
(but the same patches):

  96450ead1652 ("seqlock: add raw_seqcount_try_begin")
  eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")

These are commits

  46dbe8ab1205 ("seqlock: add raw_seqcount_try_begin")
  5f0d64389e1f ("mm: convert mm_lock_seq to a proper seqcount")

from the mm-unstable branch of the mm tree.  The latter ones are already
causing conflicts.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: duplicate patches in the tip tree

[Peter Zijlstra]

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

On Mon, Dec 09, 2024 at 01:29:41PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> The following commits are also in the mm tree as different commits
> (but the same patches):
> 
>   96450ead1652 ("seqlock: add raw_seqcount_try_begin")
>   eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")
> 
> These are commits
> 
>   46dbe8ab1205 ("seqlock: add raw_seqcount_try_begin")
>   5f0d64389e1f ("mm: convert mm_lock_seq to a proper seqcount")
> 
> from the mm-unstable branch of the mm tree.  The latter ones are already
> causing conflicts.

Why is this in -mm ? I agreed with Suren I'd take them through
tip/perf/core to go along with Andrii's uprobe patch that relies on
them.

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

Re: linux-next: duplicate patches in the tip tree

[Andrew Morton]

On Mon, 9 Dec 2024 12:08:42 +0100 Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Dec 09, 2024 at 01:29:41PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > The following commits are also in the mm tree as different commits
> > (but the same patches):
> > 
> >   96450ead1652 ("seqlock: add raw_seqcount_try_begin")
> >   eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")
> > 
> > These are commits
> > 
> >   46dbe8ab1205 ("seqlock: add raw_seqcount_try_begin")
> >   5f0d64389e1f ("mm: convert mm_lock_seq to a proper seqcount")
> > 
> > from the mm-unstable branch of the mm tree.  The latter ones are already
> > causing conflicts.
> 
> Why is this in -mm ?

Because
https://lore.kernel.org/all/20241206225204.4008261-1-surenb@google.com/T/#u
needs it.

> I agreed with Suren I'd take them through
> tip/perf/core to go along with Andrii's uprobe patch that relies on
> them.

Re: linux-next: duplicate patches in the tip tree

[Suren Baghdasaryan]

On Mon, Dec 9, 2024 at 11:45 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 9 Dec 2024 12:08:42 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Mon, Dec 09, 2024 at 01:29:41PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > The following commits are also in the mm tree as different commits
> > > (but the same patches):
> > >
> > >   96450ead1652 ("seqlock: add raw_seqcount_try_begin")
> > >   eb449bd96954 ("mm: convert mm_lock_seq to a proper seqcount")
> > >
> > > These are commits
> > >
> > >   46dbe8ab1205 ("seqlock: add raw_seqcount_try_begin")
> > >   5f0d64389e1f ("mm: convert mm_lock_seq to a proper seqcount")
> > >
> > > from the mm-unstable branch of the mm tree.  The latter ones are already
> > > causing conflicts.
> >
> > Why is this in -mm ?
>
> Because
> https://lore.kernel.org/all/20241206225204.4008261-1-surenb@google.com/T/#u
> needs it.
>
> > I agreed with Suren I'd take them through
> > tip/perf/core to go along with Andrii's uprobe patch that relies on
> > them.

Both trees now have changes depending on those patches. If we can't
have them in both trees then I can rework my last patchset in the mm
tree to use old seqcount code and not require those patches, but we
will have to deal with the merge conflicts later.

Re: linux-next: duplicate patches in the tip tree

[Thomas Gleixner]

On Mon, Dec 09 2024 at 12:21, Suren Baghdasaryan wrote:
> On Mon, Dec 9, 2024 at 11:45 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Mon, 9 Dec 2024 12:08:42 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
>> > Why is this in -mm ?
>>
>> Because
>> https://lore.kernel.org/all/20241206225204.4008261-1-surenb@google.com/T/#u
>> needs it.
>>
>> > I agreed with Suren I'd take them through
>> > tip/perf/core to go along with Andrii's uprobe patch that relies on
>> > them.
>
> Both trees now have changes depending on those patches. If we can't
> have them in both trees then I can rework my last patchset in the mm
> tree to use old seqcount code and not require those patches, but we
> will have to deal with the merge conflicts later.

Usually one tree picks the changes up into a seperate branch based on
-rc1 and declares that branch immutable by tagging it. Both trees then
can merge it into their respective branches which depend on it.

Thanks,

        tglx

linux-next: duplicate patches in the tip tree

[Stephen Rothwell]

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

Hi all,

The following commits are also in Linus Torvalds' tree as different
commits (but the same patches):

  96f9a366ec8a ("timekeeping: Add percpu counter for tracking floor swap events"
  70c8fd00a9bd ("timekeeping: Add interfaces for handling timestamps with a floor value")

These are commits

  2a15385742c6 ("timekeeping: Add percpu counter for tracking floor swap events")
  ee3283c608df ("timekeeping: Add interfaces for handling timestamps with a floor value")

in Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

linux-next: duplicate patches in the tip tree

[Stephen Rothwell]

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

Hi all,

The following commits are also in Linus Torvalds' tree as different
commits (but the same patches):

  9e1daa3bfccc ("x86/e820: Don't reserve SETUP_RNG_SEED in e820")

This is commit

  7fd817c90650 ("x86/e820: Don't reserve SETUP_RNG_SEED in e820")

in Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: duplicate patches in the tip tree

[Ingo Molnar]

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

> Hi all,
> 
> The following commits are also in Linus Torvalds' tree as different
> commits (but the same patches):
> 
>   9e1daa3bfccc ("x86/e820: Don't reserve SETUP_RNG_SEED in e820")
> 
> This is commit
> 
>   7fd817c90650 ("x86/e820: Don't reserve SETUP_RNG_SEED in e820")
> 
> in Linus' tree.

This was only temporary, should be resolved in the next -next integration.

Thanks,

	Ingo