linux-next: manual merge of the kspp tree with Linus' tree

linux-next: manual merge of the kspp tree with Linus' tree

[Stephen Rothwell]

Hi Kees,

FIXME: Add owner of second tree to To:
       Add author(s)/SOB of conflicting commits.

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

  mm/page_alloc.c
  scripts/gcc-plugins/latent_entropy_plugin.c

between commits:

  38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
  0766f788eb72 ("latent_entropy: Mark functions with __latent_entropy")
  58bea4144d23 ("latent_entropy: Fix wrong gcc code generation with 64 bit variables")

from Linus' tree and commits:

  2a5448668a3c ("gcc-plugins: Add latent_entropy plugin")
  09dd109d8241 ("latent_entropy: Mark functions with __latent_entropy")

from the kspp tree.

I fixed it up (I used the version from Linus' tree) 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.

Kees, maybe you could clean up the kspp tree.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kspp tree with Linus' tree

[Kees Cook]

On Mon, Nov 7, 2016 at 7:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> FIXME: Add owner of second tree to To:
>        Add author(s)/SOB of conflicting commits.
>
> Today's linux-next merge of the kspp tree got a conflict in:
>
>   mm/page_alloc.c
>   scripts/gcc-plugins/latent_entropy_plugin.c
>
> between commits:
>
>   38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
>   0766f788eb72 ("latent_entropy: Mark functions with __latent_entropy")
>   58bea4144d23 ("latent_entropy: Fix wrong gcc code generation with 64 bit variables")
>
> from Linus' tree and commits:
>
>   2a5448668a3c ("gcc-plugins: Add latent_entropy plugin")
>   09dd109d8241 ("latent_entropy: Mark functions with __latent_entropy")
>
> from the kspp tree.
>
> I fixed it up (I used the version from Linus' tree) 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.
>
> Kees, maybe you could clean up the kspp tree.

Oh, I wonder how that got out of sync. I've updated the kspp tree.

Thanks!

-Kees

-- 
Kees Cook
Nexus Security

linux-next: manual merge of the kspp tree with Linus' tree

[Stephen Rothwell]

Hi Kees,

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

  include/asm-generic/asm-prototypes.h

between commit:

  c7858bf16c0b ("asm-prototypes: Clear any CPP defines before declaring the functions")

from Linus' tree and commit:

  e89c98504d89 ("initify: Mark functions with the __nocapture attribute")

from the kspp 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/asm-generic/asm-prototypes.h
index 939869c772b1,ea784e02b28e..000000000000
--- a/include/asm-generic/asm-prototypes.h
+++ b/include/asm-generic/asm-prototypes.h
@@@ -1,13 -1,7 +1,13 @@@
  #include <linux/bitops.h>
 +#undef __memset
  extern void *__memset(void *, int, __kernel_size_t);
 +#undef __memcpy
- extern void *__memcpy(void *, const void *, __kernel_size_t);
+ extern void *__memcpy(void *, const void *, __kernel_size_t) __nocapture(2);
 +#undef __memmove
- extern void *__memmove(void *, const void *, __kernel_size_t);
+ extern void *__memmove(void *, const void *, __kernel_size_t) __nocapture(2);
 +#undef memset
  extern void *memset(void *, int, __kernel_size_t);
 +#undef memcpy
- extern void *memcpy(void *, const void *, __kernel_size_t);
+ extern void *memcpy(void *, const void *, __kernel_size_t) __nocapture(2);
 +#undef memmove
- extern void *memmove(void *, const void *, __kernel_size_t);
+ extern void *memmove(void *, const void *, __kernel_size_t) __nocapture(2);

linux-next: manual merge of the kspp tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  tools/testing/selftests/seccomp/seccomp_bpf.c

between commit:

  e4ab5ccc357b ("selftests/seccomp: Catch garbage on SECCOMP_IOCTL_NOTIF_RECV")

from Linus' tree and commit:

  589f6c054d7a ("selftests/seccomp: Catch garbage on SECCOMP_IOCTL_NOTIF_RECV")

from the kspp tree.

I fixed it up (I just used the version from Linus' tree as that seems
to have been committed later) 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 kspp tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  scripts/gcc-plugins/Makefile

between commits:

  735aab1e008b ("kbuild: add -Wall to KBUILD_HOSTCXXFLAGS")

from Linus' tree and commit:

  dda632f1bc6d ("gcc-common.h: Update for GCC 10")
  8d1951750084 ("gcc-plugins: drop support for GCC <= 4.7")

from the kspp 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 scripts/gcc-plugins/Makefile
index f22858b2c3d6,1d0b9382e759..000000000000
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@@ -1,9 -1,19 +1,10 @@@
  # SPDX-License-Identifier: GPL-2.0
 -PLUGINCC := $(CONFIG_PLUGIN_HOSTCC:"%"=%)
  GCC_PLUGINS_DIR := $(shell $(CC) -print-file-name=plugin)
  
 -ifeq ($(PLUGINCC),$(HOSTCC))
 -  HOSTLIBS := hostlibs
 -  HOST_EXTRACFLAGS += -I$(GCC_PLUGINS_DIR)/include -I$(src) -std=gnu99 -ggdb
 -  export HOST_EXTRACFLAGS
 -else
 -  HOSTLIBS := hostcxxlibs
 -  HOST_EXTRACXXFLAGS += -I$(GCC_PLUGINS_DIR)/include -I$(src) -std=gnu++98 -fno-rtti
 -  HOST_EXTRACXXFLAGS += -fno-exceptions -fasynchronous-unwind-tables -ggdb
 -  HOST_EXTRACXXFLAGS += -Wno-narrowing -Wno-unused-variable
 -  HOST_EXTRACXXFLAGS += -Wno-format-diag
 -  export HOST_EXTRACXXFLAGS
 -endif
 +HOST_EXTRACXXFLAGS += -I$(GCC_PLUGINS_DIR)/include -I$(src) -std=gnu++98 -fno-rtti
 +HOST_EXTRACXXFLAGS += -fno-exceptions -fasynchronous-unwind-tables -ggdb
 +HOST_EXTRACXXFLAGS += -Wno-narrowing -Wno-unused-variable -Wno-c++11-compat
++HOST_EXTRACXXFLAGS += -Wno-format-diag
  
  $(obj)/randomize_layout_plugin.o: $(objtree)/$(obj)/randomize_layout_seed.h
  quiet_cmd_create_randomize_layout_seed = GENSEED $@

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

linux-next: manual merge of the kspp tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  kernel/debug/kdb/kdb_io.c

between commit:

  9d71b344f86f ("kdb: Re-factor kdb_printf() message write code")

from Linus' tree and commit:

  80b89ab785a4 ("treewide: Remove uninitialized_var() usage")

from the kspp 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/debug/kdb/kdb_io.c
index 683a799618ad,af0a26a521eb..000000000000
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@@ -591,7 -553,8 +591,7 @@@ int vkdb_printf(enum kdb_msgsrc src, co
  	int this_cpu, old_cpu;
  	char *cp, *cp2, *cphold = NULL, replaced_byte = ' ';
  	char *moreprompt = "more> ";
- 	unsigned long uninitialized_var(flags);
 -	struct console *c;
+ 	unsigned long flags;
  
  	/* Serialize kdb_printf if multiple cpus try to write at once.
  	 * But if any cpu goes recursive in kdb, just print the output,

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

linux-next: manual merge of the kspp tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  lib/random32.c

between commit:

  09a6b0bc3be7 ("random32: Restore __latent_entropy attribute on net_rand_state")

from Linus' tree and commit:

  2ce6b0d4293b ("random32: Restore __latent_entropy attribute on net_rand_state")

from the kspp tree.

I fixed it up (I used Linus' version - just a white space difference)
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 kspp tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/Makefile

between commit:

  0024430e920f ("x86/build: Fix location of '-plugin-opt=' flags")

from Linus' tree and commit:

  095f63b94205 ("x86, lto: Pass -stack-alignment only on LLD < 13.0.0")

from the kspp 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/Makefile
index 2cea1ef283e3,84743ec97c05..000000000000
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@@ -197,12 -203,7 +197,13 @@@ ifdef CONFIG_RETPOLIN
    endif
  endif
  
 -KBUILD_LDFLAGS := -m elf_$(UTS_MACHINE)
 +KBUILD_LDFLAGS += -m elf_$(UTS_MACHINE)
 +
 +ifdef CONFIG_LTO_CLANG
- KBUILD_LDFLAGS	+= -plugin-opt=-code-model=kernel \
- 		   -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8)
++ifeq ($(shell test $(CONFIG_LLD_VERSION) -lt 130000; echo $$?),0)
++KBUILD_LDFLAGS	+= -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8)
++endif
 +endif
  
  ifdef CONFIG_X86_NEED_RELOCS
  LDFLAGS_vmlinux := --emit-relocs --discard-none

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

linux-next: manual merge of the kspp tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/staging/rtl8188eu/include/ieee80211.h

between commit:

  55dfa29b43d2 ("staging: rtl8188eu: remove rtl8188eu driver from staging dir")

from Linus' tree and commit:

  cdea12025e0d ("treewide: Replace 0-element memcpy() destinations with flexible arrays")

from the kspp tree.

I fixed it up (I just removed the file) 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 kspp tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  arch/arm64/Kconfig

between commit:

  6e2edd6371a4 ("arm64: Ensure execute-only permissions are not allowed without EPAN")

from Linus' tree and commit:

  afcf5441b9ff ("arm64: Add gcc Shadow Call Stack support")

from the kspp 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/arm64/Kconfig
index 181679ffedac,de01e77f4db7..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -1259,7 -1252,10 +1260,7 @@@ config HW_PERF_EVENT
  	def_bool y
  	depends on ARM_PMU
  
- # Supported by clang >= 7.0
 -config ARCH_HAS_FILTER_PGPROT
 -	def_bool y
 -
+ # Supported by clang >= 7.0 or GCC >= 12.0.0
  config CC_HAVE_SHADOW_CALL_STACK
  	def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
  

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