* linux-next: manual merge of the kvm-arm tree with the tip tree
From: Stephen Rothwell @ 2016-07-18 6:09 UTC (permalink / raw)
To: Christoffer Dall, Marc Zyngier, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Richard Cochran, Anna-Maria Gleixner
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
virt/kvm/arm/vgic.c
between commit:
42ec50b5f257 ("arm/kvm/vgic: Convert to hotplug state machine")
from the tip tree and commit:
50926d82fa27 ("KVM: arm/arm64: The GIC is dead, long live the GIC")
from the kvm-arm tree.
I fixed it up (the latter removed the file, so I did that -
CPUHP_AP_KVM_ARM_VGIC_STARTING should probably be removed as well) 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
* linux-next: manual merge of the kvm tree with the powerpc tree
From: Stephen Rothwell @ 2016-07-18 5:55 UTC (permalink / raw)
To: Marcelo Tosatti, Gleb Natapov, kvm, Michael Ellerman,
Benjamin Herrenschmidt, linuxppc-dev
Cc: linux-next, linux-kernel, Mahesh Salgaonkar, Paul Mackerras
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/powerpc/kernel/idle_book3s.S
between commit:
69c592ed40d3 ("powerpc/opal: Add real mode call wrappers")
from the powerpc tree and commit:
fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt")
from the kvm tree.
I fixed it up (on Michael's advise, I used the version form the kvm 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
* linux-next: manual merge of the kvm tree with the powerpc tree
From: Stephen Rothwell @ 2016-07-18 5:54 UTC (permalink / raw)
To: Marcelo Tosatti, Gleb Natapov, kvm, Michael Ellerman,
Benjamin Herrenschmidt, linuxppc-dev
Cc: linux-next, linux-kernel, Mahesh Salgaonkar, Paul Mackerras
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/powerpc/kernel/exceptions-64s.S
between commit:
9baaef0a22c8 ("powerpc/irq: Add support for HV virtualization interrupts")
from the powerpc tree and commit:
fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt")
from the kvm 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/powerpc/kernel/exceptions-64s.S
index 6200e4925d26,0eba47e074b9..000000000000
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@@ -669,8 -680,8 +669,10 @@@ _GLOBAL(__replay_interrupt
BEGIN_FTR_SECTION
cmpwi r3,0xe80
beq h_doorbell_common
+ cmpwi r3,0xea0
+ beq h_virt_irq_common
+ cmpwi r3,0xe60
+ beq hmi_exception_common
FTR_SECTION_ELSE
cmpwi r3,0xa00
beq doorbell_super_common
@@@ -1161,18 -1172,9 +1163,18 @@@ fwnmi_data_area
. = 0x8000
#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
+ STD_EXCEPTION_COMMON(0xf60, facility_unavailable, facility_unavailable_exception)
+ STD_EXCEPTION_COMMON(0xf80, hv_facility_unavailable, facility_unavailable_exception)
+
+#ifdef CONFIG_CBE_RAS
+ STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception)
+ STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception)
+ STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception)
+#endif /* CONFIG_CBE_RAS */
+
.globl hmi_exception_early
hmi_exception_early:
- EXCEPTION_PROLOG_1(PACA_EXGEN, NOTEST, 0xe60)
+ EXCEPTION_PROLOG_1(PACA_EXGEN, KVMTEST, 0xe62)
mr r10,r1 /* Save r1 */
ld r1,PACAEMERGSP(r13) /* Use emergency stack */
subi r1,r1,INT_FRAME_SIZE /* alloc stack frame */
^ permalink raw reply
* linux-next: manual merge of the rcu tree with the tip tree
From: Stephen Rothwell @ 2016-07-18 5:26 UTC (permalink / raw)
To: Paul E. McKenney, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra
Cc: linux-next, linux-kernel, Anna-Maria Gleixner
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in:
kernel/rcu/tree.c
between commit:
4df8374254ea ("rcu: Convert rcutree to hotplug state machine")
from the tip tree and commit:
2a84cde733b0 ("rcu: Exact CPU-online tracking for RCU")
from the rcu 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/rcu/tree.c
index e5164deb51e1,5663d1e899d3..000000000000
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@@ -3812,54 -3809,34 +3809,80 @@@ int rcutree_prepare_cpu(unsigned int cp
for_each_rcu_flavor(rsp)
rcu_init_percpu_data(cpu, rsp);
+
+ rcu_prepare_kthreads(cpu);
+ rcu_spawn_all_nocb_kthreads(cpu);
+
+ return 0;
+}
+
+static void rcutree_affinity_setting(unsigned int cpu, int outgoing)
+{
+ struct rcu_data *rdp = per_cpu_ptr(rcu_state_p->rda, cpu);
+
+ rcu_boost_kthread_setaffinity(rdp->mynode, outgoing);
+}
+
+int rcutree_online_cpu(unsigned int cpu)
+{
+ sync_sched_exp_online_cleanup(cpu);
+ rcutree_affinity_setting(cpu, -1);
+ return 0;
+}
+
+int rcutree_offline_cpu(unsigned int cpu)
+{
+ rcutree_affinity_setting(cpu, cpu);
+ return 0;
+}
+
+
+int rcutree_dying_cpu(unsigned int cpu)
+{
+ struct rcu_state *rsp;
+
+ for_each_rcu_flavor(rsp)
+ rcu_cleanup_dying_cpu(rsp);
+ return 0;
+}
+
+int rcutree_dead_cpu(unsigned int cpu)
+{
+ struct rcu_state *rsp;
+
+ for_each_rcu_flavor(rsp) {
+ rcu_cleanup_dead_cpu(cpu, rsp);
+ do_nocb_deferred_wakeup(per_cpu_ptr(rsp->rda, cpu));
+ }
+ return 0;
}
+ /*
+ * Mark the specified CPU as being online so that subsequent grace periods
+ * (both expedited and normal) will wait on it. Note that this means that
+ * incoming CPUs are not allowed to use RCU read-side critical sections
+ * until this function is called. Failing to observe this restriction
+ * will result in lockdep splats.
+ */
+ void rcu_cpu_starting(unsigned int cpu)
+ {
+ unsigned long flags;
+ unsigned long mask;
+ struct rcu_data *rdp;
+ struct rcu_node *rnp;
+ struct rcu_state *rsp;
+
+ for_each_rcu_flavor(rsp) {
+ rdp = this_cpu_ptr(rsp->rda);
+ rnp = rdp->mynode;
+ mask = rdp->grpmask;
+ raw_spin_lock_irqsave_rcu_node(rnp, flags);
+ rnp->qsmaskinitnext |= mask;
+ rnp->expmaskinitnext |= mask;
+ raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+ }
+ }
+
#ifdef CONFIG_HOTPLUG_CPU
/*
* The CPU is exiting the idle loop into the arch_cpu_idle_dead()
@@@ -4208,9 -4231,12 +4231,11 @@@ void __init rcu_init(void
* this is called early in boot, before either interrupts
* or the scheduler are operational.
*/
- cpu_notifier(rcu_cpu_notify, 0);
pm_notifier(rcu_pm_notify, 0);
- for_each_online_cpu(cpu)
+ for_each_online_cpu(cpu) {
- rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
+ rcutree_prepare_cpu(cpu);
+ rcu_cpu_starting(cpu);
+ }
}
#include "tree_exp.h"
^ permalink raw reply
* Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree
From: Stephen Rothwell @ 2016-07-18 5:18 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel,
Arnaldo Carvalho de Melo
In-Reply-To: <20160715154326.GC2523@redhat.com>
Hi Arnaldo,
On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>
> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> for you?
Sorry, no. See my other email.
I am cross building (if that makes a difference).
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build failure after merge of the tip tree
From: Stephen Rothwell @ 2016-07-18 5:15 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Arnaldo Carvalho de Melo,
Andy Lutomirski, Arnaldo Carvalho de Melo
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
from tools/include/linux/types.h:9,
from tools/include/linux/list.h:4,
from elf.h:23,
from builtin-check.c:33:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
#error Inconsistent word size. Check asm/bitsperlong.h
^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
from tools/include/linux/types.h:9,
from tools/include/linux/string.h:5,
from ../lib/str_error_r.c:4:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
#error Inconsistent word size. Check asm/bitsperlong.h
^
cat: /home/sfr/next/x86_64_allmodconfig/tools/objtool/.str_error_r.o.d: No such file or directory
Build:17: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/str_error_r.o' failed
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
from tools/include/linux/types.h:9,
from tools/include/linux/list.h:4,
from elf.h:23,
from special.h:22,
from special.c:26:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
#error Inconsistent word size. Check asm/bitsperlong.h
^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
from tools/include/linux/types.h:9,
from tools/include/linux/string.h:5,
from ../lib/string.c:18:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
#error Inconsistent word size. Check asm/bitsperlong.h
^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
from tools/include/linux/types.h:9,
from tools/include/linux/list.h:4,
from elf.h:23,
from elf.c:30:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
#error Inconsistent word size. Check asm/bitsperlong.h
^
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
from tools/include/linux/types.h:9,
from tools/include/linux/list.h:4,
from arch/x86/../../elf.h:23,
from arch/x86/decode.c:26:
tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
#error Inconsistent word size. Check asm/bitsperlong.h
^
Makefile:42: recipe for target '/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool-in.o' failed
Makefile:60: recipe for target 'objtool' failed
I have added this patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Jul 2016 14:58:39 +1000
Subject: [PATCH] tools: Simplify __BITS_PER_LONG define
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
tools/include/asm-generic/bitsperlong.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index 45eca517efb3..f46853474fd3 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -10,7 +10,8 @@
#endif
#if BITS_PER_LONG != __BITS_PER_LONG
-#error Inconsistent word size. Check asm/bitsperlong.h
+#undef __BITS_PER_LONG
+#define __BITS_PER_LONG BITS_PER_LONG
#endif
#ifndef BITS_PER_LONG_LONG
--
2.8.1
--
Cheers,
Stephen Rothwell
^ permalink raw reply related
* Re: linux-next: manual merge of the kspp tree with the arm64 tree
From: Kees Cook @ 2016-07-18 5:14 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Catalin Marinas, Linux-Next, LKML, Yang Shi
In-Reply-To: <20160718150602.1c8f1896@canb.auug.org.au>
On Sun, Jul 17, 2016 at 10:06 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> On Sun, 17 Jul 2016 21:49:40 -0700 Kees Cook <keescook@google.com> wrote:
>>
>> If I'm reading correctly, this second fixup is wrong. It should read;
>>
>> kasan_check_read(from, n);
>> check_object_size(from, n, true);
>> return __arch_copy_to_user(to, from, n);
>>
>> (i.e. fix double space between "return" and "__arch_copy..." in both
>> chunks and add check_object_size() calls after the kasan calls in both
>> chunks.
>
> Yep, sorry. I will fix it up tomorrow.
Cool, thanks! :)
-Kees
--
Kees Cook
Brillo & Chrome OS Security
^ permalink raw reply
* Re: linux-next: manual merge of the kspp tree with the arm64 tree
From: Stephen Rothwell @ 2016-07-18 5:06 UTC (permalink / raw)
To: Kees Cook; +Cc: Catalin Marinas, Linux-Next, LKML, Yang Shi
In-Reply-To: <CAGXu5jL-=N8cxoLmfNhG-1Pa864MQBbue1SyBQo-HsuOH41_nQ@mail.gmail.com>
Hi Kees,
On Sun, 17 Jul 2016 21:49:40 -0700 Kees Cook <keescook@google.com> wrote:
>
> If I'm reading correctly, this second fixup is wrong. It should read;
>
> kasan_check_read(from, n);
> check_object_size(from, n, true);
> return __arch_copy_to_user(to, from, n);
>
> (i.e. fix double space between "return" and "__arch_copy..." in both
> chunks and add check_object_size() calls after the kasan calls in both
> chunks.
Yep, sorry. I will fix it up tomorrow.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the kspp tree with the arm64 tree
From: Kees Cook @ 2016-07-18 4:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Catalin Marinas, Linux-Next, LKML, Yang Shi
In-Reply-To: <20160718125944.19ebe679@canb.auug.org.au>
On Sun, Jul 17, 2016 at 7:59 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> Today's linux-next merge of the kspp tree got a conflict in:
>
> arch/arm64/include/asm/uaccess.h
>
> between commit:
>
> bffe1baff5d5 ("arm64: kasan: instrument user memory access API")
>
> from the arm64 tree and commit:
>
> b19e7f50f056 ("arm64/uaccess: Enable hardened usercopy")
>
> 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/include/asm/uaccess.h
> index 5e834d10b291,1779cbdb7838..000000000000
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@@ -264,14 -276,14 +264,15 @@@ extern unsigned long __must_check __cle
>
> static inline unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n)
> {
> + kasan_check_write(to, n);
> - return __arch_copy_from_user(to, from, n);
> + check_object_size(to, n, false);
> + return __arch_copy_from_user(to, from, n);
> }
>
> static inline unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n)
> {
> - check_object_size(from, n, true);
> + kasan_check_read(from, n);
> - return __arch_copy_to_user(to, from, n);
> + return __arch_copy_to_user(to, from, n);
If I'm reading correctly, this second fixup is wrong. It should read;
kasan_check_read(from, n);
check_object_size(from, n, true);
return __arch_copy_to_user(to, from, n);
(i.e. fix double space between "return" and "__arch_copy..." in both
chunks and add check_object_size() calls after the kasan calls in both
chunks.
-Kees
--
Kees Cook
Brillo & Chrome OS Security
^ permalink raw reply
* linux-next: manual merge of the device-mapper tree with the block tree
From: Stephen Rothwell @ 2016-07-18 4:09 UTC (permalink / raw)
To: Alasdair G Kergon, Mike Snitzer, Jens Axboe
Cc: linux-next, linux-kernel, Toshi Kani, Christoph Hellwig
Hi all,
Today's linux-next merge of the device-mapper tree got a conflict in:
include/linux/blkdev.h
between commit:
288dab8a35a0 ("block: add a separate operation type for secure erase")
from the block tree and commit:
ff6bbdd8ef75 ("block: add QUEUE_FLAG_DAX for devices to advertise their DAX support")
from the device-mapper 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/blkdev.h
index 9ae49ccaac95,1493ab3a537f..000000000000
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@@ -592,8 -593,9 +593,9 @@@ static inline void queue_flag_clear(uns
#define blk_queue_stackable(q) \
test_bit(QUEUE_FLAG_STACKABLE, &(q)->queue_flags)
#define blk_queue_discard(q) test_bit(QUEUE_FLAG_DISCARD, &(q)->queue_flags)
-#define blk_queue_secdiscard(q) (blk_queue_discard(q) && \
- test_bit(QUEUE_FLAG_SECDISCARD, &(q)->queue_flags))
+#define blk_queue_secure_erase(q) \
+ (test_bit(QUEUE_FLAG_SECERASE, &(q)->queue_flags))
+ #define blk_queue_dax(q) test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags)
#define blk_noretry_request(rq) \
((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
^ permalink raw reply
* linux-next: manual merge of the kspp tree with the powerpc tree
From: Stephen Rothwell @ 2016-07-18 3:03 UTC (permalink / raw)
To: Kees Cook, Michael Ellerman, Benjamin Herrenschmidt, linuxppc-dev
Cc: linux-next, linux-kernel, Christophe Leroy
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
arch/powerpc/Kconfig
between commit:
c223c90386bc ("powerpc32: provide VIRT_CPU_ACCOUNTING")
from the powerpc tree and commit:
006d998dda94 ("powerpc/uaccess: Enable hardened usercopy")
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.
Michael: time to sort these selects?
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/Kconfig
index fcfe5332416f,b7a18b2604be..000000000000
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -165,7 -164,7 +165,8 @@@ config PP
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
+ select HAVE_VIRT_CPU_ACCOUNTING
+ select HAVE_ARCH_HARDENED_USERCOPY
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
^ permalink raw reply
* linux-next: manual merge of the kspp tree with the arm64 tree
From: Stephen Rothwell @ 2016-07-18 2:59 UTC (permalink / raw)
To: Kees Cook, Catalin Marinas; +Cc: linux-next, linux-kernel, Yang Shi
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
arch/arm64/include/asm/uaccess.h
between commit:
bffe1baff5d5 ("arm64: kasan: instrument user memory access API")
from the arm64 tree and commit:
b19e7f50f056 ("arm64/uaccess: Enable hardened usercopy")
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/include/asm/uaccess.h
index 5e834d10b291,1779cbdb7838..000000000000
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@@ -264,14 -276,14 +264,15 @@@ extern unsigned long __must_check __cle
static inline unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n)
{
+ kasan_check_write(to, n);
- return __arch_copy_from_user(to, from, n);
+ check_object_size(to, n, false);
+ return __arch_copy_from_user(to, from, n);
}
static inline unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n)
{
- check_object_size(from, n, true);
+ kasan_check_read(from, n);
- return __arch_copy_to_user(to, from, n);
+ return __arch_copy_to_user(to, from, n);
}
static inline unsigned long __must_check copy_from_user(void *to, const void __user *from, unsigned long n)
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-07-18 1:59 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Kiran Patil, Jeff Kirsher,
Mitch Williams
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/intel/i40e/i40e_main.c
between commit:
f6bd09625ba6 ("i40e: enable VSI broadcast promiscuous mode instead of adding broadcast filter")
from the net tree and commit:
3e25a8f31af1 ("i40e: add hw struct local variable")
from the net-next 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 drivers/net/ethernet/intel/i40e/i40e_main.c
index eb09f60b4984,2b1140563a64..000000000000
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@@ -2152,12 -2165,27 +2172,15 @@@ int i40e_sync_vsi_filters(struct i40e_v
if (aq_ret) {
retval =
i40e_aq_rc_to_posix(aq_ret,
- pf->hw.aq.asq_last_status);
+ hw->aq.asq_last_status);
dev_info(&pf->pdev->dev,
- "set multicast promisc failed, err %d, aq_err %d\n",
- aq_ret, pf->hw.aq.asq_last_status);
+ "set multicast promisc failed on %s, err %s, aq_err %s\n",
+ vsi_name,
+ i40e_stat_str(hw, aq_ret),
+ i40e_aq_str(hw,
+ hw->aq.asq_last_status));
}
}
- aq_ret = i40e_aq_set_vsi_broadcast(&vsi->back->hw,
- vsi->seid,
- cur_promisc, NULL);
- if (aq_ret) {
- retval = i40e_aq_rc_to_posix(aq_ret,
- pf->hw.aq.asq_last_status);
- dev_info(&pf->pdev->dev,
- "set brdcast promisc failed, err %s, aq_err %s\n",
- i40e_stat_str(hw, aq_ret),
- i40e_aq_str(hw,
- hw->aq.asq_last_status));
- }
}
out:
/* if something went wrong then set the changed flag so we try again */
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-07-18 1:52 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Florian Fainelli, Raghu Vatsavayi,
Derek Chickles, Satanand Burla, Felix Manlunas
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/cavium/liquidio/lio_main.c
between commit:
8e6ce7ebeb34 ("net: cavium: liquidio: Avoid dma_unmap_single on uninitialized ndata")
from the net tree and commit:
6a885b60dad2 ("liquidio: Introduce new octeon2/3 header")
from the net-next tree.
I am not sure how to fix this up, so I effectively reverted the net
tree commit. Please let me know if something else should be done.
I fixed it up (see above) 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
* Re: linux-next: manual merge of the pm tree with the i2c tree
From: Wolfram Sang @ 2016-07-17 18:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, linux-next, linux-kernel, Octavian Purdila,
Jarkko Nikula, Andy Shevchenko, Mika Westerberg
In-Reply-To: <2196027.ndrBocBl2R@vostro.rjw.lan>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
> > > > > I fixed it up (I think, but it needs more work - see below) and can
> > > >
> > > > For a start, it generates this warning, now:
> > > >
> > > > drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
> > > > static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
> > > > ^
> > >
> > > OK, thanks for the heads-up.
> >
> > Yes, thanks!
> >
> > >
> > > Wolfram, what about if I exposed my "acpi-tables" branch for you to pull?
> > >
> > > You could resolve this in your tree then.
> >
> > I can pull it in, sure. For the fixup, I'd like a commitment from one of
> > the ACPI experts (Jarkko, Mika, Andy), though. Otherwise I'd need to
> > revert given that we are quite late in the cycle already.
>
> The branch is here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-tables
>
> The top-most commit is:
>
> fafe5306f201 ACPI: Rename configfs.c to acpi_configfs.c to prevent link error
>
> I won't rebase this branch going forward, so it is safe to pull.
>
> Please let me know how I can help with the conflict resolution.
Well, not knowing much about ACPI, I just need the conflict resolution
for my latest i2c/for-next and your above branch. If you want to do it,
fine with me. But maybe Jarkko will be back to office on Monday, too.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Good Day
From: Saeed Bin Salem @ 2016-07-16 6:48 UTC (permalink / raw)
To: Recipients
I am Mr.Saeed Bin Salem Executive Director and Chief Financial Officer of the National Commercial Bank Libya.I have a secured business suggestion for you reply me on my email: salemx@foxmail.com
^ permalink raw reply
* Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree
From: H. Peter Anvin @ 2016-07-15 20:26 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Peter Zijlstra
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
linux-next, linux-kernel, Arnaldo Carvalho de Melo
In-Reply-To: <20160715162800.GE2523@redhat.com>
On 07/15/16 09:28, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
>> On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
>>> Ok, same results, it works, queuing this one, ack?
>>
>> Sure. Although I'm still somewhat puzzled by the duplicated effort of
>> __BITS_PER_LONG and BITS_PER_LONG.
>
> Well, I also can't think of something to justify that, would have to dig
> deeper to figure out why that duplication was introduced.
>
> Thanks, will queue this one up and be done with it. For the moment. :-)
>
I'm wondering if there are issues related to compat.
-hpa
^ permalink raw reply
* Re: linux-next: manual merge of the clockevents tree with the arm-soc tree
From: Daniel Lezcano @ 2016-07-15 17:06 UTC (permalink / raw)
To: Stephen Rothwell, Olof Johansson, Arnd Bergmann, linux-arm-kernel,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Alexander Shiyan
In-Reply-To: <20160711152812.3efd7047@canb.auug.org.au>
On 07/11/2016 07:28 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 7 Jul 2016 14:12:26 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the clockevents tree got a conflict in:
>>
>> arch/arm/Kconfig
>>
>> between commit:
>>
>> c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
>>
>> from the arm-soc tree and commit:
>>
>> 250e46aa3bb3 ("clocksource/drivers/clps_711x: Add the COMPILE_TEST option")
>>
>> from the clockevents tree.
>>
>> I fixed it up (I used the arm-soc version of this file and then added
>> the following merge fix patch) 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.
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Thu, 7 Jul 2016 13:59:06 +1000
>> Subject: [PATCH] clocksource/drivers/clps_711x: fixup for "ARM: clps711x: Switch to MULTIPLATFORM"
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> arch/arm/mach-clps711x/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-clps711x/Kconfig b/arch/arm/mach-clps711x/Kconfig
>> index 3b56197ccfd0..dc7c6edeab39 100644
>> --- a/arch/arm/mach-clps711x/Kconfig
>> +++ b/arch/arm/mach-clps711x/Kconfig
>> @@ -3,8 +3,8 @@ menuconfig ARCH_CLPS711X
>> depends on ARCH_MULTI_V4T
>> select ARCH_REQUIRE_GPIOLIB
>> select AUTO_ZRELADDR
>> - select CLKSRC_MMIO
>> select CLKSRC_OF
>> + select CLPS711X_TIMER
>> select COMMON_CLK
>> select CPU_ARM720T
>> select GENERIC_CLOCKEVENTS
>> --
>> 2.8.1
>
> This merge fix is now applicable to the merge between the arm-soc tree
> and the tip tree.
>
> Also, the clockevents tree needs to be cleaned up as all its commits
> have been added to the tip tree as different commits (but the s
> patches) :-(
I synced the branch with tip/timers/core, no more conflict should happen.
Thanks.
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree
From: Arnaldo Carvalho de Melo @ 2016-07-15 16:28 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel,
Arnaldo Carvalho de Melo
In-Reply-To: <20160715154930.GC3115@twins.programming.kicks-ass.net>
Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
> > Ok, same results, it works, queuing this one, ack?
>
> Sure. Although I'm still somewhat puzzled by the duplicated effort of
> __BITS_PER_LONG and BITS_PER_LONG.
Well, I also can't think of something to justify that, would have to dig
deeper to figure out why that duplication was introduced.
Thanks, will queue this one up and be done with it. For the moment. :-)
- Arnaldo
> > commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
> > Author: Peter Zijlstra <peterz@infradead.org>
> > Date: Fri Jul 15 12:38:18 2016 -0300
> >
> > tools: Simplify BITS_PER_LONG define
> >
> > Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
> > reduces the complexity by ditching CONFIG_64BIT, that was being
> > synthesized from yet another set of defines, which proved fragile,
> > breaking the build on linux-next for no obvious reasons.
>
> If you ever do need to introduce CONFIG_64BIT, __LP64__ seems like the
> right symbol to use for it.
^ permalink raw reply
* Re: linux-next: build failure after merge of the luto-misc tree
From: Arnaldo Carvalho de Melo @ 2016-07-15 15:56 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel,
Arnaldo Carvalho de Melo
In-Reply-To: <20160715152937.GB3115@twins.programming.kicks-ass.net>
Em Fri, Jul 15, 2016 at 05:29:37PM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo wrote:
> > Seems ok, but I'll reinstate this:
> >
> > #if BITS_PER_LONG != __BITS_PER_LONG
> > #error Inconsistent word size. Check asm/bitsperlong.h
> > #endif
>
> Confuses me; why do we have two?
>
> Why not then do:
>
> #define BITS_PER_LONG __BITS_PER_LONG
>
> and be done with it?
Well, I just kept existing kernel practice, it uses __BITS_PER_LONG in
uapi files and BITS_PER_LONG elsewhere, since we copy stuff from the
kernel and check when it drifts using diff, I kept it like that so that
automation could point us when the tools/ copy drifted from the original
file.
- Arnaldo
^ permalink raw reply
* Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree
From: Peter Zijlstra @ 2016-07-15 15:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel,
Arnaldo Carvalho de Melo
In-Reply-To: <20160715154326.GC2523@redhat.com>
On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Ok, same results, it works, queuing this one, ack?
Sure. Although I'm still somewhat puzzled by the duplicated effort of
__BITS_PER_LONG and BITS_PER_LONG.
> commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
> Author: Peter Zijlstra <peterz@infradead.org>
> Date: Fri Jul 15 12:38:18 2016 -0300
>
> tools: Simplify BITS_PER_LONG define
>
> Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
> reduces the complexity by ditching CONFIG_64BIT, that was being
> synthesized from yet another set of defines, which proved fragile,
> breaking the build on linux-next for no obvious reasons.
If you ever do need to introduce CONFIG_64BIT, __LP64__ seems like the
right symbol to use for it.
^ permalink raw reply
* [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree
From: Arnaldo Carvalho de Melo @ 2016-07-15 15:43 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel,
Arnaldo Carvalho de Melo
In-Reply-To: <20160715152436.GB2523@redhat.com>
Em Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Jul 15, 2016 at 12:09:03PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
> > > On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> > > > All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.
> > > > (and I checked most everything from 4.4 - 6.1)
> > > clang-3.8 also defines all three of those, and I don't consider that a
> > > usable compiler as it doesn't even build a kernel.
> > I was trying to have that file as close to the kernel as possible, but
> > I'll try building with your patch in my test rig, lets see if one of the
> > dozens of distros/releases barf at that...
> Seems ok, but I'll reinstate this:
> #if BITS_PER_LONG != __BITS_PER_LONG
> #error Inconsistent word size. Check asm/bitsperlong.h
> #endif
> And now I'm rerunning these tests, that without the above check
Ok, same results, it works, queuing this one, ack? Stephen, does it work
for you?
commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
Author: Peter Zijlstra <peterz@infradead.org>
Date: Fri Jul 15 12:38:18 2016 -0300
tools: Simplify BITS_PER_LONG define
Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
reduces the complexity by ditching CONFIG_64BIT, that was being
synthesized from yet another set of defines, which proved fragile,
breaking the build on linux-next for no obvious reasons.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160715072243.GP30154@twins.programming.kicks-ass.net
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c6fc17..4c7a9ab42424 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -3,30 +3,7 @@
#include <uapi/asm-generic/bitsperlong.h>
-/*
- * In the kernel, where this file comes from, we can rely on CONFIG_64BIT,
- * here we have to make amends with what the various compilers provides us
- * to figure out if we're on a 64-bit machine...
- */
-#ifdef __SIZEOF_LONG__
-# if __SIZEOF_LONG__ == 8
-# define CONFIG_64BIT
-# endif
-#else
-# ifdef __WORDSIZE
-# if __WORDSIZE == 64
-# define CONFIG_64BIT
-# endif
-# else
-# error Failed to determine BITS_PER_LONG value
-# endif
-#endif
-
-#ifdef CONFIG_64BIT
-#define BITS_PER_LONG 64
-#else
-#define BITS_PER_LONG 32
-#endif /* CONFIG_64BIT */
+#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
#if BITS_PER_LONG != __BITS_PER_LONG
#error Inconsistent word size. Check asm/bitsperlong.h
^ permalink raw reply related
* Re: linux-next: build failure after merge of the luto-misc tree
From: Peter Zijlstra @ 2016-07-15 15:29 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel
In-Reply-To: <20160715152436.GB2523@redhat.com>
On Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Seems ok, but I'll reinstate this:
>
> #if BITS_PER_LONG != __BITS_PER_LONG
> #error Inconsistent word size. Check asm/bitsperlong.h
> #endif
Confuses me; why do we have two?
Why not then do:
#define BITS_PER_LONG __BITS_PER_LONG
and be done with it?
^ permalink raw reply
* Re: linux-next: build failure after merge of the luto-misc tree
From: Arnaldo Carvalho de Melo @ 2016-07-15 15:24 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel
In-Reply-To: <20160715150903.GA2523@redhat.com>
Em Fri, Jul 15, 2016 at 12:09:03PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
> > On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> > > On Fri, Jul 15, 2016 at 05:06:54PM +1000, Stephen Rothwell wrote:
> > > > interacting with commit
> > > >
> > > > 2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")
> > > >
> > > > from the tip tree.
> > >
> > > Yuck.. that thing is horrid :/
> > >
> > > What's wrong with so?
> > >
> > > And if you really want to retain CONFIG_64BIT (because other headers
> > > might want it, and they currently do not) then do something like:
> > >
> > > #ifdef __LP64__
> > > #define CONFIG_64BIT
> > > #else
> > > #define CONFIG_32BIT
> > > #endif
> > >
> > > All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.
> > >
> > > (and I checked most everything from 4.4 - 6.1)
> >
> > clang-3.8 also defines all three of those, and I don't consider that a
> > usable compiler as it doesn't even build a kernel.
>
> I was trying to have that file as close to the kernel as possible, but
> I'll try building with your patch in my test rig, lets see if one of the
> dozens of distros/releases barf at that...
Seems ok, but I'll reinstate this:
#if BITS_PER_LONG != __BITS_PER_LONG
#error Inconsistent word size. Check asm/bitsperlong.h
#endif
And now I'm rerunning these tests, that without the above check
produces:
# dm
alpine:3.4: Ok
android-ndk:r12b: Ok
centos:5: perf: Ok, objtool: FAIL # But this one predates this patch, I'll fix it
centos:6: Ok
centos:7: Ok
debian:7: Ok
debian:8: Ok
debian:experimental: Ok
fedora:21: Ok
fedora:22: Ok
fedora:23: Ok
fedora:24: Ok
fedora:rawhide: Ok
opensuse:13.2: Ok
opensuse:42.1: Ok
ubuntu:14.04.4: Ok
ubuntu:15.10: Ok
ubuntu:16.04: Ok
#
- Arnaldo
^ permalink raw reply
* Re: linux-next: build failure after merge of the luto-misc tree
From: Arnaldo Carvalho de Melo @ 2016-07-15 15:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linux-next, linux-kernel
In-Reply-To: <20160715073119.GR30927@twins.programming.kicks-ass.net>
Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 05:06:54PM +1000, Stephen Rothwell wrote:
> > > interacting with commit
> > >
> > > 2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")
> > >
> > > from the tip tree.
> >
> > Yuck.. that thing is horrid :/
> >
> > What's wrong with so?
> >
> > And if you really want to retain CONFIG_64BIT (because other headers
> > might want it, and they currently do not) then do something like:
> >
> > #ifdef __LP64__
> > #define CONFIG_64BIT
> > #else
> > #define CONFIG_32BIT
> > #endif
> >
> > All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.
> >
> > (and I checked most everything from 4.4 - 6.1)
>
> clang-3.8 also defines all three of those, and I don't consider that a
> usable compiler as it doesn't even build a kernel.
I was trying to have that file as close to the kernel as possible, but
I'll try building with your patch in my test rig, lets see if one of the
dozens of distros/releases barf at that...
- Arnaldo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox