All of lore.kernel.org
 help / color / mirror / Atom feed
* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2021-06-25 10:37 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2021-06-25 10:37 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Marco Elver,
	Nick Desaulniers

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

Hi all,

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

  include/linux/compiler_types.h

between commit:

  380d53c45ff2 ("compiler_attributes.h: define __no_profile, add to noinstr")

from the kspp tree and commit:

  120ae5440ef0 ("kcov: add __no_sanitize_coverage to fix noinstr for all architectures")

from the akpm-current 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/compiler_types.h
index d509169860f1,cc2bee7f0977..000000000000
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@@ -210,7 -210,7 +210,7 @@@ struct ftrace_likely_data 
  /* Section for code which can't be instrumented at all */
  #define noinstr								\
  	noinline notrace __attribute((__section__(".noinstr.text")))	\
- 	__no_kcsan __no_sanitize_address __no_profile
 -	__no_kcsan __no_sanitize_address __no_sanitize_coverage
++	__no_kcsan __no_sanitize_address __no_sanitize_coverage __no_profile
  
  #endif /* __KERNEL__ */
  

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2022-03-03  8:15 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2022-03-03  8:15 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Anshuman Khandual, Linux Kernel Mailing List,
	Linux Next Mailing List, Stephen Rothwell

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

Hi all,

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

  mm/Kconfig

between commit:

  2792d84e6da5 ("usercopy: Check valid lifetime via stack depth")

from the kspp tree and commit:

  29c91f123969 ("mm: generalize ARCH_HAS_FILTER_PGPROT")

from the akpm-current 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/Kconfig
index 4b7663a91f18,67998bd3352e..000000000000
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@@ -747,15 -750,9 +753,18 @@@ config IDLE_PAGE_TRACKIN
  config ARCH_HAS_CACHE_LINE_SIZE
  	bool
  
 +config ARCH_HAS_CURRENT_STACK_POINTER
 +	bool
 +	help
 +	  In support of HARDENED_USERCOPY performing stack variable lifetime
 +	  checking, an architecture-agnostic way to find the stack pointer
 +	  is needed. Once an architecture defines an unsigned long global
 +	  register alias named "current_stack_pointer", this config can be
 +	  selected.
 +
+ config ARCH_HAS_FILTER_PGPROT
+ 	bool
+ 
  config ARCH_HAS_PTE_DEVMAP
  	bool
  

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2020-11-25 10:05 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2020-11-25 10:05 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux Kernel Mailing List, Linux Next Mailing List,
	Mike Rapoport, Mike Rapoport, Nathan Chancellor

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

Hi all,

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

  arch/Kconfig

between commit:

  5a3a47bf8367 ("orphans: Hoist '--orphan-handling' into Kconfig")

from the kspp tree and commits:

  84d8b3661cc9 ("arm, arm64: move free_unused_memmap() to generic mm")
  46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on DEBUG_PAGEALLOC")

from the akpm-current 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 313b2bc0c475,9ebdab3d0ca2..000000000000
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -1062,15 -1035,12 +1069,21 @@@ config HAVE_STATIC_CALL_INLIN
  	bool
  	depends on HAVE_STATIC_CALL
  
 +config ARCH_WANT_LD_ORPHAN_WARN
 +	bool
 +	help
 +	  An arch should select this symbol once all linker sections are explicitly
 +	  included, size-asserted, or discarded in the linker scripts. This is
 +	  important because we never want expected sections to be placed heuristically
 +	  by the linker, since the locations of such sections can change between linker
 +	  versions.
 +
+ config HAVE_ARCH_PFN_VALID
+ 	bool
+ 
+ config ARCH_SUPPORTS_DEBUG_PAGEALLOC
+ 	bool
+ 
  source "kernel/gcov/Kconfig"
  
  source "scripts/gcc-plugins/Kconfig"

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2019-02-13  6:03 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2019-02-13  6:03 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Andrey Ryabinin

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

Hi Andrew,

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

  scripts/gcc-plugins/Kconfig

between commit:

  9219e54be983 ("gcc-plugins: structleak: Generalize to all variable types")

from the kspp tree and commit:

  7fabedf42152 ("kasan: remove use after scope bugs detection.")

from the akpm-current 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/Kconfig
index d0cc92e48f6f,d9fd9988ef27..000000000000
--- a/scripts/gcc-plugins/Kconfig
+++ b/scripts/gcc-plugins/Kconfig
@@@ -67,22 -67,13 +67,18 @@@ config GCC_PLUGIN_LATENT_ENTROP
  	   * https://pax.grsecurity.net/
  
  config GCC_PLUGIN_STRUCTLEAK
 -	bool "Force initialization of variables containing userspace addresses"
 +	bool "Zero initialize stack variables"
