linux-next: manual merge of the akpm-current tree with the kspp tree
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
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
On Mon, Jan 15, 2018 at 4:41 AM, Arnd Bergmannwrote: > 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
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
On Mon, Jan 15, 2018 at 5:57 AM, Stephen Rothwellwrote: > 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
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
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
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
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
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
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 Rothwellwrote: > > 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
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
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
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
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
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
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
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
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
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
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
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