linux-next: manual merge of the akpm-current tree with the kspp tree

2020-11-25 Thread Stephen Rothwell
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..
--- 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"


pgpt8Mv9NkHnB.pgp
Description: OpenPGP digital signature


linux-next: manual merge of the akpm-current tree with the kspp tree

2019-02-12 Thread Stephen Rothwell
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..
--- 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/
  


pgpFIoL990Hqx.pgp
Description: OpenPGP digital signature


Re: linux-next: manual merge of the akpm-current tree with the kspp tree

2018-01-15 Thread Kees Cook
On Mon, Jan 15, 2018 at 4:41 AM, Arnd Bergmann  wrote:
> On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwell  
> 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


Re: linux-next: manual merge of the akpm-current tree with the kspp tree

2018-01-15 Thread Kees Cook
On Mon, Jan 15, 2018 at 4:41 AM, Arnd Bergmann  wrote:
> On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwell  
> 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


Re: linux-next: manual merge of the akpm-current tree with the kspp tree

2018-01-15 Thread Arnd Bergmann
On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwell  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


Re: linux-next: manual merge of the akpm-current tree with the kspp tree

2018-01-15 Thread Arnd Bergmann
On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwell  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


linux-next: manual merge of the akpm-current tree with the kspp tree

2018-01-14 Thread Stephen Rothwell
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


linux-next: manual merge of the akpm-current tree with the kspp tree

2018-01-14 Thread Stephen Rothwell
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


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-11-02 Thread Stephen Rothwell
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..
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -481,14 -701,11 +717,14 @@@ void __init fork_init(void
  #define ARCH_MIN_TASKALIGN0
  #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(, );
 +  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();


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-11-02 Thread Stephen Rothwell
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..
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -481,14 -701,11 +717,14 @@@ void __init fork_init(void
  #define ARCH_MIN_TASKALIGN0
  #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(, );
 +  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();


Re: linux-next: manual merge of the akpm-current tree with the kspp tree

2017-07-02 Thread Stephen Rothwell
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  
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..
> --- 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 intuse_global_lock;/* >0: global lock required */
> + 
> + struct sem  sems[];
>  -};
>  +} __randomize_layout;
>   
>   #ifdef CONFIG_SYSVIPC
>   

-- 
Cheers,
Stephen Rothwell


Re: linux-next: manual merge of the akpm-current tree with the kspp tree

2017-07-02 Thread Stephen Rothwell
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  
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..
> --- 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 intuse_global_lock;/* >0: global lock required */
> + 
> + struct sem  sems[];
>  -};
>  +} __randomize_layout;
>   
>   #ifdef CONFIG_SYSVIPC
>   

-- 
Cheers,
Stephen Rothwell


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-06-19 Thread Stephen Rothwell
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..
--- 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 */


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-06-19 Thread Stephen Rothwell
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..
--- 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 */


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-06-19 Thread Stephen Rothwell
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..
--- 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 intuse_global_lock;/* >0: global lock required */
+ 
+   struct sem  sems[];
 -};
 +} __randomize_layout;
  
  #ifdef CONFIG_SYSVIPC
  


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-06-19 Thread Stephen Rothwell
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..
--- 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 intuse_global_lock;/* >0: global lock required */
+ 
+   struct sem  sems[];
 -};
 +} __randomize_layout;
  
  #ifdef CONFIG_SYSVIPC
  


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-02-16 Thread Stephen Rothwell
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..
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
diff --cc arch/x86/kernel/Makefile
index bdcdb3b3a219,f6caf829085a..
--- 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


linux-next: manual merge of the akpm-current tree with the kspp tree

2017-02-16 Thread Stephen Rothwell
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..
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
diff --cc arch/x86/kernel/Makefile
index bdcdb3b3a219,f6caf829085a..
--- 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


linux-next: manual merge of the akpm-current tree with the kspp tree

2016-07-27 Thread Stephen Rothwell
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


linux-next: manual merge of the akpm-current tree with the kspp tree

2016-07-27 Thread Stephen Rothwell
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


linux-next: manual merge of the akpm-current tree with the kspp tree

2016-06-21 Thread Stephen Rothwell
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..
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -63,7 -63,7 +63,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include 
  #include 


linux-next: manual merge of the akpm-current tree with the kspp tree

2016-06-21 Thread Stephen Rothwell
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..
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@@ -63,7 -63,7 +63,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include 
  #include