Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

Just for the records...

[ OBJDUMP irq_work_tick() ]

$ objdump -d -S --start-address=0x$(grep irq_work_tick System.map |
sed -e "s/ \+.*//") vmlinux | less

[ OBJDUMP native_save_fl() ]

$ objdump -d -S --start-address=0x$(grep native_save_fl System.map |
sed -e "s/ \+.*//") vmlinux | less

- sedat -
[ OBJDUMP irq_work_tick() ]

$ objdump -d -S --start-address=0x$(grep irq_work_tick System.map | sed -e "s/ 
\+.*//") vmlinux | less

vmlinux: file format elf64-x86-64


Disassembly of section .text:

811982f0 :
irq_work_run_list(this_cpu_ptr(_list));
}
EXPORT_SYMBOL_GPL(irq_work_run);

void irq_work_tick(void)
{
811982f0:   41 57   push   %r15
811982f2:   41 56   push   %r14
811982f4:   41 54   push   %r12
811982f6:   53  push   %rbx
struct llist_head *raised = this_cpu_ptr(_list);
811982f7:   48 c7 c1 80 e5 01 00mov$0x1e580,%rcx
811982fe:   65 48 03 0c 25 d8 f1add%gs:0xf1d8,%rcx
81198305:   00 00 
 * test whether the list is empty without deleting something from the
 * list.
 */
static inline bool llist_empty(const struct llist_head *head)
{
return ACCESS_ONCE(head->first) == NULL;
81198307:   48 83 39 00 cmpq   $0x0,(%rcx)

if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
8119830b:   74 6a   je 81198377 

}

static __always_inline bool constant_test_bit(long nr, const volatile unsigned 
long *addr)
{
return ((1UL << (nr & (BITS_PER_LONG-1))) &
(addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
8119830d:   48 8b 04 25 44 3c 0fmov0x820f3c44,%rax
81198314:   82 
81198315:   a9 00 02 00 00  test   $0x200,%eax
8119831a:   75 5b   jne81198377 

#define __PV_IS_CALLEE_SAVE(func)   \
((struct paravirt_callee_save) { func })

static inline notrace unsigned long arch_local_save_flags(void)
{
return PVOP_CALLEE0(unsigned long, pv_irq_ops.save_fl);
8119831c:   ff 14 25 d0 28 02 82callq  *0x820228d0
BUG_ON(!irqs_disabled());
81198323:   a9 00 02 00 00  test   $0x200,%eax
81198328:   0f 85 d4 00 00 00   jne81198402 

8119832e:   48 83 39 00 cmpq   $0x0,(%rcx)
if (llist_empty(list))
81198332:   74 43   je 81198377 

81198334:   31 db   xor%ebx,%ebx
 * return the pointer to the first entry.  The order of entries
 * deleted is from the newest to the oldest added one.
 */
static inline struct llist_node *llist_del_all(struct llist_head *head)
{
return xchg(>first, NULL);
81198336:   48 87 19xchg   %rbx,(%rcx)
while (llnode != NULL) {
81198339:   48 85 dbtest   %rbx,%rbx
8119833c:   74 39   je 81198377 

8119833e:   66 90   xchg   %ax,%ax
work = llist_entry(llnode, struct irq_work, llnode);
81198340:   48 8d 7b f8 lea-0x8(%rbx),%rdi
flags = work->flags & ~IRQ_WORK_PENDING;
81198344:   4c 8b 7b f8 mov-0x8(%rbx),%r15
return node->next;
81198348:   4c 8b 23mov(%rbx),%r12
8119834b:   4d 89 femov%r15,%r14
8119834e:   49 83 e6 fe and$0xfffe,%r14
xchg(>flags, flags);
81198352:   4c 89 f0mov%r14,%rax
81198355:   48 87 43 f8 xchg   %rax,-0x8(%rbx)
work->func(work);
81198359:   4c 8b 5b 08 mov0x8(%rbx),%r11
8119835d:   e8 de ad 86 00  callq  81a03140 
<__x86_indirect_thunk_r11>
(void)cmpxchg(>flags, flags, flags & ~IRQ_WORK_BUSY);
81198362:   49 83 e7 fc and$0xfffc,%r15
81198366:   4c 89 f0mov%r14,%rax
81198369:   f0 4c 0f b1 7b f8   lock cmpxchg %r15,-0x8(%rbx)
8119836f:   4c 89 e3mov%r12,%rbx
while (llnode != NULL) {
81198372:   4d 85 e4test   %r12,%r12
81198375:   75 c9   jne81198340 

irq_work_run_list(raised);
irq_work_run_list(this_cpu_ptr(_list));
81198377:   48 c7 c1 88 e5 01 00mov$0x1e588,%rcx
8119837e:   65 48 03 0c 25 d8 f1add%gs:0xf1d8,%rcx

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

Just for the records...

[ OBJDUMP irq_work_tick() ]

$ objdump -d -S --start-address=0x$(grep irq_work_tick System.map |
sed -e "s/ \+.*//") vmlinux | less

[ OBJDUMP native_save_fl() ]

$ objdump -d -S --start-address=0x$(grep native_save_fl System.map |
sed -e "s/ \+.*//") vmlinux | less

- sedat -
[ OBJDUMP irq_work_tick() ]

$ objdump -d -S --start-address=0x$(grep irq_work_tick System.map | sed -e "s/ 
\+.*//") vmlinux | less

vmlinux: file format elf64-x86-64


Disassembly of section .text:

811982f0 :
irq_work_run_list(this_cpu_ptr(_list));
}
EXPORT_SYMBOL_GPL(irq_work_run);

void irq_work_tick(void)
{
811982f0:   41 57   push   %r15
811982f2:   41 56   push   %r14
811982f4:   41 54   push   %r12
811982f6:   53  push   %rbx
struct llist_head *raised = this_cpu_ptr(_list);
811982f7:   48 c7 c1 80 e5 01 00mov$0x1e580,%rcx
811982fe:   65 48 03 0c 25 d8 f1add%gs:0xf1d8,%rcx
81198305:   00 00 
 * test whether the list is empty without deleting something from the
 * list.
 */
static inline bool llist_empty(const struct llist_head *head)
{
return ACCESS_ONCE(head->first) == NULL;
81198307:   48 83 39 00 cmpq   $0x0,(%rcx)

if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
8119830b:   74 6a   je 81198377 

}

static __always_inline bool constant_test_bit(long nr, const volatile unsigned 
long *addr)
{
return ((1UL << (nr & (BITS_PER_LONG-1))) &
(addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
8119830d:   48 8b 04 25 44 3c 0fmov0x820f3c44,%rax
81198314:   82 
81198315:   a9 00 02 00 00  test   $0x200,%eax
8119831a:   75 5b   jne81198377 

#define __PV_IS_CALLEE_SAVE(func)   \
((struct paravirt_callee_save) { func })

static inline notrace unsigned long arch_local_save_flags(void)
{
return PVOP_CALLEE0(unsigned long, pv_irq_ops.save_fl);
8119831c:   ff 14 25 d0 28 02 82callq  *0x820228d0
BUG_ON(!irqs_disabled());
81198323:   a9 00 02 00 00  test   $0x200,%eax
81198328:   0f 85 d4 00 00 00   jne81198402 

8119832e:   48 83 39 00 cmpq   $0x0,(%rcx)
if (llist_empty(list))
81198332:   74 43   je 81198377 

81198334:   31 db   xor%ebx,%ebx
 * return the pointer to the first entry.  The order of entries
 * deleted is from the newest to the oldest added one.
 */
static inline struct llist_node *llist_del_all(struct llist_head *head)
{
return xchg(>first, NULL);
81198336:   48 87 19xchg   %rbx,(%rcx)
while (llnode != NULL) {
81198339:   48 85 dbtest   %rbx,%rbx
8119833c:   74 39   je 81198377 

8119833e:   66 90   xchg   %ax,%ax
work = llist_entry(llnode, struct irq_work, llnode);
81198340:   48 8d 7b f8 lea-0x8(%rbx),%rdi
flags = work->flags & ~IRQ_WORK_PENDING;
81198344:   4c 8b 7b f8 mov-0x8(%rbx),%r15
return node->next;
81198348:   4c 8b 23mov(%rbx),%r12
8119834b:   4d 89 femov%r15,%r14
8119834e:   49 83 e6 fe and$0xfffe,%r14
xchg(>flags, flags);
81198352:   4c 89 f0mov%r14,%rax
81198355:   48 87 43 f8 xchg   %rax,-0x8(%rbx)
work->func(work);
81198359:   4c 8b 5b 08 mov0x8(%rbx),%r11
8119835d:   e8 de ad 86 00  callq  81a03140 
<__x86_indirect_thunk_r11>
(void)cmpxchg(>flags, flags, flags & ~IRQ_WORK_BUSY);
81198362:   49 83 e7 fc and$0xfffc,%r15
81198366:   4c 89 f0mov%r14,%rax
81198369:   f0 4c 0f b1 7b f8   lock cmpxchg %r15,-0x8(%rbx)
8119836f:   4c 89 e3mov%r12,%rbx
while (llnode != NULL) {
81198372:   4d 85 e4test   %r12,%r12
81198375:   75 c9   jne81198340 

irq_work_run_list(raised);
irq_work_run_list(this_cpu_ptr(_list));
81198377:   48 c7 c1 88 e5 01 00mov$0x1e588,%rcx
8119837e:   65 48 03 0c 25 d8 f1add%gs:0xf1d8,%rcx
81198385:   00 00 
81198387:   ff 14 25 d0 28 02 82callq  *0x820228d0

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

For the sake of completeness...

[ CLANG VERSION ]

# dpkg -l | grep clang-7
ii  clang-7
1:7~svn332830-1~exp1+0~20180521091322.1776~1.gbp198359 amd64C,
C++ and Objective-C compiler

[ OBJDUMP native_save_fl() ]

$ objdump -d -S --start-address=0x$(grep native_save_fl System.map |
sed -e "s/ \+.*//") vmlinux | less

vmlinux: file format elf64-x86-64


Disassembly of section .text:

810633a0 :
/*
 * Interrupt control:
 */

static inline __nostackprotector unsigned long native_save_fl(void)
{
810633a0:   55  push   %rbp
810633a1:   48 89 e5mov%rsp,%rbp
810633a4:   50  push   %rax
/*
 * "=rm" is safe here, because "pop" adjusts the stack before
 * it evaluates its effective address -- this is part of the
 * documented behavior of the "pop" instruction.
 */
asm volatile("# __raw_save_flags\n\t"
810633a5:   9c  pushfq
810633a6:   8f 45 f8popq   -0x8(%rbp)
 "pushf ; pop %0"
 : "=rm" (flags)
 : /* no input */
 : "memory");

return flags;
810633a9:   48 8b 45 f8 mov-0x8(%rbp),%rax
810633ad:   48 83 c4 08 add$0x8,%rsp
810633b1:   5d  pop%rbp
810633b2:   c3  retq
810633b3:   0f 1f 00nopl   (%rax)
810633b6:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
810633bd:   00 00 00

810633c0 :
}

static inline void native_restore_fl(unsigned long flags)
{
...

- Sedat -

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

For the sake of completeness...

[ CLANG VERSION ]

# dpkg -l | grep clang-7
ii  clang-7
1:7~svn332830-1~exp1+0~20180521091322.1776~1.gbp198359 amd64C,
C++ and Objective-C compiler

[ OBJDUMP native_save_fl() ]

$ objdump -d -S --start-address=0x$(grep native_save_fl System.map |
sed -e "s/ \+.*//") vmlinux | less

vmlinux: file format elf64-x86-64


Disassembly of section .text:

810633a0 :
/*
 * Interrupt control:
 */

static inline __nostackprotector unsigned long native_save_fl(void)
{
810633a0:   55  push   %rbp
810633a1:   48 89 e5mov%rsp,%rbp
810633a4:   50  push   %rax
/*
 * "=rm" is safe here, because "pop" adjusts the stack before
 * it evaluates its effective address -- this is part of the
 * documented behavior of the "pop" instruction.
 */
asm volatile("# __raw_save_flags\n\t"
810633a5:   9c  pushfq
810633a6:   8f 45 f8popq   -0x8(%rbp)
 "pushf ; pop %0"
 : "=rm" (flags)
 : /* no input */
 : "memory");

return flags;
810633a9:   48 8b 45 f8 mov-0x8(%rbp),%rax
810633ad:   48 83 c4 08 add$0x8,%rsp
810633b1:   5d  pop%rbp
810633b2:   c3  retq
810633b3:   0f 1f 00nopl   (%rax)
810633b6:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
810633bd:   00 00 00

810633c0 :
}

static inline void native_restore_fl(unsigned long flags)
{
...

- Sedat -

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

Hi,

I looked again into the llvm-bug #37512 and mentioned patches, so I
give this a 2nd try (see attached patchset).

Regards,
- Sedat -
From 6b78d2ecfae1cd3de35c8871605f0881df174b35 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers 
Date: Sat, 7 Oct 2017 13:23:23 -0700
Subject: [PATCH 1/4] kbuild: clang: remove crufty HOSTCFLAGS

When compiling with `make CC=clang HOSTCC=clang`, I was seeing warnings
that clang did not recognize -fno-delete-null-pointer-checks for HOSTCC
targets.  These were added in commit 61163efae020 ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").

Clang does not support -fno-delete-null-pointer-checks, so adding it to
HOSTCFLAGS if HOSTCC is clang does not make sense.

It's not clear why the other warnings were disabled, and just for
HOSTCFLAGS, but I can remove them, add -Werror to HOSTCFLAGS and compile
with clang just fine.

Suggested-by: Masahiro Yamada 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Masahiro Yamada 
---
 Makefile | 5 -
 1 file changed, 5 deletions(-)

diff --git a/Makefile b/Makefile
index 0a1f941899f4..0e4dec5fdba5 100644
--- a/Makefile
+++ b/Makefile
@@ -369,11 +369,6 @@ HOSTCXXFLAGS := -O2 $(HOST_LFS_CFLAGS)
 HOSTLDFLAGS  := $(HOST_LFS_LDFLAGS)
 HOST_LOADLIBES := $(HOST_LFS_LIBS)
 
-ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
-HOSTCFLAGS  += -Wno-unused-value -Wno-unused-parameter \
-		-Wno-missing-field-initializers -fno-delete-null-pointer-checks
-endif
-
 # Make variables (CC, etc...)
 AS		= $(CROSS_COMPILE)as
 LD		= $(CROSS_COMPILE)ld
-- 
2.17.0

From 32f3dd55b9c8c5ce45ac8f90a2a5dd5cfab0f4df Mon Sep 17 00:00:00 2001
From: Nick Desaulniers 
Date: Sat, 6 Jan 2018 13:39:48 -0800
Subject: [PATCH 2/4] x86: xen: remove the use of VLAIS

Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
frowned upon by others.

https://lkml.org/lkml/2013/9/23/500

Here, the VLAIS was used because the size of the bitmap returned from
xen_mc_entry() depended on possibly (based on kernel configuration)
runtime sized data. Rather than declaring args as a VLAIS then calling
sizeof on *args, we calculate the appropriate sizeof args manually.
Further, we can get rid of the #ifdef's and rely on num_possible_cpus()
(thanks to a helpful checkpatch warning from an earlier version of this
patch).

Suggested-by: Juergen Gross 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/mmu_pv.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 042e9c422b21..854d5aa90b02 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1325,20 +1325,18 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
 {
 	struct {
 		struct mmuext_op op;
-#ifdef CONFIG_SMP
-		DECLARE_BITMAP(mask, num_processors);
-#else
 		DECLARE_BITMAP(mask, NR_CPUS);
-#endif
 	} *args;
 	struct multicall_space mcs;
+	const size_t mc_entry_size = sizeof(args->op) +
+		sizeof(args->mask[0]) * BITS_TO_LONGS(num_possible_cpus());
 
 	trace_xen_mmu_flush_tlb_others(cpus, info->mm, info->start, info->end);
 
 	if (cpumask_empty(cpus))
 		return;		/* nothing to do */
 
-	mcs = xen_mc_entry(sizeof(*args));
+	mcs = xen_mc_entry(mc_entry_size);
 	args = mcs.args;
 	args->op.arg2.vcpumask = to_cpumask(args->mask);
 
-- 
2.17.0

From 81eceff6658d6e750c7c0d0810ec3d6e66a0cd51 Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 12:00:56 +0200
Subject: [PATCH 3/4] compiler-clang.h: Add __nostackprotector attribute v2

---
 include/linux/compiler-clang.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 070f85d92c15..3fb36173bb99 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,3 +21,10 @@
 #ifdef __noretpoline
 #undef __noretpoline
 #endif
+
+/* Clang version 7 (>= svn331925) supports no_stack_protector attribute
+ * which disables the stack protector on the specified function.
+ * For details see .
+ */
+#undef __nostackprotector
+#define __nostackprotector __attribute__((no_stack_protector))
-- 
2.17.0

From 4bdace7d91eb044aa7245da1cdf8a3d52182b7e0 Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 12:07:24 +0200
Subject: [PATCH 4/4] x86/paravirt: Mark native_save_fl() with
 __nostackprotector attribute v2

---
 arch/x86/include/asm/irqflags.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 89f08955fff7..7e6765097adc 100644
--- a/arch/x86/include/asm/irqflags.h

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

Hi,

I looked again into the llvm-bug #37512 and mentioned patches, so I
give this a 2nd try (see attached patchset).

Regards,
- Sedat -
From 6b78d2ecfae1cd3de35c8871605f0881df174b35 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers 
Date: Sat, 7 Oct 2017 13:23:23 -0700
Subject: [PATCH 1/4] kbuild: clang: remove crufty HOSTCFLAGS

When compiling with `make CC=clang HOSTCC=clang`, I was seeing warnings
that clang did not recognize -fno-delete-null-pointer-checks for HOSTCC
targets.  These were added in commit 61163efae020 ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").

Clang does not support -fno-delete-null-pointer-checks, so adding it to
HOSTCFLAGS if HOSTCC is clang does not make sense.

It's not clear why the other warnings were disabled, and just for
HOSTCFLAGS, but I can remove them, add -Werror to HOSTCFLAGS and compile
with clang just fine.

Suggested-by: Masahiro Yamada 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Masahiro Yamada 
---
 Makefile | 5 -
 1 file changed, 5 deletions(-)

diff --git a/Makefile b/Makefile
index 0a1f941899f4..0e4dec5fdba5 100644
--- a/Makefile
+++ b/Makefile
@@ -369,11 +369,6 @@ HOSTCXXFLAGS := -O2 $(HOST_LFS_CFLAGS)
 HOSTLDFLAGS  := $(HOST_LFS_LDFLAGS)
 HOST_LOADLIBES := $(HOST_LFS_LIBS)
 
-ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
-HOSTCFLAGS  += -Wno-unused-value -Wno-unused-parameter \
-		-Wno-missing-field-initializers -fno-delete-null-pointer-checks
-endif
-
 # Make variables (CC, etc...)
 AS		= $(CROSS_COMPILE)as
 LD		= $(CROSS_COMPILE)ld
-- 
2.17.0

From 32f3dd55b9c8c5ce45ac8f90a2a5dd5cfab0f4df Mon Sep 17 00:00:00 2001
From: Nick Desaulniers 
Date: Sat, 6 Jan 2018 13:39:48 -0800
Subject: [PATCH 2/4] x86: xen: remove the use of VLAIS

Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
frowned upon by others.

https://lkml.org/lkml/2013/9/23/500

Here, the VLAIS was used because the size of the bitmap returned from
xen_mc_entry() depended on possibly (based on kernel configuration)
runtime sized data. Rather than declaring args as a VLAIS then calling
sizeof on *args, we calculate the appropriate sizeof args manually.
Further, we can get rid of the #ifdef's and rely on num_possible_cpus()
(thanks to a helpful checkpatch warning from an earlier version of this
patch).

Suggested-by: Juergen Gross 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/mmu_pv.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 042e9c422b21..854d5aa90b02 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1325,20 +1325,18 @@ static void xen_flush_tlb_others(const struct cpumask *cpus,
 {
 	struct {
 		struct mmuext_op op;
-#ifdef CONFIG_SMP
-		DECLARE_BITMAP(mask, num_processors);
-#else
 		DECLARE_BITMAP(mask, NR_CPUS);
-#endif
 	} *args;
 	struct multicall_space mcs;
+	const size_t mc_entry_size = sizeof(args->op) +
+		sizeof(args->mask[0]) * BITS_TO_LONGS(num_possible_cpus());
 
 	trace_xen_mmu_flush_tlb_others(cpus, info->mm, info->start, info->end);
 
 	if (cpumask_empty(cpus))
 		return;		/* nothing to do */
 
-	mcs = xen_mc_entry(sizeof(*args));
+	mcs = xen_mc_entry(mc_entry_size);
 	args = mcs.args;
 	args->op.arg2.vcpumask = to_cpumask(args->mask);
 
-- 
2.17.0

From 81eceff6658d6e750c7c0d0810ec3d6e66a0cd51 Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 12:00:56 +0200
Subject: [PATCH 3/4] compiler-clang.h: Add __nostackprotector attribute v2

---
 include/linux/compiler-clang.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 070f85d92c15..3fb36173bb99 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,3 +21,10 @@
 #ifdef __noretpoline
 #undef __noretpoline
 #endif
+
+/* Clang version 7 (>= svn331925) supports no_stack_protector attribute
+ * which disables the stack protector on the specified function.
+ * For details see .
+ */
+#undef __nostackprotector
+#define __nostackprotector __attribute__((no_stack_protector))
-- 
2.17.0

From 4bdace7d91eb044aa7245da1cdf8a3d52182b7e0 Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 12:07:24 +0200
Subject: [PATCH 4/4] x86/paravirt: Mark native_save_fl() with
 __nostackprotector attribute v2

---
 arch/x86/include/asm/irqflags.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 89f08955fff7..7e6765097adc 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -13,7 +13,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+static inline __nostackprotector unsigned long native_save_fl(void)
 {
 	unsigned long flags;
 
-- 
2.17.0

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Tue, May 22, 2018 at 10:04 AM, Sedat Dilek  wrote:
> On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek  wrote:
>> On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
>>  wrote:
>>> Sedat,
>>> Thanks for the report.  We have a fix ready in
>>> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
>>> version of clang you were using and if earlier versions of clang have
>>> this issue?
>>> Thanks,
>>
>> Can you give some advices on how to implement
>> "attribute((no_stack_protector))" for Clang?
>>
>> I looked on how this is done for GCC...
>>
>> [ include/linux/compiler-gcc.h ]
>>
>> #if GCC_VERSION >= 40400
>> #define __optimize(level)   __attribute__((__optimize__(level)))
>> #define __nostackprotector  __optimize("no-stack-protector")
>> #endif /* GCC_VERSION >= 40400 */
>>
>> [ include/linux/compiler_types.h ]
>>
>> #ifndef __nostackprotector
>> # define __nostackprotector
>> #endif
>>
>> LLVM-bug #37512 says:
>>
>> "GCC option for this is: attribute((optimize("no-stack-protector")))
>> and the equivalent clang syntax would be: attribute((no_stack_protector))"
>>
>> So, there should be a define in "include/linux/compiler-clang.h" for this?
>>
>> [ include/linux/compiler-clang.h ]
>>
>> #define __nostackprotector attribute((no_stack_protector))
>>
>> Looks that good to you?
>>
>
> I am trying with the attached files and...
>
> CONFIG_PARAVIRT=y
> CONFIG_CC_STACKPROTECTOR_STRONG=y
>

Hmmm, I get these errors in my build-log...

  mycompiler -Wp,-MD,arch/x86/kernel/.asm-offsets.s.d  -nostdinc
-isystem /usr/lib/llvm-7/lib/clang/7.0.0/include -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Qunused-arguments -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89
-fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64
-mno-80387 -mstack-alignment=8 -mtune=generic -mno-red-zone
-mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mretpoline-external-thunk -DRETPOLINE
-O2 -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-unused-variable -Wno-format-invalid-specifier -Wno-gnu
-Wno-address-of-packed-member -Wno-tautological-compare
-mno-global-merge -no-integrated-as -g -pg -mfentry -DCC_USING_FENTRY
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fno-merge-all-constants -fno-stack-check -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time
-Werror=incompatible-pointer-types -Wno-initializer-overrides
-Wno-unused-value -Wno-format -Wno-sign-compare
-Wno-format-zero-length -Wno-uninitialized
-DKBUILD_BASENAME='"asm_offsets"'  -DKBUILD_MODNAME='"asm_offsets"'
-fverbose-asm -S -o arch/x86/kernel/asm-offsets.s
arch/x86/kernel/asm-offsets.c
In file included from arch/x86/kernel/asm-offsets.c:9:
In file included from ./include/linux/crypto.h:24:
In file included from ./include/linux/slab.h:15:
In file included from ./include/linux/gfp.h:6:
In file included from ./include/linux/mmzone.h:8:
In file included from ./include/linux/spinlock.h:51:
In file included from ./include/linux/preempt.h:81:
In file included from ./arch/x86/include/asm/preempt.h:7:
In file included from ./include/linux/thread_info.h:38:
In file included from ./arch/x86/include/asm/thread_info.h:53:
In file included from ./arch/x86/include/asm/cpufeature.h:5:
In file included from ./arch/x86/include/asm/processor.h:33:
In file included from ./include/linux/irqflags.h:16:
./arch/x86/include/asm/irqflags.h:16:29: warning: declaration
specifier missing, defaulting to 'int'
static inline unsigned long __nostackprotector native_save_fl(void)
^
./include/linux/compiler-clang.h:28:39: note: expanded from macro
'__nostackprotector'
#define __nostackprotector attribute((no_stack_protector))
  ^
In file included from arch/x86/kernel/asm-offsets.c:9:
In file included from ./include/linux/crypto.h:24:
In file included from ./include/linux/slab.h:15:
In file included from ./include/linux/gfp.h:6:
In file included from ./include/linux/mmzone.h:8:
In file included from ./include/linux/spinlock.h:51:
In file included from ./include/linux/preempt.h:81:
In file included from ./arch/x86/include/asm/preempt.h:7:
In file included from ./include/linux/thread_info.h:38:
In file included from ./arch/x86/include/asm/thread_info.h:53:
In file included from ./arch/x86/include/asm/cpufeature.h:5:
In file included from 

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Tue, May 22, 2018 at 10:04 AM, Sedat Dilek  wrote:
> On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek  wrote:
>> On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
>>  wrote:
>>> Sedat,
>>> Thanks for the report.  We have a fix ready in
>>> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
>>> version of clang you were using and if earlier versions of clang have
>>> this issue?
>>> Thanks,
>>
>> Can you give some advices on how to implement
>> "attribute((no_stack_protector))" for Clang?
>>
>> I looked on how this is done for GCC...
>>
>> [ include/linux/compiler-gcc.h ]
>>
>> #if GCC_VERSION >= 40400
>> #define __optimize(level)   __attribute__((__optimize__(level)))
>> #define __nostackprotector  __optimize("no-stack-protector")
>> #endif /* GCC_VERSION >= 40400 */
>>
>> [ include/linux/compiler_types.h ]
>>
>> #ifndef __nostackprotector
>> # define __nostackprotector
>> #endif
>>
>> LLVM-bug #37512 says:
>>
>> "GCC option for this is: attribute((optimize("no-stack-protector")))
>> and the equivalent clang syntax would be: attribute((no_stack_protector))"
>>
>> So, there should be a define in "include/linux/compiler-clang.h" for this?
>>
>> [ include/linux/compiler-clang.h ]
>>
>> #define __nostackprotector attribute((no_stack_protector))
>>
>> Looks that good to you?
>>
>
> I am trying with the attached files and...
>
> CONFIG_PARAVIRT=y
> CONFIG_CC_STACKPROTECTOR_STRONG=y
>

Hmmm, I get these errors in my build-log...

  mycompiler -Wp,-MD,arch/x86/kernel/.asm-offsets.s.d  -nostdinc
-isystem /usr/lib/llvm-7/lib/clang/7.0.0/include -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Qunused-arguments -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89
-fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64
-mno-80387 -mstack-alignment=8 -mtune=generic -mno-red-zone
-mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mretpoline-external-thunk -DRETPOLINE
-O2 -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-unused-variable -Wno-format-invalid-specifier -Wno-gnu
-Wno-address-of-packed-member -Wno-tautological-compare
-mno-global-merge -no-integrated-as -g -pg -mfentry -DCC_USING_FENTRY
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fno-merge-all-constants -fno-stack-check -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time
-Werror=incompatible-pointer-types -Wno-initializer-overrides
-Wno-unused-value -Wno-format -Wno-sign-compare
-Wno-format-zero-length -Wno-uninitialized
-DKBUILD_BASENAME='"asm_offsets"'  -DKBUILD_MODNAME='"asm_offsets"'
-fverbose-asm -S -o arch/x86/kernel/asm-offsets.s
arch/x86/kernel/asm-offsets.c
In file included from arch/x86/kernel/asm-offsets.c:9:
In file included from ./include/linux/crypto.h:24:
In file included from ./include/linux/slab.h:15:
In file included from ./include/linux/gfp.h:6:
In file included from ./include/linux/mmzone.h:8:
In file included from ./include/linux/spinlock.h:51:
In file included from ./include/linux/preempt.h:81:
In file included from ./arch/x86/include/asm/preempt.h:7:
In file included from ./include/linux/thread_info.h:38:
In file included from ./arch/x86/include/asm/thread_info.h:53:
In file included from ./arch/x86/include/asm/cpufeature.h:5:
In file included from ./arch/x86/include/asm/processor.h:33:
In file included from ./include/linux/irqflags.h:16:
./arch/x86/include/asm/irqflags.h:16:29: warning: declaration
specifier missing, defaulting to 'int'
static inline unsigned long __nostackprotector native_save_fl(void)
^
./include/linux/compiler-clang.h:28:39: note: expanded from macro
'__nostackprotector'
#define __nostackprotector attribute((no_stack_protector))
  ^
In file included from arch/x86/kernel/asm-offsets.c:9:
In file included from ./include/linux/crypto.h:24:
In file included from ./include/linux/slab.h:15:
In file included from ./include/linux/gfp.h:6:
In file included from ./include/linux/mmzone.h:8:
In file included from ./include/linux/spinlock.h:51:
In file included from ./include/linux/preempt.h:81:
In file included from ./arch/x86/include/asm/preempt.h:7:
In file included from ./include/linux/thread_info.h:38:
In file included from ./arch/x86/include/asm/thread_info.h:53:
In file included from ./arch/x86/include/asm/cpufeature.h:5:
In file included from ./arch/x86/include/asm/processor.h:33:
In file included from 

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek  wrote:
> On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
>  wrote:
>> Sedat,
>> Thanks for the report.  We have a fix ready in
>> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
>> version of clang you were using and if earlier versions of clang have
>> this issue?
>> Thanks,
>
> Can you give some advices on how to implement
> "attribute((no_stack_protector))" for Clang?
>
> I looked on how this is done for GCC...
>
> [ include/linux/compiler-gcc.h ]
>
> #if GCC_VERSION >= 40400
> #define __optimize(level)   __attribute__((__optimize__(level)))
> #define __nostackprotector  __optimize("no-stack-protector")
> #endif /* GCC_VERSION >= 40400 */
>
> [ include/linux/compiler_types.h ]
>
> #ifndef __nostackprotector
> # define __nostackprotector
> #endif
>
> LLVM-bug #37512 says:
>
> "GCC option for this is: attribute((optimize("no-stack-protector")))
> and the equivalent clang syntax would be: attribute((no_stack_protector))"
>
> So, there should be a define in "include/linux/compiler-clang.h" for this?
>
> [ include/linux/compiler-clang.h ]
>
> #define __nostackprotector attribute((no_stack_protector))
>
> Looks that good to you?
>

I am trying with the attached files and...

CONFIG_PARAVIRT=y
CONFIG_CC_STACKPROTECTOR_STRONG=y

- Sedat -
From ed07ff36ae7ae121e48d6c0579ff3fd5796bf57a Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 09:46:18 +0200
Subject: [PATCH 1/2] compiler-clang.h: Add __nostackprotector function
 attribute

---
 include/linux/compiler-clang.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 070f85d92c15..1da957c33140 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,3 +21,8 @@
 #ifdef __noretpoline
 #undef __noretpoline
 #endif
+
+/* For details see .
+ * This feature requires Clang version 7 >= svn331925.
+ */
+#define __nostackprotector attribute((no_stack_protector))
-- 
2.17.0

From 6ff43719d2f225ee90364ce054a955590a07e911 Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 09:52:15 +0200
Subject: [PATCH 2/2] x86/paravirt: Mark native_save_fl() with
 __nostackprotector attribute

---
 arch/x86/include/asm/irqflags.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 89f08955fff7..6def04321181 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -13,7 +13,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+static inline unsigned long __nostackprotector native_save_fl(void)
 {
 	unsigned long flags;
 
-- 
2.17.0

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Tue, May 22, 2018 at 9:39 AM, Sedat Dilek  wrote:
> On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
>  wrote:
>> Sedat,
>> Thanks for the report.  We have a fix ready in
>> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
>> version of clang you were using and if earlier versions of clang have
>> this issue?
>> Thanks,
>
> Can you give some advices on how to implement
> "attribute((no_stack_protector))" for Clang?
>
> I looked on how this is done for GCC...
>
> [ include/linux/compiler-gcc.h ]
>
> #if GCC_VERSION >= 40400
> #define __optimize(level)   __attribute__((__optimize__(level)))
> #define __nostackprotector  __optimize("no-stack-protector")
> #endif /* GCC_VERSION >= 40400 */
>
> [ include/linux/compiler_types.h ]
>
> #ifndef __nostackprotector
> # define __nostackprotector
> #endif
>
> LLVM-bug #37512 says:
>
> "GCC option for this is: attribute((optimize("no-stack-protector")))
> and the equivalent clang syntax would be: attribute((no_stack_protector))"
>
> So, there should be a define in "include/linux/compiler-clang.h" for this?
>
> [ include/linux/compiler-clang.h ]
>
> #define __nostackprotector attribute((no_stack_protector))
>
> Looks that good to you?
>

I am trying with the attached files and...

CONFIG_PARAVIRT=y
CONFIG_CC_STACKPROTECTOR_STRONG=y

- Sedat -
From ed07ff36ae7ae121e48d6c0579ff3fd5796bf57a Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 09:46:18 +0200
Subject: [PATCH 1/2] compiler-clang.h: Add __nostackprotector function
 attribute

---
 include/linux/compiler-clang.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 070f85d92c15..1da957c33140 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,3 +21,8 @@
 #ifdef __noretpoline
 #undef __noretpoline
 #endif
+
+/* For details see .
+ * This feature requires Clang version 7 >= svn331925.
+ */
+#define __nostackprotector attribute((no_stack_protector))
-- 
2.17.0

From 6ff43719d2f225ee90364ce054a955590a07e911 Mon Sep 17 00:00:00 2001
From: Sedat Dilek 
Date: Tue, 22 May 2018 09:52:15 +0200
Subject: [PATCH 2/2] x86/paravirt: Mark native_save_fl() with
 __nostackprotector attribute

---
 arch/x86/include/asm/irqflags.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 89f08955fff7..6def04321181 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -13,7 +13,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+static inline unsigned long __nostackprotector native_save_fl(void)
 {
 	unsigned long flags;
 
-- 
2.17.0

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
 wrote:
> Sedat,
> Thanks for the report.  We have a fix ready in
> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
> version of clang you were using and if earlier versions of clang have
> this issue?
> Thanks,

Can you give some advices on how to implement
"attribute((no_stack_protector))" for Clang?

I looked on how this is done for GCC...

[ include/linux/compiler-gcc.h ]

#if GCC_VERSION >= 40400
#define __optimize(level)   __attribute__((__optimize__(level)))
#define __nostackprotector  __optimize("no-stack-protector")
#endif /* GCC_VERSION >= 40400 */

[ include/linux/compiler_types.h ]

#ifndef __nostackprotector
# define __nostackprotector
#endif

LLVM-bug #37512 says:

"GCC option for this is: attribute((optimize("no-stack-protector")))
and the equivalent clang syntax would be: attribute((no_stack_protector))"

So, there should be a define in "include/linux/compiler-clang.h" for this?

[ include/linux/compiler-clang.h ]

#define __nostackprotector attribute((no_stack_protector))

Looks that good to you?

- Sedat -

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
 wrote:
> Sedat,
> Thanks for the report.  We have a fix ready in
> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
> version of clang you were using and if earlier versions of clang have
> this issue?
> Thanks,

Can you give some advices on how to implement
"attribute((no_stack_protector))" for Clang?

I looked on how this is done for GCC...

[ include/linux/compiler-gcc.h ]

#if GCC_VERSION >= 40400
#define __optimize(level)   __attribute__((__optimize__(level)))
#define __nostackprotector  __optimize("no-stack-protector")
#endif /* GCC_VERSION >= 40400 */

[ include/linux/compiler_types.h ]

#ifndef __nostackprotector
# define __nostackprotector
#endif

LLVM-bug #37512 says:

"GCC option for this is: attribute((optimize("no-stack-protector")))
and the equivalent clang syntax would be: attribute((no_stack_protector))"

So, there should be a define in "include/linux/compiler-clang.h" for this?

[ include/linux/compiler-clang.h ]

#define __nostackprotector attribute((no_stack_protector))

Looks that good to you?

- Sedat -

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
 wrote:
> Sedat,
> Thanks for the report.  We have a fix ready in
> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
> version of clang you were using and if earlier versions of clang have
> this issue?
> Thanks,

Hi Nick,

yesterday was public holiday in Germany, so I answer today.

These are really good news, Thanks.

For my recent experiments with Linux-kernel v4.14.y LTS I used Clang...

#1: version 6.0 from Debian/testing repositories
#2: version 7 (svn330207) from 

In these cases I had success (good means boot on bare metal) or it
failed (bad verified in Qemu):

bad: CONFIG_PARAVIRT=y and  CONFIG_CC_STACKPROTECTOR_STRONG=y
good: CONFIG_PARAVIRT=n and CONFIG_CC_STACKPROTECTOR_STRONG=y
good: CONFIG_PARAVIRT=y and CONFIG_CC_STACKPROTECTOR_NONE=y

So, the issue is in both Clang versions and I appreciate to have your
fix in LLVM/Clang version 6.0.1 as I don't know which version will get
into upcoming Debian/buster (version 10, current status: testing).

Hope this helps.

Regards,
- Sedat -

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Sat, May 19, 2018 at 12:54 AM, Nick Desaulniers
 wrote:
> Sedat,
> Thanks for the report.  We have a fix ready in
> https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
> version of clang you were using and if earlier versions of clang have
> this issue?
> Thanks,

Hi Nick,

yesterday was public holiday in Germany, so I answer today.

These are really good news, Thanks.

For my recent experiments with Linux-kernel v4.14.y LTS I used Clang...

#1: version 6.0 from Debian/testing repositories
#2: version 7 (svn330207) from 

In these cases I had success (good means boot on bare metal) or it
failed (bad verified in Qemu):

bad: CONFIG_PARAVIRT=y and  CONFIG_CC_STACKPROTECTOR_STRONG=y
good: CONFIG_PARAVIRT=n and CONFIG_CC_STACKPROTECTOR_STRONG=y
good: CONFIG_PARAVIRT=y and CONFIG_CC_STACKPROTECTOR_NONE=y

So, the issue is in both Clang versions and I appreciate to have your
fix in LLVM/Clang version 6.0.1 as I don't know which version will get
into upcoming Debian/buster (version 10, current status: testing).

Hope this helps.

Regards,
- Sedat -

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Nick Desaulniers]

Sedat,
Thanks for the report.  We have a fix ready in
https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
version of clang you were using and if earlier versions of clang have
this issue?
Thanks,
~Nick

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Nick Desaulniers]

Sedat,
Thanks for the report.  We have a fix ready in
https://bugs.llvm.org/show_bug.cgi?id=37512.  Can you report what
version of clang you were using and if earlier versions of clang have
this issue?
Thanks,
~Nick

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Mon, May 7, 2018 at 7:49 PM, Matthias Kaehlcke  wrote:
> On Sun, May 06, 2018 at 09:42:09AM +0200, Sedat Dilek wrote:
>> On Wed, Apr 25, 2018 at 1:06 AM, Matthias Kaehlcke  wrote:
>> > On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote:
>> >> Hi Matthias,
>> >>
>> >> a big thank you for giving all the informations!
>> >>
>> >> I used your mka/llvm/v4.14_ext Git tree...
>> >>
>> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
>> >>
>> >> ...and was able to compile with clang-6.0 from Debian/buster64 with...
>> >>
>> >> ...reverting the clang-3/clang-4 patches...
>> >>
>> >> user$ for p in 69e44656ae43 222b88977a00 cdfcf1e45537 26f14c9225a6
>> >> 0385a18e9995 68dab143c9b4 ; do echo [ $p ] ; LC_ALL=C git revert
>> >> --no-edit $p ; done
>> >>
>> >> 0001-Revert-CLANG3-core-clang-work-around-x86-regparm-int.patch
>> >> 0002-Revert-CLANG4-futex-don-t-optimize-futex_detect_cmpx.patch
>> >> 0003-Revert-CLANG4-Disable-lkdtm-when-ftrace-is-enabled.patch
>> >> 0004-Revert-CLANG4-arm64-prefetch-Use-__builtin_arm_prefe.patch
>> >> 0005-Revert-CLANG4-kbuild-Add-meabi-gnu-to-the-clang-para.patch
>> >> 0006-Revert-CLANG4-crypto-arm64-aes-ce-Explicitly-pass-th.patch
>> >>
>> >> ...and needed two additional patches from upstream:
>> >>
>> >> 0007-kbuild-clang-remove-crufty-HOSTCFLAGS.patch <--- Label with
>> >> BACKPORT (XXX: Backported; Required when using HOSTCC in make-line,
>> >> see below)
>> >> 0008-x86-xen-remove-the-use-of-VLAIS.patch <--- Label with UPSTREAM
>> >> (XXX: cherry-picked)
>> >>
>> >> These 3 patches in your Git branch are in Linux v4.14.36...
>> >>
>> >> 9af5ddf981ed BACKPORT: kbuild: disable clang's default use of
>> >> -fmerge-all-constants
>> >> f24088a3842c BACKPORT: kbuild: Set KBUILD_CFLAGS before incl. arch 
>> >> Makefile
>> >> d4dfe384346d UPSTREAM: kbuild: fix linker feature test macros when
>> >> cross compiling with Clang
>> >>
>> >> ...and can be dropped.
>> >> I do not know your work-flow/policy: Maybe you want to keep your
>> >> patch-stack against vanilla Linux v4.14 - without stables from
>> >> linux-stable-4.14.y.
>> >
>> > Yes, these patch stacks are based on vanilla Linux v4.14, one reason
>> > is that it isn't a moving target. Also I think it makes it easier for
>> > folks not merging LTS (though they probably should!) to locate all
>> > patches, and it's fairly trivial to skip the (currently) few patches
>> > not needed with the -stable tree.
>> >
>> >> For easy switching "mycompiler" I use a wrapper-script:
>> >>
>> >> root# cat /usr/bin/mycompiler
>> >> #!/bin/bash
>> >>
>> >> clang-6.0 "$@"
>> >> - EOF -
>> >>
>> >> user$ cp -v /boot/config-4.14.35-1-iniza-amd64 .config
>> >> user$ MAKE="make V=1" ; COMPILER="mycompiler" ;
>> >> MAKE_OPTS="CC=$COMPILER HOSTCC=$COMPILER"
>> >> user$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>> >> silentoldconfig < /dev/null
>> >>
>> >> The diffconfig to my current kernel-config-4.14 looks like this...
>> >>
>> >> user$ ./scripts/diffconfig /boot/config-4.14.35-1-iniza-amd64 .config
>> >> -ARCH_HAS_REFCOUNT y
>> >> -BPF_JIT_ALWAYS_ON n
>> >> -EXOFS_DEBUG n
>> >> -EXOFS_FS m
>> >> -GENERIC_CPU_VULNERABILITIES y
>> >> -KASAN n
>> >> -ORE m
>> >> -PAGE_TABLE_ISOLATION y
>> >> -RETPOLINE y
>> >> -UNWINDER_FRAME_POINTER n
>> >> -UNWINDER_GUESS n
>> >> -UNWINDER_ORC y
>> >> +FRAME_POINTER y
>> >> +FRAME_POINTER_UNWINDER y
>> >> +GUESS_UNWINDER n
>> >> +HAVE_ARCH_KMEMCHECK y
>> >> +HAVE_RELIABLE_STACKTRACE y
>> >> +ORC_UNWINDER n
>> >>
>> >> Unfortunately, I cannot boot into the generated kernel on bare metal.
>> >>
>> >> Checking with QEMU (version: 2.12~rc3) and catching earlyprintk, I see 
>> >> this...
>> >>
>> >> user$ echo $KPATH
>> >> $HOME/src/linux-kernel/important-files
>> >>
>> >> user$ ls -al
>> >> insgesamt 344916
>> >> drwxr-xr-x  2 sdi sdi  4096 Apr 24 13:15 .
>> >> drwxr-xr-x 20 sdi sdi  4096 Apr 24 13:13 ..
>> >> -rw-r--r--  1 sdi sdi   4528416 Apr 24 12:42 bzImage
>> >> lrwxrwxrwx  1 sdi sdi35 Apr 24 13:15 initrd.img ->
>> >> initrd.img-4.14.0-1-iniza-llvmlinux
>> >> -rw-r--r--  1 sdi sdi  25572955 Apr 24 13:08
>> >> initrd.img-4.14.0-1-iniza-llvmlinux
>> >> -rw-r--r--  1 sdi sdi   2887195 Apr 24 12:42 System.map
>> >> -rwxr-xr-x  1 sdi sdi 326116744 Apr 24 12:42 vmlinux
>> >>
>> >> user$ sudo qemu-system-x86_64 -enable-kvm -M pc -kernel $KPATH/bzImage
>> >> -initrd $KPATH/initrd.img -m 512 -net none -serial stdio -append
>> >> "root=/dev/ram0 console=ttyS0 hung_task_panic=1
>> >> earlyprintk=ttyS0,115200"
>> >>
>> >> Probing EDD (edd=off to disable)... ok
>> >> [0.00] Linux version 4.14.0-1-iniza-llvmlinux
>> >> (sedat.di...@gmail.com@iniza) (clang version 6.0.0-1
>> >> (tags/RELEASE_600/final)) #1 SMP Tue Apr 24 12:42:21 CEST 2018
>> >> [0.00] Command line: root=/dev/ram0 console=ttyS0
>> >> hung_task_panic=1 earlyprintk=ttyS0,115200
>> >> [0.00] x86/fpu: x87 FPU will use FXSAVE

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Mon, May 7, 2018 at 7:49 PM, Matthias Kaehlcke  wrote:
> On Sun, May 06, 2018 at 09:42:09AM +0200, Sedat Dilek wrote:
>> On Wed, Apr 25, 2018 at 1:06 AM, Matthias Kaehlcke  wrote:
>> > On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote:
>> >> Hi Matthias,
>> >>
>> >> a big thank you for giving all the informations!
>> >>
>> >> I used your mka/llvm/v4.14_ext Git tree...
>> >>
>> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
>> >>
>> >> ...and was able to compile with clang-6.0 from Debian/buster64 with...
>> >>
>> >> ...reverting the clang-3/clang-4 patches...
>> >>
>> >> user$ for p in 69e44656ae43 222b88977a00 cdfcf1e45537 26f14c9225a6
>> >> 0385a18e9995 68dab143c9b4 ; do echo [ $p ] ; LC_ALL=C git revert
>> >> --no-edit $p ; done
>> >>
>> >> 0001-Revert-CLANG3-core-clang-work-around-x86-regparm-int.patch
>> >> 0002-Revert-CLANG4-futex-don-t-optimize-futex_detect_cmpx.patch
>> >> 0003-Revert-CLANG4-Disable-lkdtm-when-ftrace-is-enabled.patch
>> >> 0004-Revert-CLANG4-arm64-prefetch-Use-__builtin_arm_prefe.patch
>> >> 0005-Revert-CLANG4-kbuild-Add-meabi-gnu-to-the-clang-para.patch
>> >> 0006-Revert-CLANG4-crypto-arm64-aes-ce-Explicitly-pass-th.patch
>> >>
>> >> ...and needed two additional patches from upstream:
>> >>
>> >> 0007-kbuild-clang-remove-crufty-HOSTCFLAGS.patch <--- Label with
>> >> BACKPORT (XXX: Backported; Required when using HOSTCC in make-line,
>> >> see below)
>> >> 0008-x86-xen-remove-the-use-of-VLAIS.patch <--- Label with UPSTREAM
>> >> (XXX: cherry-picked)
>> >>
>> >> These 3 patches in your Git branch are in Linux v4.14.36...
>> >>
>> >> 9af5ddf981ed BACKPORT: kbuild: disable clang's default use of
>> >> -fmerge-all-constants
>> >> f24088a3842c BACKPORT: kbuild: Set KBUILD_CFLAGS before incl. arch 
>> >> Makefile
>> >> d4dfe384346d UPSTREAM: kbuild: fix linker feature test macros when
>> >> cross compiling with Clang
>> >>
>> >> ...and can be dropped.
>> >> I do not know your work-flow/policy: Maybe you want to keep your
>> >> patch-stack against vanilla Linux v4.14 - without stables from
>> >> linux-stable-4.14.y.
>> >
>> > Yes, these patch stacks are based on vanilla Linux v4.14, one reason
>> > is that it isn't a moving target. Also I think it makes it easier for
>> > folks not merging LTS (though they probably should!) to locate all
>> > patches, and it's fairly trivial to skip the (currently) few patches
>> > not needed with the -stable tree.
>> >
>> >> For easy switching "mycompiler" I use a wrapper-script:
>> >>
>> >> root# cat /usr/bin/mycompiler
>> >> #!/bin/bash
>> >>
>> >> clang-6.0 "$@"
>> >> - EOF -
>> >>
>> >> user$ cp -v /boot/config-4.14.35-1-iniza-amd64 .config
>> >> user$ MAKE="make V=1" ; COMPILER="mycompiler" ;
>> >> MAKE_OPTS="CC=$COMPILER HOSTCC=$COMPILER"
>> >> user$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>> >> silentoldconfig < /dev/null
>> >>
>> >> The diffconfig to my current kernel-config-4.14 looks like this...
>> >>
>> >> user$ ./scripts/diffconfig /boot/config-4.14.35-1-iniza-amd64 .config
>> >> -ARCH_HAS_REFCOUNT y
>> >> -BPF_JIT_ALWAYS_ON n
>> >> -EXOFS_DEBUG n
>> >> -EXOFS_FS m
>> >> -GENERIC_CPU_VULNERABILITIES y
>> >> -KASAN n
>> >> -ORE m
>> >> -PAGE_TABLE_ISOLATION y
>> >> -RETPOLINE y
>> >> -UNWINDER_FRAME_POINTER n
>> >> -UNWINDER_GUESS n
>> >> -UNWINDER_ORC y
>> >> +FRAME_POINTER y
>> >> +FRAME_POINTER_UNWINDER y
>> >> +GUESS_UNWINDER n
>> >> +HAVE_ARCH_KMEMCHECK y
>> >> +HAVE_RELIABLE_STACKTRACE y
>> >> +ORC_UNWINDER n
>> >>
>> >> Unfortunately, I cannot boot into the generated kernel on bare metal.
>> >>
>> >> Checking with QEMU (version: 2.12~rc3) and catching earlyprintk, I see 
>> >> this...
>> >>
>> >> user$ echo $KPATH
>> >> $HOME/src/linux-kernel/important-files
>> >>
>> >> user$ ls -al
>> >> insgesamt 344916
>> >> drwxr-xr-x  2 sdi sdi  4096 Apr 24 13:15 .
>> >> drwxr-xr-x 20 sdi sdi  4096 Apr 24 13:13 ..
>> >> -rw-r--r--  1 sdi sdi   4528416 Apr 24 12:42 bzImage
>> >> lrwxrwxrwx  1 sdi sdi35 Apr 24 13:15 initrd.img ->
>> >> initrd.img-4.14.0-1-iniza-llvmlinux
>> >> -rw-r--r--  1 sdi sdi  25572955 Apr 24 13:08
>> >> initrd.img-4.14.0-1-iniza-llvmlinux
>> >> -rw-r--r--  1 sdi sdi   2887195 Apr 24 12:42 System.map
>> >> -rwxr-xr-x  1 sdi sdi 326116744 Apr 24 12:42 vmlinux
>> >>
>> >> user$ sudo qemu-system-x86_64 -enable-kvm -M pc -kernel $KPATH/bzImage
>> >> -initrd $KPATH/initrd.img -m 512 -net none -serial stdio -append
>> >> "root=/dev/ram0 console=ttyS0 hung_task_panic=1
>> >> earlyprintk=ttyS0,115200"
>> >>
>> >> Probing EDD (edd=off to disable)... ok
>> >> [0.00] Linux version 4.14.0-1-iniza-llvmlinux
>> >> (sedat.di...@gmail.com@iniza) (clang version 6.0.0-1
>> >> (tags/RELEASE_600/final)) #1 SMP Tue Apr 24 12:42:21 CEST 2018
>> >> [0.00] Command line: root=/dev/ram0 console=ttyS0
>> >> hung_task_panic=1 earlyprintk=ttyS0,115200
>> >> [0.00] x86/fpu: x87 FPU will use FXSAVE
>> >> [0.00] e820: 

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Matthias Kaehlcke]

On Sun, May 06, 2018 at 09:42:09AM +0200, Sedat Dilek wrote:
> On Wed, Apr 25, 2018 at 1:06 AM, Matthias Kaehlcke  wrote:
> > On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote:
> >> Hi Matthias,
> >>
> >> a big thank you for giving all the informations!
> >>
> >> I used your mka/llvm/v4.14_ext Git tree...
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
> >>
> >> ...and was able to compile with clang-6.0 from Debian/buster64 with...
> >>
> >> ...reverting the clang-3/clang-4 patches...
> >>
> >> user$ for p in 69e44656ae43 222b88977a00 cdfcf1e45537 26f14c9225a6
> >> 0385a18e9995 68dab143c9b4 ; do echo [ $p ] ; LC_ALL=C git revert
> >> --no-edit $p ; done
> >>
> >> 0001-Revert-CLANG3-core-clang-work-around-x86-regparm-int.patch
> >> 0002-Revert-CLANG4-futex-don-t-optimize-futex_detect_cmpx.patch
> >> 0003-Revert-CLANG4-Disable-lkdtm-when-ftrace-is-enabled.patch
> >> 0004-Revert-CLANG4-arm64-prefetch-Use-__builtin_arm_prefe.patch
> >> 0005-Revert-CLANG4-kbuild-Add-meabi-gnu-to-the-clang-para.patch
> >> 0006-Revert-CLANG4-crypto-arm64-aes-ce-Explicitly-pass-th.patch
> >>
> >> ...and needed two additional patches from upstream:
> >>
> >> 0007-kbuild-clang-remove-crufty-HOSTCFLAGS.patch <--- Label with
> >> BACKPORT (XXX: Backported; Required when using HOSTCC in make-line,
> >> see below)
> >> 0008-x86-xen-remove-the-use-of-VLAIS.patch <--- Label with UPSTREAM
> >> (XXX: cherry-picked)
> >>
> >> These 3 patches in your Git branch are in Linux v4.14.36...
> >>
> >> 9af5ddf981ed BACKPORT: kbuild: disable clang's default use of
> >> -fmerge-all-constants
> >> f24088a3842c BACKPORT: kbuild: Set KBUILD_CFLAGS before incl. arch Makefile
> >> d4dfe384346d UPSTREAM: kbuild: fix linker feature test macros when
> >> cross compiling with Clang
> >>
> >> ...and can be dropped.
> >> I do not know your work-flow/policy: Maybe you want to keep your
> >> patch-stack against vanilla Linux v4.14 - without stables from
> >> linux-stable-4.14.y.
> >
> > Yes, these patch stacks are based on vanilla Linux v4.14, one reason
> > is that it isn't a moving target. Also I think it makes it easier for
> > folks not merging LTS (though they probably should!) to locate all
> > patches, and it's fairly trivial to skip the (currently) few patches
> > not needed with the -stable tree.
> >
> >> For easy switching "mycompiler" I use a wrapper-script:
> >>
> >> root# cat /usr/bin/mycompiler
> >> #!/bin/bash
> >>
> >> clang-6.0 "$@"
> >> - EOF -
> >>
> >> user$ cp -v /boot/config-4.14.35-1-iniza-amd64 .config
> >> user$ MAKE="make V=1" ; COMPILER="mycompiler" ;
> >> MAKE_OPTS="CC=$COMPILER HOSTCC=$COMPILER"
> >> user$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
> >> silentoldconfig < /dev/null
> >>
> >> The diffconfig to my current kernel-config-4.14 looks like this...
> >>
> >> user$ ./scripts/diffconfig /boot/config-4.14.35-1-iniza-amd64 .config
> >> -ARCH_HAS_REFCOUNT y
> >> -BPF_JIT_ALWAYS_ON n
> >> -EXOFS_DEBUG n
> >> -EXOFS_FS m
> >> -GENERIC_CPU_VULNERABILITIES y
> >> -KASAN n
> >> -ORE m
> >> -PAGE_TABLE_ISOLATION y
> >> -RETPOLINE y
> >> -UNWINDER_FRAME_POINTER n
> >> -UNWINDER_GUESS n
> >> -UNWINDER_ORC y
> >> +FRAME_POINTER y
> >> +FRAME_POINTER_UNWINDER y
> >> +GUESS_UNWINDER n
> >> +HAVE_ARCH_KMEMCHECK y
> >> +HAVE_RELIABLE_STACKTRACE y
> >> +ORC_UNWINDER n
> >>
> >> Unfortunately, I cannot boot into the generated kernel on bare metal.
> >>
> >> Checking with QEMU (version: 2.12~rc3) and catching earlyprintk, I see 
> >> this...
> >>
> >> user$ echo $KPATH
> >> $HOME/src/linux-kernel/important-files
> >>
> >> user$ ls -al
> >> insgesamt 344916
> >> drwxr-xr-x  2 sdi sdi  4096 Apr 24 13:15 .
> >> drwxr-xr-x 20 sdi sdi  4096 Apr 24 13:13 ..
> >> -rw-r--r--  1 sdi sdi   4528416 Apr 24 12:42 bzImage
> >> lrwxrwxrwx  1 sdi sdi35 Apr 24 13:15 initrd.img ->
> >> initrd.img-4.14.0-1-iniza-llvmlinux
> >> -rw-r--r--  1 sdi sdi  25572955 Apr 24 13:08
> >> initrd.img-4.14.0-1-iniza-llvmlinux
> >> -rw-r--r--  1 sdi sdi   2887195 Apr 24 12:42 System.map
> >> -rwxr-xr-x  1 sdi sdi 326116744 Apr 24 12:42 vmlinux
> >>
> >> user$ sudo qemu-system-x86_64 -enable-kvm -M pc -kernel $KPATH/bzImage
> >> -initrd $KPATH/initrd.img -m 512 -net none -serial stdio -append
> >> "root=/dev/ram0 console=ttyS0 hung_task_panic=1
> >> earlyprintk=ttyS0,115200"
> >>
> >> Probing EDD (edd=off to disable)... ok
> >> [0.00] Linux version 4.14.0-1-iniza-llvmlinux
> >> (sedat.di...@gmail.com@iniza) (clang version 6.0.0-1
> >> (tags/RELEASE_600/final)) #1 SMP Tue Apr 24 12:42:21 CEST 2018
> >> [0.00] Command line: root=/dev/ram0 console=ttyS0
> >> hung_task_panic=1 earlyprintk=ttyS0,115200
> >> [0.00] x86/fpu: x87 FPU will use FXSAVE
> >> [0.00] e820: BIOS-provided physical RAM map:
> >> [0.00] BIOS-e820: [mem 0x-0x0009fbff] 
> >> usable
> >> [0.00] BIOS-e820: [mem 

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Matthias Kaehlcke]

On Sun, May 06, 2018 at 09:42:09AM +0200, Sedat Dilek wrote:
> On Wed, Apr 25, 2018 at 1:06 AM, Matthias Kaehlcke  wrote:
> > On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote:
> >> Hi Matthias,
> >>
> >> a big thank you for giving all the informations!
> >>
> >> I used your mka/llvm/v4.14_ext Git tree...
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
> >>
> >> ...and was able to compile with clang-6.0 from Debian/buster64 with...
> >>
> >> ...reverting the clang-3/clang-4 patches...
> >>
> >> user$ for p in 69e44656ae43 222b88977a00 cdfcf1e45537 26f14c9225a6
> >> 0385a18e9995 68dab143c9b4 ; do echo [ $p ] ; LC_ALL=C git revert
> >> --no-edit $p ; done
> >>
> >> 0001-Revert-CLANG3-core-clang-work-around-x86-regparm-int.patch
> >> 0002-Revert-CLANG4-futex-don-t-optimize-futex_detect_cmpx.patch
> >> 0003-Revert-CLANG4-Disable-lkdtm-when-ftrace-is-enabled.patch
> >> 0004-Revert-CLANG4-arm64-prefetch-Use-__builtin_arm_prefe.patch
> >> 0005-Revert-CLANG4-kbuild-Add-meabi-gnu-to-the-clang-para.patch
> >> 0006-Revert-CLANG4-crypto-arm64-aes-ce-Explicitly-pass-th.patch
> >>
> >> ...and needed two additional patches from upstream:
> >>
> >> 0007-kbuild-clang-remove-crufty-HOSTCFLAGS.patch <--- Label with
> >> BACKPORT (XXX: Backported; Required when using HOSTCC in make-line,
> >> see below)
> >> 0008-x86-xen-remove-the-use-of-VLAIS.patch <--- Label with UPSTREAM
> >> (XXX: cherry-picked)
> >>
> >> These 3 patches in your Git branch are in Linux v4.14.36...
> >>
> >> 9af5ddf981ed BACKPORT: kbuild: disable clang's default use of
> >> -fmerge-all-constants
> >> f24088a3842c BACKPORT: kbuild: Set KBUILD_CFLAGS before incl. arch Makefile
> >> d4dfe384346d UPSTREAM: kbuild: fix linker feature test macros when
> >> cross compiling with Clang
> >>
> >> ...and can be dropped.
> >> I do not know your work-flow/policy: Maybe you want to keep your
> >> patch-stack against vanilla Linux v4.14 - without stables from
> >> linux-stable-4.14.y.
> >
> > Yes, these patch stacks are based on vanilla Linux v4.14, one reason
> > is that it isn't a moving target. Also I think it makes it easier for
> > folks not merging LTS (though they probably should!) to locate all
> > patches, and it's fairly trivial to skip the (currently) few patches
> > not needed with the -stable tree.
> >
> >> For easy switching "mycompiler" I use a wrapper-script:
> >>
> >> root# cat /usr/bin/mycompiler
> >> #!/bin/bash
> >>
> >> clang-6.0 "$@"
> >> - EOF -
> >>
> >> user$ cp -v /boot/config-4.14.35-1-iniza-amd64 .config
> >> user$ MAKE="make V=1" ; COMPILER="mycompiler" ;
> >> MAKE_OPTS="CC=$COMPILER HOSTCC=$COMPILER"
> >> user$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
> >> silentoldconfig < /dev/null
> >>
> >> The diffconfig to my current kernel-config-4.14 looks like this...
> >>
> >> user$ ./scripts/diffconfig /boot/config-4.14.35-1-iniza-amd64 .config
> >> -ARCH_HAS_REFCOUNT y
> >> -BPF_JIT_ALWAYS_ON n
> >> -EXOFS_DEBUG n
> >> -EXOFS_FS m
> >> -GENERIC_CPU_VULNERABILITIES y
> >> -KASAN n
> >> -ORE m
> >> -PAGE_TABLE_ISOLATION y
> >> -RETPOLINE y
> >> -UNWINDER_FRAME_POINTER n
> >> -UNWINDER_GUESS n
> >> -UNWINDER_ORC y
> >> +FRAME_POINTER y
> >> +FRAME_POINTER_UNWINDER y
> >> +GUESS_UNWINDER n
> >> +HAVE_ARCH_KMEMCHECK y
> >> +HAVE_RELIABLE_STACKTRACE y
> >> +ORC_UNWINDER n
> >>
> >> Unfortunately, I cannot boot into the generated kernel on bare metal.
> >>
> >> Checking with QEMU (version: 2.12~rc3) and catching earlyprintk, I see 
> >> this...
> >>
> >> user$ echo $KPATH
> >> $HOME/src/linux-kernel/important-files
> >>
> >> user$ ls -al
> >> insgesamt 344916
> >> drwxr-xr-x  2 sdi sdi  4096 Apr 24 13:15 .
> >> drwxr-xr-x 20 sdi sdi  4096 Apr 24 13:13 ..
> >> -rw-r--r--  1 sdi sdi   4528416 Apr 24 12:42 bzImage
> >> lrwxrwxrwx  1 sdi sdi35 Apr 24 13:15 initrd.img ->
> >> initrd.img-4.14.0-1-iniza-llvmlinux
> >> -rw-r--r--  1 sdi sdi  25572955 Apr 24 13:08
> >> initrd.img-4.14.0-1-iniza-llvmlinux
> >> -rw-r--r--  1 sdi sdi   2887195 Apr 24 12:42 System.map
> >> -rwxr-xr-x  1 sdi sdi 326116744 Apr 24 12:42 vmlinux
> >>
> >> user$ sudo qemu-system-x86_64 -enable-kvm -M pc -kernel $KPATH/bzImage
> >> -initrd $KPATH/initrd.img -m 512 -net none -serial stdio -append
> >> "root=/dev/ram0 console=ttyS0 hung_task_panic=1
> >> earlyprintk=ttyS0,115200"
> >>
> >> Probing EDD (edd=off to disable)... ok
> >> [0.00] Linux version 4.14.0-1-iniza-llvmlinux
> >> (sedat.di...@gmail.com@iniza) (clang version 6.0.0-1
> >> (tags/RELEASE_600/final)) #1 SMP Tue Apr 24 12:42:21 CEST 2018
> >> [0.00] Command line: root=/dev/ram0 console=ttyS0
> >> hung_task_panic=1 earlyprintk=ttyS0,115200
> >> [0.00] x86/fpu: x87 FPU will use FXSAVE
> >> [0.00] e820: BIOS-provided physical RAM map:
> >> [0.00] BIOS-e820: [mem 0x-0x0009fbff] 
> >> usable
> >> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] 
> >> 

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

[...]
> Moreover, a test-case can be helpful, e.g. "Is clang clobbering RCX?"
> when it's a clang-bug.
>
> I tried to find some suitable test-case myself.
>
> The clang-source has a test-dir, but this is new to me.
>
> I tried to run a single test like test/Sema/asm.c in [1] with
> llvm-tools Debian-package which ships "lit.py" script.
>
[...]

> [1] https://raw.githubusercontent.com/llvm-mirror/clang/master/test/Sema/asm.c
> [2] https://llvm.org/docs/CommandGuide/lit.html
> [3] https://llvm.org/docs/TestingGuide.html
> [4] https://llvm.org/docs/TestSuiteMakefileGuide.html

In [5] are some hints on running a single test...

- Sedat -

[5] http://clang.llvm.org/hacking.html

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

[...]
> Moreover, a test-case can be helpful, e.g. "Is clang clobbering RCX?"
> when it's a clang-bug.
>
> I tried to find some suitable test-case myself.
>
> The clang-source has a test-dir, but this is new to me.
>
> I tried to run a single test like test/Sema/asm.c in [1] with
> llvm-tools Debian-package which ships "lit.py" script.
>
[...]

> [1] https://raw.githubusercontent.com/llvm-mirror/clang/master/test/Sema/asm.c
> [2] https://llvm.org/docs/CommandGuide/lit.html
> [3] https://llvm.org/docs/TestingGuide.html
> [4] https://llvm.org/docs/TestSuiteMakefileGuide.html

In [5] are some hints on running a single test...

- Sedat -

[5] http://clang.llvm.org/hacking.html

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Sun, May 6, 2018 at 9:41 AM, Dmitry Vyukov  wrote:
> On Sun, May 6, 2018 at 8:35 AM, Sedat Dilek  wrote:
>> On Mon, Apr 23, 2018 at 7:42 PM, Matthias Kaehlcke  wrote:
>> [...]
 [ ASM-GOTO ]

 Foremore, I have seen you have a "refs/sandbox/mka/llvm/v4.14" Git branch.
 Linux v4.14 is also an LTS release.
>>>
>>> Yes, there is also a follow up post:
>>> https://lkml.org/lkml/2017/11/22/943
>>>
 After Linux v4.9 "asm-goto" support was added which is GCC specific.
>>>
>>> asm-goto was optional until a few weeks ago, when x86 maintainers
>>> decided to make it mandatory, and thus break clang builds for x86:
>>>
>>> https://lkml.org/lkml/2018/4/2/486
>>>
 Is there a workaround to compile Linux-kernel with any CLANG
 version?
>>>
>>> You could revert the patch that makes asm-goto mandatory.
>>>
 You happen to know the status in LLVM upstream?
>>>
>>> I know people are actively working on this, but don't know an ETA.
>>>
>>
>> [ CC Dimitry ]
>>
>> Sorry for the late response.
>> This weekend I had some time to play with clang-7 and Linux-4.17-rcN.
>>
>> I tried with Linux v4.17-rc3-261-gc1c07416cdd4 and reverted the
>> mandatory patch [1].
>>
>> commit e501ce957a786ecd076ea0cfb10b114e6e4d0f40
>> "x86: Force asm-goto"
>>
>> This needed a follow up [2]...
>>
>> commit d0266046ad54e0c964941364cd82a0d0478ce286
>> "x86: Remove FAST_FEATURE_TESTS"
>>
>> ...but breaks my build.
>>
>> That seems to be a known issue [3] and Dimitry bisected this to [4].
>> Is there a fix for this?
>>
>> I have attached my kernel-config and the broken build-log.
>>
>> Hope this helps.
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e501ce957a786ecd076ea0cfb10b114e6e4d0f40
>> [2] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/include/asm/cpufeature.h?id=d0266046ad54e0c964941364cd82a0d0478ce286
>> [3] https://www.spinics.net/lists/linux-mm/msg147669.html
>> [4] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8bf705d130396e69c04cd8e6e010244ad2ce71f4
>
>
> Hi Sedat,
>
> Sorry for the breakage.
>
> This was reported and discussed here:
> https://groups.google.com/forum/#!topic/kasan-dev/oMgCP37n1vw
> The plan is to make clang behave the same way as gcc wrt asm
> constraint checking. But I don't know what's the progress.

Hi Dimitry,

that's the thread I looked into and also looked into the involved
commits and appropriate files in the linux-source without knowing of
[1].

Just just for the records...
I used the kernel-config of Debian's
linux-image-4.17.0-rc3-amd64-unsigned (4.17~rc3-1~exp1) as a base with
this modification:

$ cd /path/to/linux-source
$ LINUX_CONFIG="./.config"
$ scripts/config --file $LINUX_CONFIG --disable X86_X32

...and...

# CONFIG_KASAN is not set

...if this matters.

Kind regards,
- Sedat -

[1] https://bugs.llvm.org/show_bug.cgi?id=33587
[2] 
https://packages.debian.org/experimental/linux-image-4.17.0-rc3-amd64-unsigned

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Sedat Dilek]

On Sun, May 6, 2018 at 9:41 AM, Dmitry Vyukov  wrote:
> On Sun, May 6, 2018 at 8:35 AM, Sedat Dilek  wrote:
>> On Mon, Apr 23, 2018 at 7:42 PM, Matthias Kaehlcke  wrote:
>> [...]
 [ ASM-GOTO ]

 Foremore, I have seen you have a "refs/sandbox/mka/llvm/v4.14" Git branch.
 Linux v4.14 is also an LTS release.
>>>
>>> Yes, there is also a follow up post:
>>> https://lkml.org/lkml/2017/11/22/943
>>>
 After Linux v4.9 "asm-goto" support was added which is GCC specific.
>>>
>>> asm-goto was optional until a few weeks ago, when x86 maintainers
>>> decided to make it mandatory, and thus break clang builds for x86:
>>>
>>> https://lkml.org/lkml/2018/4/2/486
>>>
 Is there a workaround to compile Linux-kernel with any CLANG
 version?
>>>
>>> You could revert the patch that makes asm-goto mandatory.
>>>
 You happen to know the status in LLVM upstream?
>>>
>>> I know people are actively working on this, but don't know an ETA.
>>>
>>
>> [ CC Dimitry ]
>>
>> Sorry for the late response.
>> This weekend I had some time to play with clang-7 and Linux-4.17-rcN.
>>
>> I tried with Linux v4.17-rc3-261-gc1c07416cdd4 and reverted the
>> mandatory patch [1].
>>
>> commit e501ce957a786ecd076ea0cfb10b114e6e4d0f40
>> "x86: Force asm-goto"
>>
>> This needed a follow up [2]...
>>
>> commit d0266046ad54e0c964941364cd82a0d0478ce286
>> "x86: Remove FAST_FEATURE_TESTS"
>>
>> ...but breaks my build.
>>
>> That seems to be a known issue [3] and Dimitry bisected this to [4].
>> Is there a fix for this?
>>
>> I have attached my kernel-config and the broken build-log.
>>
>> Hope this helps.
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e501ce957a786ecd076ea0cfb10b114e6e4d0f40
>> [2] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/include/asm/cpufeature.h?id=d0266046ad54e0c964941364cd82a0d0478ce286
>> [3] https://www.spinics.net/lists/linux-mm/msg147669.html
>> [4] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8bf705d130396e69c04cd8e6e010244ad2ce71f4
>
>
> Hi Sedat,
>
> Sorry for the breakage.
>
> This was reported and discussed here:
> https://groups.google.com/forum/#!topic/kasan-dev/oMgCP37n1vw
> The plan is to make clang behave the same way as gcc wrt asm
> constraint checking. But I don't know what's the progress.

Hi Dimitry,

that's the thread I looked into and also looked into the involved
commits and appropriate files in the linux-source without knowing of
[1].

Just just for the records...
I used the kernel-config of Debian's
linux-image-4.17.0-rc3-amd64-unsigned (4.17~rc3-1~exp1) as a base with
this modification:

$ cd /path/to/linux-source
$ LINUX_CONFIG="./.config"
$ scripts/config --file $LINUX_CONFIG --disable X86_X32

...and...

# CONFIG_KASAN is not set

...if this matters.

Kind regards,
- Sedat -

[1] https://bugs.llvm.org/show_bug.cgi?id=33587
[2] 
https://packages.debian.org/experimental/linux-image-4.17.0-rc3-amd64-unsigned

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Dmitry Vyukov]

On Sun, May 6, 2018 at 8:35 AM, Sedat Dilek  wrote:
> On Mon, Apr 23, 2018 at 7:42 PM, Matthias Kaehlcke  wrote:
> [...]
>>> [ ASM-GOTO ]
>>>
>>> Foremore, I have seen you have a "refs/sandbox/mka/llvm/v4.14" Git branch.
>>> Linux v4.14 is also an LTS release.
>>
>> Yes, there is also a follow up post:
>> https://lkml.org/lkml/2017/11/22/943
>>
>>> After Linux v4.9 "asm-goto" support was added which is GCC specific.
>>
>> asm-goto was optional until a few weeks ago, when x86 maintainers
>> decided to make it mandatory, and thus break clang builds for x86:
>>
>> https://lkml.org/lkml/2018/4/2/486
>>
>>> Is there a workaround to compile Linux-kernel with any CLANG
>>> version?
>>
>> You could revert the patch that makes asm-goto mandatory.
>>
>>> You happen to know the status in LLVM upstream?
>>
>> I know people are actively working on this, but don't know an ETA.
>>
>
> [ CC Dimitry ]
>
> Sorry for the late response.
> This weekend I had some time to play with clang-7 and Linux-4.17-rcN.
>
> I tried with Linux v4.17-rc3-261-gc1c07416cdd4 and reverted the
> mandatory patch [1].
>
> commit e501ce957a786ecd076ea0cfb10b114e6e4d0f40
> "x86: Force asm-goto"
>
> This needed a follow up [2]...
>
> commit d0266046ad54e0c964941364cd82a0d0478ce286
> "x86: Remove FAST_FEATURE_TESTS"
>
> ...but breaks my build.
>
> That seems to be a known issue [3] and Dimitry bisected this to [4].
> Is there a fix for this?
>
> I have attached my kernel-config and the broken build-log.
>
> Hope this helps.
>
> Regards,
> - Sedat -
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e501ce957a786ecd076ea0cfb10b114e6e4d0f40
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/include/asm/cpufeature.h?id=d0266046ad54e0c964941364cd82a0d0478ce286
> [3] https://www.spinics.net/lists/linux-mm/msg147669.html
> [4] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8bf705d130396e69c04cd8e6e010244ad2ce71f4


Hi Sedat,

Sorry for the breakage.

This was reported and discussed here:
https://groups.google.com/forum/#!topic/kasan-dev/oMgCP37n1vw
The plan is to make clang behave the same way as gcc wrt asm
constraint checking. But I don't know what's the progress.

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Dmitry Vyukov]

On Sun, May 6, 2018 at 8:35 AM, Sedat Dilek  wrote:
> On Mon, Apr 23, 2018 at 7:42 PM, Matthias Kaehlcke  wrote:
> [...]
>>> [ ASM-GOTO ]
>>>
>>> Foremore, I have seen you have a "refs/sandbox/mka/llvm/v4.14" Git branch.
>>> Linux v4.14 is also an LTS release.
>>
>> Yes, there is also a follow up post:
>> https://lkml.org/lkml/2017/11/22/943
>>
>>> After Linux v4.9 "asm-goto" support was added which is GCC specific.
>>
>> asm-goto was optional until a few weeks ago, when x86 maintainers
>> decided to make it mandatory, and thus break clang builds for x86:
>>
>> https://lkml.org/lkml/2018/4/2/486
>>
>>> Is there a workaround to compile Linux-kernel with any CLANG
>>> version?
>>
>> You could revert the patch that makes asm-goto mandatory.
>>
>>> You happen to know the status in LLVM upstream?
>>
>> I know people are actively working on this, but don't know an ETA.
>>
>
> [ CC Dimitry ]
>
> Sorry for the late response.
> This weekend I had some time to play with clang-7 and Linux-4.17-rcN.
>
> I tried with Linux v4.17-rc3-261-gc1c07416cdd4 and reverted the
> mandatory patch [1].
>
> commit e501ce957a786ecd076ea0cfb10b114e6e4d0f40
> "x86: Force asm-goto"
>
> This needed a follow up [2]...
>
> commit d0266046ad54e0c964941364cd82a0d0478ce286
> "x86: Remove FAST_FEATURE_TESTS"
>
> ...but breaks my build.
>
> That seems to be a known issue [3] and Dimitry bisected this to [4].
> Is there a fix for this?
>
> I have attached my kernel-config and the broken build-log.
>
> Hope this helps.
>
> Regards,
> - Sedat -
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e501ce957a786ecd076ea0cfb10b114e6e4d0f40
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/include/asm/cpufeature.h?id=d0266046ad54e0c964941364cd82a0d0478ce286
> [3] https://www.spinics.net/lists/linux-mm/msg147669.html
> [4] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8bf705d130396e69c04cd8e6e010244ad2ce71f4


Hi Sedat,

Sorry for the breakage.

This was reported and discussed here:
https://groups.google.com/forum/#!topic/kasan-dev/oMgCP37n1vw
The plan is to make clang behave the same way as gcc wrt asm
constraint checking. But I don't know what's the progress.

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Matthias Kaehlcke]

On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote:
> Hi Matthias,
> 
> a big thank you for giving all the informations!
> 
> I used your mka/llvm/v4.14_ext Git tree...
> 
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
> 
> ...and was able to compile with clang-6.0 from Debian/buster64 with...
> 
> ...reverting the clang-3/clang-4 patches...
> 
> user$ for p in 69e44656ae43 222b88977a00 cdfcf1e45537 26f14c9225a6
> 0385a18e9995 68dab143c9b4 ; do echo [ $p ] ; LC_ALL=C git revert
> --no-edit $p ; done
> 
> 0001-Revert-CLANG3-core-clang-work-around-x86-regparm-int.patch
> 0002-Revert-CLANG4-futex-don-t-optimize-futex_detect_cmpx.patch
> 0003-Revert-CLANG4-Disable-lkdtm-when-ftrace-is-enabled.patch
> 0004-Revert-CLANG4-arm64-prefetch-Use-__builtin_arm_prefe.patch
> 0005-Revert-CLANG4-kbuild-Add-meabi-gnu-to-the-clang-para.patch
> 0006-Revert-CLANG4-crypto-arm64-aes-ce-Explicitly-pass-th.patch
> 
> ...and needed two additional patches from upstream:
> 
> 0007-kbuild-clang-remove-crufty-HOSTCFLAGS.patch <--- Label with
> BACKPORT (XXX: Backported; Required when using HOSTCC in make-line,
> see below)
> 0008-x86-xen-remove-the-use-of-VLAIS.patch <--- Label with UPSTREAM
> (XXX: cherry-picked)
> 
> These 3 patches in your Git branch are in Linux v4.14.36...
> 
> 9af5ddf981ed BACKPORT: kbuild: disable clang's default use of
> -fmerge-all-constants
> f24088a3842c BACKPORT: kbuild: Set KBUILD_CFLAGS before incl. arch Makefile
> d4dfe384346d UPSTREAM: kbuild: fix linker feature test macros when
> cross compiling with Clang
> 
> ...and can be dropped.
> I do not know your work-flow/policy: Maybe you want to keep your
> patch-stack against vanilla Linux v4.14 - without stables from
> linux-stable-4.14.y.

Yes, these patch stacks are based on vanilla Linux v4.14, one reason
is that it isn't a moving target. Also I think it makes it easier for
folks not merging LTS (though they probably should!) to locate all
patches, and it's fairly trivial to skip the (currently) few patches
not needed with the -stable tree.

> For easy switching "mycompiler" I use a wrapper-script:
> 
> root# cat /usr/bin/mycompiler
> #!/bin/bash
> 
> clang-6.0 "$@"
> - EOF -
> 
> user$ cp -v /boot/config-4.14.35-1-iniza-amd64 .config
> user$ MAKE="make V=1" ; COMPILER="mycompiler" ;
> MAKE_OPTS="CC=$COMPILER HOSTCC=$COMPILER"
> user$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
> silentoldconfig < /dev/null
> 
> The diffconfig to my current kernel-config-4.14 looks like this...
> 
> user$ ./scripts/diffconfig /boot/config-4.14.35-1-iniza-amd64 .config
> -ARCH_HAS_REFCOUNT y
> -BPF_JIT_ALWAYS_ON n
> -EXOFS_DEBUG n
> -EXOFS_FS m
> -GENERIC_CPU_VULNERABILITIES y
> -KASAN n
> -ORE m
> -PAGE_TABLE_ISOLATION y
> -RETPOLINE y
> -UNWINDER_FRAME_POINTER n
> -UNWINDER_GUESS n
> -UNWINDER_ORC y
> +FRAME_POINTER y
> +FRAME_POINTER_UNWINDER y
> +GUESS_UNWINDER n
> +HAVE_ARCH_KMEMCHECK y
> +HAVE_RELIABLE_STACKTRACE y
> +ORC_UNWINDER n
> 
> Unfortunately, I cannot boot into the generated kernel on bare metal.
> 
> Checking with QEMU (version: 2.12~rc3) and catching earlyprintk, I see this...
> 
> user$ echo $KPATH
> $HOME/src/linux-kernel/important-files
> 
> user$ ls -al
> insgesamt 344916
> drwxr-xr-x  2 sdi sdi  4096 Apr 24 13:15 .
> drwxr-xr-x 20 sdi sdi  4096 Apr 24 13:13 ..
> -rw-r--r--  1 sdi sdi   4528416 Apr 24 12:42 bzImage
> lrwxrwxrwx  1 sdi sdi35 Apr 24 13:15 initrd.img ->
> initrd.img-4.14.0-1-iniza-llvmlinux
> -rw-r--r--  1 sdi sdi  25572955 Apr 24 13:08
> initrd.img-4.14.0-1-iniza-llvmlinux
> -rw-r--r--  1 sdi sdi   2887195 Apr 24 12:42 System.map
> -rwxr-xr-x  1 sdi sdi 326116744 Apr 24 12:42 vmlinux
> 
> user$ sudo qemu-system-x86_64 -enable-kvm -M pc -kernel $KPATH/bzImage
> -initrd $KPATH/initrd.img -m 512 -net none -serial stdio -append
> "root=/dev/ram0 console=ttyS0 hung_task_panic=1
> earlyprintk=ttyS0,115200"
> 
> Probing EDD (edd=off to disable)... ok
> [0.00] Linux version 4.14.0-1-iniza-llvmlinux
> (sedat.di...@gmail.com@iniza) (clang version 6.0.0-1
> (tags/RELEASE_600/final)) #1 SMP Tue Apr 24 12:42:21 CEST 2018
> [0.00] Command line: root=/dev/ram0 console=ttyS0
> hung_task_panic=1 earlyprintk=ttyS0,115200
> [0.00] x86/fpu: x87 FPU will use FXSAVE
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x1ffd] usable
> [0.00] BIOS-e820: [mem 0x1ffe-0x1fff] reserved
> [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
> [0.00] BIOS-e820: [mem 0xfffc-0x] reserved
> [0.00] bootconsole [earlyser0] enabled
> [0.00] NX 

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Matthias Kaehlcke]

On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote:
> Hi Matthias,
> 
> a big thank you for giving all the informations!
> 
> I used your mka/llvm/v4.14_ext Git tree...
> 
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
> 
> ...and was able to compile with clang-6.0 from Debian/buster64 with...
> 
> ...reverting the clang-3/clang-4 patches...
> 
> user$ for p in 69e44656ae43 222b88977a00 cdfcf1e45537 26f14c9225a6
> 0385a18e9995 68dab143c9b4 ; do echo [ $p ] ; LC_ALL=C git revert
> --no-edit $p ; done
> 
> 0001-Revert-CLANG3-core-clang-work-around-x86-regparm-int.patch
> 0002-Revert-CLANG4-futex-don-t-optimize-futex_detect_cmpx.patch
> 0003-Revert-CLANG4-Disable-lkdtm-when-ftrace-is-enabled.patch
> 0004-Revert-CLANG4-arm64-prefetch-Use-__builtin_arm_prefe.patch
> 0005-Revert-CLANG4-kbuild-Add-meabi-gnu-to-the-clang-para.patch
> 0006-Revert-CLANG4-crypto-arm64-aes-ce-Explicitly-pass-th.patch
> 
> ...and needed two additional patches from upstream:
> 
> 0007-kbuild-clang-remove-crufty-HOSTCFLAGS.patch <--- Label with
> BACKPORT (XXX: Backported; Required when using HOSTCC in make-line,
> see below)
> 0008-x86-xen-remove-the-use-of-VLAIS.patch <--- Label with UPSTREAM
> (XXX: cherry-picked)
> 
> These 3 patches in your Git branch are in Linux v4.14.36...
> 
> 9af5ddf981ed BACKPORT: kbuild: disable clang's default use of
> -fmerge-all-constants
> f24088a3842c BACKPORT: kbuild: Set KBUILD_CFLAGS before incl. arch Makefile
> d4dfe384346d UPSTREAM: kbuild: fix linker feature test macros when
> cross compiling with Clang
> 
> ...and can be dropped.
> I do not know your work-flow/policy: Maybe you want to keep your
> patch-stack against vanilla Linux v4.14 - without stables from
> linux-stable-4.14.y.

Yes, these patch stacks are based on vanilla Linux v4.14, one reason
is that it isn't a moving target. Also I think it makes it easier for
folks not merging LTS (though they probably should!) to locate all
patches, and it's fairly trivial to skip the (currently) few patches
not needed with the -stable tree.

> For easy switching "mycompiler" I use a wrapper-script:
> 
> root# cat /usr/bin/mycompiler
> #!/bin/bash
> 
> clang-6.0 "$@"
> - EOF -
> 
> user$ cp -v /boot/config-4.14.35-1-iniza-amd64 .config
> user$ MAKE="make V=1" ; COMPILER="mycompiler" ;
> MAKE_OPTS="CC=$COMPILER HOSTCC=$COMPILER"
> user$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
> silentoldconfig < /dev/null
> 
> The diffconfig to my current kernel-config-4.14 looks like this...
> 
> user$ ./scripts/diffconfig /boot/config-4.14.35-1-iniza-amd64 .config
> -ARCH_HAS_REFCOUNT y
> -BPF_JIT_ALWAYS_ON n
> -EXOFS_DEBUG n
> -EXOFS_FS m
> -GENERIC_CPU_VULNERABILITIES y
> -KASAN n
> -ORE m
> -PAGE_TABLE_ISOLATION y
> -RETPOLINE y
> -UNWINDER_FRAME_POINTER n
> -UNWINDER_GUESS n
> -UNWINDER_ORC y
> +FRAME_POINTER y
> +FRAME_POINTER_UNWINDER y
> +GUESS_UNWINDER n
> +HAVE_ARCH_KMEMCHECK y
> +HAVE_RELIABLE_STACKTRACE y
> +ORC_UNWINDER n
> 
> Unfortunately, I cannot boot into the generated kernel on bare metal.
> 
> Checking with QEMU (version: 2.12~rc3) and catching earlyprintk, I see this...
> 
> user$ echo $KPATH
> $HOME/src/linux-kernel/important-files
> 
> user$ ls -al
> insgesamt 344916
> drwxr-xr-x  2 sdi sdi  4096 Apr 24 13:15 .
> drwxr-xr-x 20 sdi sdi  4096 Apr 24 13:13 ..
> -rw-r--r--  1 sdi sdi   4528416 Apr 24 12:42 bzImage
> lrwxrwxrwx  1 sdi sdi35 Apr 24 13:15 initrd.img ->
> initrd.img-4.14.0-1-iniza-llvmlinux
> -rw-r--r--  1 sdi sdi  25572955 Apr 24 13:08
> initrd.img-4.14.0-1-iniza-llvmlinux
> -rw-r--r--  1 sdi sdi   2887195 Apr 24 12:42 System.map
> -rwxr-xr-x  1 sdi sdi 326116744 Apr 24 12:42 vmlinux
> 
> user$ sudo qemu-system-x86_64 -enable-kvm -M pc -kernel $KPATH/bzImage
> -initrd $KPATH/initrd.img -m 512 -net none -serial stdio -append
> "root=/dev/ram0 console=ttyS0 hung_task_panic=1
> earlyprintk=ttyS0,115200"
> 
> Probing EDD (edd=off to disable)... ok
> [0.00] Linux version 4.14.0-1-iniza-llvmlinux
> (sedat.di...@gmail.com@iniza) (clang version 6.0.0-1
> (tags/RELEASE_600/final)) #1 SMP Tue Apr 24 12:42:21 CEST 2018
> [0.00] Command line: root=/dev/ram0 console=ttyS0
> hung_task_panic=1 earlyprintk=ttyS0,115200
> [0.00] x86/fpu: x87 FPU will use FXSAVE
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x1ffd] usable
> [0.00] BIOS-e820: [mem 0x1ffe-0x1fff] reserved
> [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
> [0.00] BIOS-e820: [mem 0xfffc-0x] reserved
> [0.00] bootconsole [earlyser0] enabled
> [0.00] NX 

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Matthias Kaehlcke]

Hi Sedat,

On Mon, Apr 23, 2018 at 03:56:41PM +0200, Sedat Dilek wrote:
> [ CC Nick ]
> [ CC Arnd ]
> [ CC JF ]
 
> I wrote some early documentation (wiki) and tested/booted a
> clang-compiled kernel on x86-64 bare metal.
> The project was called "lll-project" these days.
> The followup - LLVMlinux project - seems to be somehow dead?

Yes, I think it stalled in 2014 or so. There is still a mailing list
with very occasional traffic.

> After reading your posting, I got really excited and had a quick look
> over the Linux v4.9.y-LTS patch-stack with additional stuff:
> 
> $ git fetch https://chromium.googlesource.com/chromiumos/third_party/kernel
> refs/sandbox/mka/llvm/v4.9_ext
> $ git checkout -b llvm_v4.9_ext FETCH_HEAD
> 
> I like your commit subjects and messages.
> 
> Before starting to compile I have some questions, I hope you can answer them.
> 
> [ CLANG-VERSION ]
> 
> Here on Debian/testing (will get Version 10 with codename "buster")
> AMD64 I have the choice of installing CLANG v4.0.1, v5.0.1 and v6.0.0.
> As you point out LLVM/CLANG v5.0 or higher are a good and faster
> choice than v4.0.
> Using CLANG >= 5.0 makes the *CLANG* patch-series obsolete?

Correct, preferably use clang v6 or newer.

> [ REFRESH PATCH-STACK ]
> 
> What about the *FROMGIT* and *CUSTOM* patch-series?
> Are they in upstream in the meantime?

CUSTOM patches address issues in older kernels that have been fixed
upstream in a different, not easily backportable way. They will never
land in upstream.

FROMGIT patches should eventually land upstream, since they were taken
from a maintainer tree.

The commit message includes the upstream git hash, so you can easily
check if it has landed (though in some cases the hash changes ...)

> If yes, will you refresh this v4.9.y-LTS patch-stack?

I eventually will, the two FROMGIT patches are relatively recent, and
respinning the trees just to update the tags isn't one of my
priorities.

> [ ASM-GOTO ]
> 
> Foremore, I have seen you have a "refs/sandbox/mka/llvm/v4.14" Git branch.
> Linux v4.14 is also an LTS release.

Yes, there is also a follow up post:
https://lkml.org/lkml/2017/11/22/943

> After Linux v4.9 "asm-goto" support was added which is GCC specific.

asm-goto was optional until a few weeks ago, when x86 maintainers
decided to make it mandatory, and thus break clang builds for x86:

https://lkml.org/lkml/2018/4/2/486

> Is there a workaround to compile Linux-kernel with any CLANG
> version?

You could revert the patch that makes asm-goto mandatory.

> You happen to know the status in LLVM upstream?

I know people are actively working on this, but don't know an ETA.

> [ X86-EFLAGS/IF ]
> 
> AFAICS, I remember an EFLAGS/IF problem on X86 and interrupt handling.
> You happen to know if this is fixed in LLVM upstream?
> Some LLVM developers were interested in fixing this.
> Can you comment on this, JF (we had some email conversation in private in 
> 2016)?

Yes, this has been fixed recently:
https://bugs.llvm.org/show_bug.cgi?id=36028

Cheers

Matthias

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

[Matthias Kaehlcke]

Hi Sedat,

On Mon, Apr 23, 2018 at 03:56:41PM +0200, Sedat Dilek wrote:
> [ CC Nick ]
> [ CC Arnd ]
> [ CC JF ]
 
> I wrote some early documentation (wiki) and tested/booted a
> clang-compiled kernel on x86-64 bare metal.
> The project was called "lll-project" these days.
> The followup - LLVMlinux project - seems to be somehow dead?

Yes, I think it stalled in 2014 or so. There is still a mailing list
with very occasional traffic.

> After reading your posting, I got really excited and had a quick look
> over the Linux v4.9.y-LTS patch-stack with additional stuff:
> 
> $ git fetch https://chromium.googlesource.com/chromiumos/third_party/kernel
> refs/sandbox/mka/llvm/v4.9_ext
> $ git checkout -b llvm_v4.9_ext FETCH_HEAD
> 
> I like your commit subjects and messages.
> 
> Before starting to compile I have some questions, I hope you can answer them.
> 
> [ CLANG-VERSION ]
> 
> Here on Debian/testing (will get Version 10 with codename "buster")
> AMD64 I have the choice of installing CLANG v4.0.1, v5.0.1 and v6.0.0.
> As you point out LLVM/CLANG v5.0 or higher are a good and faster
> choice than v4.0.
> Using CLANG >= 5.0 makes the *CLANG* patch-series obsolete?

Correct, preferably use clang v6 or newer.

> [ REFRESH PATCH-STACK ]
> 
> What about the *FROMGIT* and *CUSTOM* patch-series?
> Are they in upstream in the meantime?

CUSTOM patches address issues in older kernels that have been fixed
upstream in a different, not easily backportable way. They will never
land in upstream.

FROMGIT patches should eventually land upstream, since they were taken
from a maintainer tree.

The commit message includes the upstream git hash, so you can easily
check if it has landed (though in some cases the hash changes ...)

> If yes, will you refresh this v4.9.y-LTS patch-stack?

I eventually will, the two FROMGIT patches are relatively recent, and
respinning the trees just to update the tags isn't one of my
priorities.

> [ ASM-GOTO ]
> 
> Foremore, I have seen you have a "refs/sandbox/mka/llvm/v4.14" Git branch.
> Linux v4.14 is also an LTS release.

Yes, there is also a follow up post:
https://lkml.org/lkml/2017/11/22/943

> After Linux v4.9 "asm-goto" support was added which is GCC specific.

asm-goto was optional until a few weeks ago, when x86 maintainers
decided to make it mandatory, and thus break clang builds for x86:

https://lkml.org/lkml/2018/4/2/486

> Is there a workaround to compile Linux-kernel with any CLANG
> version?

You could revert the patch that makes asm-goto mandatory.

> You happen to know the status in LLVM upstream?

I know people are actively working on this, but don't know an ETA.

> [ X86-EFLAGS/IF ]
> 
> AFAICS, I remember an EFLAGS/IF problem on X86 and interrupt handling.
> You happen to know if this is fixed in LLVM upstream?
> Some LLVM developers were interested in fixing this.
> Can you comment on this, JF (we had some email conversation in private in 
> 2016)?

Yes, this has been fixed recently:
https://bugs.llvm.org/show_bug.cgi?id=36028

Cheers

Matthias