linux-next: manual merge of the powerpc tree with the arm64 tree

linux-next: manual merge of the powerpc tree with the arm64 tree

[Stephen Rothwell]

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

Hi all,

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

  arch/Kconfig

between commit:

  5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")

from the arm64 tree and commit:

  0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig")

from the powerpc 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/Kconfig
index 6f4d3e9bf486,89e2e3f64f79..000000000000
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -932,20 -925,9 +932,23 @@@ config LOCK_EVENT_COUNT
  	  the chance of application behavior change because of timing
  	  differences. The counts are reported via debugfs.
  
 +# Select if the architecture has support for applying RELR relocations.
 +config ARCH_HAS_RELR
 +	bool
 +
 +config RELR
 +	bool "Use RELR relocation packing"
 +	depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR
 +	default y
 +	help
 +	  Store the kernel's dynamic relocations in the RELR relocation packing
 +	  format. Requires a compatible linker (LLD supports this feature), as
 +	  well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy
 +	  are compatible).
 +
+ config ARCH_HAS_MEM_ENCRYPT
+ 	bool
+ 
  source "kernel/gcov/Kconfig"
  
  source "scripts/gcc-plugins/Kconfig"

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

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Michael Ellerman]

Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
>   arch/Kconfig
>
> between commit:
>
>   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")
>
> from the arm64 tree and commit:
>
>   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig")
>
> from the powerpc 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.

That conflict seems entirely trivial, but Catalin/Will if it bothers you
I have the conflicting commit in a topic branch based on rc2 which you
could merge to resolve it:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=topic/mem-encrypt&id=0c9c1d56397518eb823d458b00b06bcccd956794


cheers

> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/Kconfig
> index 6f4d3e9bf486,89e2e3f64f79..000000000000
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@@ -932,20 -925,9 +932,23 @@@ config LOCK_EVENT_COUNT
>   	  the chance of application behavior change because of timing
>   	  differences. The counts are reported via debugfs.
>   
>  +# Select if the architecture has support for applying RELR relocations.
>  +config ARCH_HAS_RELR
>  +	bool
>  +
>  +config RELR
>  +	bool "Use RELR relocation packing"
>  +	depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR
>  +	default y
>  +	help
>  +	  Store the kernel's dynamic relocations in the RELR relocation packing
>  +	  format. Requires a compatible linker (LLD supports this feature), as
>  +	  well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy
>  +	  are compatible).
>  +
> + config ARCH_HAS_MEM_ENCRYPT
> + 	bool
> + 
>   source "kernel/gcov/Kconfig"
>   
>   source "scripts/gcc-plugins/Kconfig"

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Catalin Marinas]

On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > Hi all,
> >
> > Today's linux-next merge of the powerpc tree got a conflict in:
> >
> >   arch/Kconfig
> >
> > between commit:
> >
> >   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")
> >
> > from the arm64 tree and commit:
> >
> >   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig")
> >
> > from the powerpc 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.
> 
> That conflict seems entirely trivial, but Catalin/Will if it bothers you
> I have the conflicting commit in a topic branch based on rc2 which you
> could merge to resolve it:

It's a trivial conflict, easy to resolve. I don't think it's worth
trying to avoid it (Linus normally doesn't mind such conflicts).

-- 
Catalin

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Will Deacon]

On Mon, Sep 02, 2019 at 10:08:46AM +0100, Catalin Marinas wrote:
> On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
> > Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > > Hi all,
> > >
> > > Today's linux-next merge of the powerpc tree got a conflict in:
> > >
> > >   arch/Kconfig
> > >
> > > between commit:
> > >
> > >   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")
> > >
> > > from the arm64 tree and commit:
> > >
> > >   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig")
> > >
> > > from the powerpc 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.
> > 
> > That conflict seems entirely trivial, but Catalin/Will if it bothers you
> > I have the conflicting commit in a topic branch based on rc2 which you
> > could merge to resolve it:
> 
> It's a trivial conflict, easy to resolve. I don't think it's worth
> trying to avoid it (Linus normally doesn't mind such conflicts).

Agreed, we can live with this one :)

Will

Re: linux-next: manual merge of the powerpc tree with the arm64 tree

[Michael Ellerman]

Catalin Marinas <catalin.marinas@arm.com> writes:
> On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
>> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>> > Hi all,
>> >
>> > Today's linux-next merge of the powerpc tree got a conflict in:
>> >
>> >   arch/Kconfig
>> >
>> > between commit:
>> >
>> >   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")
>> >
>> > from the arm64 tree and commit:
>> >
>> >   0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig")
>> >
>> > from the powerpc 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.
>> 
>> That conflict seems entirely trivial, but Catalin/Will if it bothers you
>> I have the conflicting commit in a topic branch based on rc2 which you
>> could merge to resolve it:
>
> It's a trivial conflict, easy to resolve. I don't think it's worth
> trying to avoid it (Linus normally doesn't mind such conflicts).

Yep, I agree.

cheers