- 	# Currently STRUCTLEAK inserts initialization out of live scope of
- 	# variables from KASAN point of view. This leads to KASAN false
- 	# positive reports. Prohibit this combination for now.
- 	depends on !KASAN_EXTRA
  	help
 -	  This plugin zero-initializes any structures containing a
 -	  __user attribute. This can prevent some classes of information
 -	  exposures.
 -
 -	  This plugin was ported from grsecurity/PaX. More information at:
 +	  While the kernel is built with warnings enabled for any missed
 +	  stack variable initializations, this warning is silenced for
 +	  anything passed by reference to another function, under the
 +	  occasionally misguided assumption that the function will do
 +	  the initialization. As this regularly leads to exploitable
 +	  flaws, this plugin is available to identify and zero-initialize
 +	  such variables, depending on the chosen level of coverage.
 +
 +	  This plugin was originally ported from grsecurity/PaX. More
 +	  information at:
  	   * https://grsecurity.net/
  	   * https://pax.grsecurity.net/
  

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the kspp tree
  2018-01-15 12:41 ` Arnd Bergmann
@ 2018-01-15 20:07   ` Kees Cook
  0 siblings, 0 replies; 14+ messages in thread
From: Kees Cook @ 2018-01-15 20:07 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, Jan 15, 2018 at 4:41 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi Andrew,
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>   arch/cris/include/arch-v10/arch/bug.h
>>
>> between commit:
>>
>>   c8133e59edb0 ("cris: Mark end of BUG() implementation as unreachable")
>>
>> from the kspp tree and commit:
>>
>>   c5a1e183a75a ("bug.h: work around GCC PR82365 in BUG()")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (I just used the akpm-current 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.
>
> Kees,
>
> it seems you ran into the same issue that I did, and got the same fix
> for the first BUG() variant, but I think my version for the second one
> is slightly better:
>
>  /* This just causes an oops. */
> -#define BUG() (*(int *)0 = 0)
> +#define BUG()                                                          \
> +do {                                                                   \
> +       barrier_before_unreachable();                                   \
> +       __builtin_trap();                                               \
> +} while (0)
>
> compared to yours:
>
>  /* This just causes an oops. */
> -#define BUG() (*(int *)0 = 0)
> +#define BUG()                                                          \
> +do {                                                                   \
> +       (*(int *)0 = 0);                                                \
> +       do {} while (1);                                                \
> +       unreachable();                                                  \
> +} while (0)
>
> which relies on a NULL pointer dereference to trap but otherwise
> does the same thing. The easiest solution for the conflict seems to
> be that you just drop your patch.

Oh yeah, very nice. Yeah, yours is better. I'll drop mine.

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the kspp tree
  2018-01-15  4:57 Stephen Rothwell
@ 2018-01-15 12:41 ` Arnd Bergmann
  2018-01-15 20:07   ` Kees Cook
  0 siblings, 1 reply; 14+ messages in thread
From: Arnd Bergmann @ 2018-01-15 12:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Kees Cook, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   arch/cris/include/arch-v10/arch/bug.h
>
> between commit:
>
>   c8133e59edb0 ("cris: Mark end of BUG() implementation as unreachable")
>
> from the kspp tree and commit:
>
>   c5a1e183a75a ("bug.h: work around GCC PR82365 in BUG()")
>
> from the akpm-current tree.
>
> I fixed it up (I just used the akpm-current 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.

Kees,

it seems you ran into the same issue that I did, and got the same fix
for the first BUG() variant, but I think my version for the second one
is slightly better:

 /* This just causes an oops. */
-#define BUG() (*(int *)0 = 0)
+#define BUG()                                                          \
+do {                                                                   \
+       barrier_before_unreachable();                                   \
+       __builtin_trap();                                               \
+} while (0)

compared to yours:

 /* This just causes an oops. */
-#define BUG() (*(int *)0 = 0)
+#define BUG()                                                          \
+do {                                                                   \
+       (*(int *)0 = 0);                                                \
+       do {} while (1);                                                \
+       unreachable();                                                  \
+} while (0)

which relies on a NULL pointer dereference to trap but otherwise
does the same thing. The easiest solution for the conflict seems to
be that you just drop your patch.

       Arnd

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2018-01-15  4:57 Stephen Rothwell
  2018-01-15 12:41 ` Arnd Bergmann
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2018-01-15  4:57 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Arnd Bergmann

Hi Andrew,

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

  arch/cris/include/arch-v10/arch/bug.h

between commit:

  c8133e59edb0 ("cris: Mark end of BUG() implementation as unreachable")

from the kspp tree and commit:

  c5a1e183a75a ("bug.h: work around GCC PR82365 in BUG()")

from the akpm-current tree.

I fixed it up (I just used the akpm-current 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2017-11-02  8:05 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2017-11-02  8:05 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sasha Levin,
	David Windsor

Hi Andrew,

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

  kernel/fork.c

between commit:

  962b2ff950dd ("fork: Define usercopy region in mm_struct slab caches")
  41359fc82cc7 ("fork: Provide usercopy whitelisting for task_struct")

from the kspp tree and commit:

  9738ce7db723 ("kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK")

from the akpm-current 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/fork.c
index 87bc10bb2b5a,f28d946586c5..000000000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -481,14 -701,11 +717,14 @@@ void __init fork_init(void
  #define ARCH_MIN_TASKALIGN	0
  #endif
  	int align = max_t(int, L1_CACHE_BYTES, ARCH_MIN_TASKALIGN);
 +	unsigned long useroffset, usersize;
  
  	/* create a slab on which task_structs can be allocated */
 -	task_struct_cachep = kmem_cache_create("task_struct",
 +	task_struct_whitelist(&useroffset, &usersize);
 +	task_struct_cachep = kmem_cache_create_usercopy("task_struct",
  			arch_task_struct_size, align,
- 			SLAB_PANIC|SLAB_NOTRACK|SLAB_ACCOUNT,
 -			SLAB_PANIC|SLAB_ACCOUNT, NULL);
++			SLAB_PANIC|SLAB_ACCOUNT,
 +			useroffset, usersize, NULL);
  #endif
  
  	/* do the arch specific task caches init */
@@@ -2248,11 -2250,9 +2269,11 @@@ void __init proc_caches_init(void
  	 * maximum number of CPU's we can ever have.  The cpumask_allocation
  	 * is at the end of the structure, exactly for that reason.
  	 */
 -	mm_cachep = kmem_cache_create("mm_struct",
 +	mm_cachep = kmem_cache_create_usercopy("mm_struct",
  			sizeof(struct mm_struct), ARCH_MIN_MMSTRUCT_ALIGN,
- 			SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK|SLAB_ACCOUNT,
+ 			SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT,
 +			offsetof(struct mm_struct, saved_auxv),
 +			sizeof_field(struct mm_struct, saved_auxv),
  			NULL);
  	vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC|SLAB_ACCOUNT);
  	mmap_init();

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the kspp tree
  2017-06-20  5:15 Stephen Rothwell
@ 2017-07-03  1:31 ` Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2017-07-03  1:31 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Manfred Spraul

Hi all,

With the merge window opening, just a reminder that this conflict still
exists.

On Tue, 20 Jun 2017 15:15:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   include/linux/sem.h
> 
> between commit:
> 
>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
> 
> from the kspp tree and commit:
> 
>   337e62a32a54 ("ipc/sem.c: remove sem_base, embed struct sem")
> 
> from the akpm-current 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/sem.h
> index 23bcbdfad4a6,be5cf2ea14ad..000000000000
> --- a/include/linux/sem.h
> +++ b/include/linux/sem.h
> @@@ -21,7 -39,9 +39,9 @@@ struct sem_array 
>   	int			sem_nsems;	/* no. of semaphores in array */
>   	int			complex_count;	/* pending complex operations */
>   	unsigned int		use_global_lock;/* >0: global lock required */
> + 
> + 	struct sem		sems[];
>  -};
>  +} __randomize_layout;
>   
>   #ifdef CONFIG_SYSVIPC
>   

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2017-06-20  5:18 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2017-06-20  5:18 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Manfred Spraul

Hi all,

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

  include/linux/ipc.h

between commit:

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

from the kspp tree and commit:

  893106d6be17 ("ipc: merge ipc_rcu and kern_ipc_perm")

from the akpm-current 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/ipc.h
index ea0eb0b5f98c,5591f055e13f..000000000000
--- a/include/linux/ipc.h
+++ b/include/linux/ipc.h
@@@ -20,6 -20,9 +20,9 @@@ struct kern_ipc_perm 
  	umode_t		mode;
  	unsigned long	seq;
  	void		*security;
+ 
+ 	struct rcu_head rcu;
+ 	atomic_t refcount;
 -} ____cacheline_aligned_in_smp;
 +} ____cacheline_aligned_in_smp __randomize_layout;
  
  #endif /* _LINUX_IPC_H */

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2017-06-20  5:15 Stephen Rothwell
  2017-07-03  1:31 ` Stephen Rothwell
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2017-06-20  5:15 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Manfred Spraul

Hi all,

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

  include/linux/sem.h

between commit:

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

from the kspp tree and commit:

  337e62a32a54 ("ipc/sem.c: remove sem_base, embed struct sem")

from the akpm-current 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/sem.h
index 23bcbdfad4a6,be5cf2ea14ad..000000000000
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@@ -21,7 -39,9 +39,9 @@@ struct sem_array 
  	int			sem_nsems;	/* no. of semaphores in array */
  	int			complex_count;	/* pending complex operations */
  	unsigned int		use_global_lock;/* >0: global lock required */
+ 
+ 	struct sem		sems[];
 -};
 +} __randomize_layout;
  
  #ifdef CONFIG_SYSVIPC
  

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2017-02-17  4:53 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2017-02-17  4:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Jinbum Park, Laura Abbott

Hi all,

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

  arch/x86/Kconfig.debug
  arch/x86/kernel/Makefile

between commits:

  ad21fc4faa2a ("arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common")
  3ad38ceb2769 ("x86/mm: Remove CONFIG_DEBUG_NX_TEST")

from the kspp tree and commit:

  ae4aea38de49 ("mm: add arch-independent testcases for RODATA")

from the akpm-current 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/Kconfig.debug
index c4cba00dbdee,3fa469c82707..000000000000
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
diff --cc arch/x86/kernel/Makefile
index bdcdb3b3a219,f6caf829085a..000000000000
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@@ -100,7 -100,7 +100,6 @@@ obj-$(CONFIG_HPET_TIMER) 	+= hpet.
  obj-$(CONFIG_APB_TIMER)		+= apb_timer.o
  
  obj-$(CONFIG_AMD_NB)		+= amd_nb.o
- obj-$(CONFIG_DEBUG_RODATA_TEST)	+= test_rodata.o
 -obj-$(CONFIG_DEBUG_NX_TEST)	+= test_nx.o
  obj-$(CONFIG_DEBUG_NMI_SELFTEST) += nmi_selftest.o
  
  obj-$(CONFIG_KVM_GUEST)		+= kvm.o kvmclock.o

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2016-07-27  6:23 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2016-07-27  6:23 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Kees Cook

Hi Andrew,

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

  Makefile

between commit:

  228d96c603cf ("kbuild: Abort build on bad stack protector flag")

from the kspp tree and commit:

  f273155b8dc7 ("kbuild: abort build on bad stack protector flag")

from the akpm-current tree.

I fixed it up (I just arbitrarily used the version from the kspp 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.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the akpm-current tree with the kspp tree
@ 2016-06-22  4:58 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2016-06-22  4:58 UTC (permalink / raw)
  To: Andrew Morton, Kees Cook
  Cc: linux-next, linux-kernel, Emese Revfy, Vladimir Davydov

Hi Andrew,

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

  mm/page_alloc.c

between commit:

  0df42965deb7 ("latent_entropy: Add the extra_latent_entropy kernel parameter")

from the kspp tree and commit:

  6f4f5445297d ("mm: charge/uncharge kmemcg from generic page allocator paths")

from the akpm-current 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/page_alloc.c
index 02c7a0e6e66a,180f5afc5a1f..000000000000
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -63,7 -63,7 +63,8 @@@
  #include <linux/sched/rt.h>
  #include <linux/page_owner.h>
  #include <linux/kthread.h>
 +#include <linux/random.h>
+ #include <linux/memcontrol.h>
  
  #include <asm/sections.h>
  #include <asm/tlbflush.h>

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-03-03  8:15 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-25 10:37 linux-next: manual merge of the akpm-current tree with the kspp tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-03-03  8:15 Stephen Rothwell
2020-11-25 10:05 Stephen Rothwell
2019-02-13  6:03 Stephen Rothwell
2018-01-15  4:57 Stephen Rothwell
2018-01-15 12:41 ` Arnd Bergmann
2018-01-15 20:07   ` Kees Cook
2017-11-02  8:05 Stephen Rothwell
2017-06-20  5:18 Stephen Rothwell
2017-06-20  5:15 Stephen Rothwell
2017-07-03  1:31 ` Stephen Rothwell
2017-02-17  4:53 Stephen Rothwell
2016-07-27  6:23 Stephen Rothwell
2016-06-22  4:58 Stephen Rothwell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.