Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1654570 > unrolled thread

sparc gcc 7.1 compile issue

Back to article view | Back to linux.kernel

Contents

  sparc gcc 7.1 compile issue Waldemar Brodkorb <wbx@openadk.org> - 2017-05-31 21:40 +0200
    Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-05-31 23:20 +0200
      Re: sparc gcc 7.1 compile issue Waldemar Brodkorb <wbx@openadk.org> - 2017-06-01 14:20 +0200
        Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-01 14:50 +0200
        Re: sparc gcc 7.1 compile issue Anatoly Pugachev <matorola@gmail.com> - 2017-06-01 14:50 +0200
          Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-06-01 18:50 +0200
      Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-02 11:20 +0200
        Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-06-02 16:30 +0200
          Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-02 18:40 +0200
            Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-06-02 19:30 +0200
              Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-04 15:20 +0200
                Re: sparc gcc 7.1 compile issue Waldemar Brodkorb <wbx@openadk.org> - 2017-06-04 16:50 +0200
                  Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-04 17:10 +0200
                  Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-06-04 22:30 +0200
                    Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-04 22:30 +0200
                Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-04 22:30 +0200
                  Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-04 22:40 +0200
                  Re: sparc gcc 7.1 compile issue John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2017-06-04 22:40 +0200
                    Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-06-04 22:40 +0200
                  Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-06-04 22:40 +0200
                Re: sparc gcc 7.1 compile issue David Miller <davem@davemloft.net> - 2017-06-04 22:30 +0200

Page 1 of 2  [1] 2  Next page →

#1654570 — sparc gcc 7.1 compile issue

[Multipart message — attachments visible in raw view] — view raw

Hi,

when compiling a kernel (4.11.3) for sparc with gcc 7.1 and 
attached config I get following error:

/usr/bin/make -f ./scripts/Makefile.build obj=arch/sparc/mm
  /home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/bin/sparc-openadk-linux-uclibc-gcc -Wp,-MD,arch/sparc/mm/.init_32.o.d  -nostdinc -isystem /home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/lib/gcc/sparc-openadk-linux-uclibc/7.1.0/include -I./arch/sparc/include -I./arch/sparc/include/generated/uapi -I./arch/sparc/include/generated  -I./include -I./arch/sparc/include/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7 -Wa,-Av8 -fno-delete-null-pointer-checks -Wno-frame-address -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror    -DKBUILD_BASENAME='"init_32"'  -DKBUILD_MODNAME='"init_32"' -c -o arch/sparc/mm/init_32.o arch/sparc/mm/init_32.c
In file included from ./include/linux/string.h:18:0,
                 from ./include/linux/bitmap.h:8,
                 from ./include/linux/cpumask.h:11,
                 from ./arch/sparc/include/asm/smp_32.h:14,
                 from ./arch/sparc/include/asm/smp.h:6,
                 from ./arch/sparc/include/asm/switch_to_32.h:4,
                 from ./arch/sparc/include/asm/switch_to.h:6,
                 from ./arch/sparc/include/asm/ptrace.h:118,
                 from ./arch/sparc/include/asm/thread_info_32.h:18,
                 from ./arch/sparc/include/asm/thread_info.h:6,
                 from ./include/linux/thread_info.h:25,
                 from ./include/asm-generic/preempt.h:4,
                 from ./arch/sparc/include/generated/asm/preempt.h:1,
                 from ./include/linux/preempt.h:80,
                 from ./include/linux/spinlock.h:50,
                 from ./include/linux/seqlock.h:35,
                 from ./include/linux/time.h:5,
                 from ./include/linux/stat.h:18,
                 from ./include/linux/module.h:10,
                 from arch/sparc/mm/init_32.c:10:
arch/sparc/mm/init_32.c: In function 'mem_init':
./arch/sparc/include/asm/string.h:17:29: error: '__builtin_memset' writing 4096 bytes into a region of size 4 overflows the destination [-Werror=stringop-overflow=]
 #define memset(s, c, count) __builtin_memset(s, c, count)
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/mm/init_32.c:293:2: note: in expansion of macro 'memset'
  memset((void *)&empty_zero_page, 0, PAGE_SIZE);
  ^~~~~~
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 'arch/sparc/mm/init_32.o' failed
make[8]: *** [arch/sparc/mm/init_32.o] Error 1
scripts/Makefile.build:553: recipe for target 'arch/sparc/mm' failed
make[7]: *** [arch/sparc/mm] Error 2
Makefile:1002: recipe for target 'arch/sparc' failed
make[6]: *** [arch/sparc] Error 2
/home/wbx/openadk/mk/kernel-build.mk:77: recipe for target '/home/wbx/openadk/build_qemu-sparc_uclibc-ng_v8/linux/vmlinux' failed
make[5]: *** [/home/wbx/openadk/build_qemu-sparc_uclibc-ng_v8/linux/vmlinux] Error 2
Makefile:177: recipe for target 'sparc-compile' failed
make[4]: *** [sparc-compile] Error 2
mk/build.mk:218: recipe for target 'target/compile' failed
make[3]: *** [target/compile] Error 2
/home/wbx/openadk/mk/build.mk:170: recipe for target 'world' failed
make[2]: *** [world] Error 2

How can this be fixed? 

best regards
 Waldemar

[toc] | [next] | [standalone]

#1654633

A fix for this is in Linus's tree and was submitted to -stable last
night:

====================
commit deba804c90642c8ed0f15ac1083663976d578f54
Author: Orlando Arias <oarias@knights.ucf.edu>
Date:   Tue May 16 15:34:00 2017 -0400

    sparc: Fix -Wstringop-overflow warning
    
    Greetings,
    
    GCC 7 introduced the -Wstringop-overflow flag to detect buffer overflows
    in calls to string handling functions [1][2]. Due to the way
    ``empty_zero_page'' is declared in arch/sparc/include/setup.h, this
    causes a warning to trigger at compile time in the function mem_init(),
    which is subsequently converted to an error. The ensuing patch fixes
    this issue and aligns the declaration of empty_zero_page to that of
    other architectures. Thank you.
    
    Cheers,
    Orlando.
    
    [1] https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02308.html
    [2] https://gcc.gnu.org/gcc-7/changes.html
    
    Signed-off-by: Orlando Arias <oarias@knights.ucf.edu>
    
    --------------------------------------------------------------------------------
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc/include/asm/pgtable_32.h b/arch/sparc/include/asm/pgtable_32.h
index ce6f569..cf19072 100644
--- a/arch/sparc/include/asm/pgtable_32.h
+++ b/arch/sparc/include/asm/pgtable_32.h
@@ -91,9 +91,9 @@ extern unsigned long pfn_base;
  * ZERO_PAGE is a global shared page that is always zero: used
  * for zero-mapped memory areas etc..
  */
-extern unsigned long empty_zero_page;
+extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 
-#define ZERO_PAGE(vaddr) (virt_to_page(&empty_zero_page))
+#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page))
 
 /*
  * In general all page table modifications should use the V8 atomic
diff --git a/arch/sparc/include/asm/setup.h b/arch/sparc/include/asm/setup.h
index 478bf6bb..3fae200 100644
--- a/arch/sparc/include/asm/setup.h
+++ b/arch/sparc/include/asm/setup.h
@@ -16,7 +16,7 @@ extern char reboot_command[];
  */
 extern unsigned char boot_cpu_id;
 
-extern unsigned long empty_zero_page;
+extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 
 extern int serial_console;
 static inline int con_is_present(void)
diff --git a/arch/sparc/mm/init_32.c b/arch/sparc/mm/init_32.c
index c6afe98..3bd0d51 100644
--- a/arch/sparc/mm/init_32.c
+++ b/arch/sparc/mm/init_32.c
@@ -290,7 +290,7 @@ void __init mem_init(void)
 
 
 	/* Saves us work later. */
-	memset((void *)&empty_zero_page, 0, PAGE_SIZE);
+	memset((void *)empty_zero_page, 0, PAGE_SIZE);
 
 	i = last_valid_pfn >> ((20 - PAGE_SHIFT) + 5);
 	i += 1;

[toc] | [prev] | [next] | [standalone]

#1655081

Hi David,

thank you very much.

best regards
 Waldemar

[toc] | [prev] | [next] | [standalone]

#1655108

On Thu, Jun 01, 2017 at 03:46:04PM +0300, Anatoly Pugachev wrote:
> on the same topic , latest git does not compile for me with gcc-7.0.1
> gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
> (Debian 7-20170407-1)

Let's first try this again once the 7.1.0-6 gcc-7 package has built
successfully in Debian experimental. It's been uploaded for a while
now but we have the usual issues with the gcc testsuite crashing the
kernel.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1655110

on the same topic , latest git does not compile for me with gcc-7.0.1
gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
(Debian 7-20170407-1)

$ make
...
  CC      arch/sparc/kernel/ds.o
arch/sparc/kernel/ds.c: In function ‘register_services’:
arch/sparc/kernel/ds.c:912:3: error: ‘strcpy’: writing at least 1 byte
into a region of size 0 overflows the destination
[-Werror=stringop-overflow ]
   strcpy(pbuf.req.svc_id, cp->service_id);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
scripts/Makefile.build:302: recipe for target 'arch/sparc/kernel/ds.o' failed
make[2]: *** [arch/sparc/kernel/ds.o] Error 1
scripts/Makefile.build:561: recipe for target 'arch/sparc/kernel' failed
make[1]: *** [arch/sparc/kernel] Error 2
Makefile:1016: recipe for target 'arch/sparc' failed
make: *** [arch/sparc] Error 2

I'm able to pass arch/sparc/kernel/ compilation, if I change/add to
arch/sparc/kernel/Makefile :

-ccflags-y := -Werror
+ccflags-y := -Werror -Wno-error=stringop-overflow

but even with that hack, i'm unable to compile kernel, getting in the
end of make:
...
  LD      init/built-in.o
  LD      vmlinux.o
  MODPOST vmlinux.o
ipc/built-in.o: In function `mq_attr_ok.isra.0':
mqueue.c:(.text+0xc490): undefined reference to `__multi3'
drivers/built-in.o: In function `dm_vcalloc':
(.text+0xc9e98): undefined reference to `__multi3'
Makefile:997: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

[toc] | [prev] | [next] | [standalone]

#1655495

From: Anatoly Pugachev <matorola@gmail.com>
Date: Thu, 1 Jun 2017 15:46:04 +0300

> on the same topic , latest git does not compile for me with gcc-7.0.1
> gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
> (Debian 7-20170407-1)
> 
> $ make
> ...
>   CC      arch/sparc/kernel/ds.o
> arch/sparc/kernel/ds.c: In function ‘register_services’:
> arch/sparc/kernel/ds.c:912:3: error: ‘strcpy’: writing at least 1 byte
> into a region of size 0 overflows the destination
> [-Werror=stringop-overflow ]
>    strcpy(pbuf.req.svc_id, cp->service_id);
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That's easy enough to fix, I've pushed the patch below to 'sparc' GIT.

>   MODPOST vmlinux.o
> ipc/built-in.o: In function `mq_attr_ok.isra.0':
> mqueue.c:(.text+0xc490): undefined reference to `__multi3'
> drivers/built-in.o: In function `dm_vcalloc':
> (.text+0xc9e98): undefined reference to `__multi3'
> Makefile:997: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1

This, on the other hand.... wonder why it wants to do a 128-bit multiply
when the MQ attribute struct is just 64-bit values...

====================
From 0fde7ad71ee371ede73b3f326e58f9e8d102feb6 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Thu, 1 Jun 2017 09:42:46 -0700
Subject: [PATCH] sparc64: Fix build warnings with gcc 7.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

arch/sparc/kernel/ds.c: In function ‘register_services’:
arch/sparc/kernel/ds.c:912:3: error: ‘strcpy’: writing at least 1 byte
into a region of size 0 overflows the destination

Reported-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 arch/sparc/kernel/ds.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/ds.c b/arch/sparc/kernel/ds.c
index b542cc7..f87265a 100644
--- a/arch/sparc/kernel/ds.c
+++ b/arch/sparc/kernel/ds.c
@@ -909,7 +909,7 @@ static int register_services(struct ds_info *dp)
 		pbuf.req.handle = cp->handle;
 		pbuf.req.major = 1;
 		pbuf.req.minor = 0;
-		strcpy(pbuf.req.svc_id, cp->service_id);
+		strcpy(pbuf.id_buf, cp->service_id);
 
 		err = __ds_send(lp, &pbuf, msg_len);
 		if (err > 0)
-- 
2.1.2.532.g19b5d50

[toc] | [prev] | [next] | [standalone]

#1656049

On Wed, May 31, 2017 at 05:10:08PM -0400, David Miller wrote:
> A fix for this is in Linus's tree and was submitted to -stable last
> night:

What remains to be fixed though is that the gcc-7 testsuite
*reproducibly* kills the kernel on sparc64 when building with more than
around 20 jobs:

[617633.376777] fib.exe[242839]: segfault at fff8000100045a20 ip fff800010095c180 (rpc fff800010095cfb4) sp fff8000100045b10 error 30002 in libc-2.24.so[fff80001008dc000+15e000]
[617635.588137] Kernel unaligned access at TPC[4a3c4c] idle_cpu+0x2c/0x60
[617635.588202] Unable to handle kernel paging request in mna handler
[617635.588209]  at virtual address 8000000000db742f
[617635.588227] Kernel unaligned access at TPC[4a3c4c] idle_cpu+0x2c/0x60
[617635.588235] Unable to handle kernel paging request in mna handler
[617635.588240]  at virtual address 8000000000db742f
[617635.588244] current->{active_,}mm->context = 0000000000000f52
[617635.588248] current->{active_,}mm->pgd = fff80004b8072000
[617635.588253]               \|/ ____ \|/
[617635.588253]               "@'/ .. \`@"
[617635.588253]               /_| \__/ |_\
[617635.588253]                  \__U_/
[617635.588258] cilk_for_ptr_it(243636): Oops [#1]
[617635.588270] CPU: 0 PID: 243636 Comm: cilk_for_ptr_it Tainted: G           O    4.12.0-rc3-00011-gf511c0b17b08-dirty #331
[617635.588276] task: fff80005047dc8e0 task.stack: fff80006c807c000
[617635.588284] TSTATE: 0000000011e01603 TPC: 00000000004a3c4c TNPC: 00000000004a3c50 Y: 00000000    Tainted: G           O   
[617635.588290] TPC: <idle_cpu+0x2c/0x60>
[617635.588296] g0: 0000000000000000 g1: 8000000000db6abf g2: 7fffffffffffffff g3: fff80004b82c9480
[617635.588302] g4: fff80005047dc8e0 g5: fff80040bc256000 g6: fff80006c807c000 g7: 0000000000000010
[617635.588307] o0: 0000000000000016 o1: 0000000000000100 o2: 0000000000000000 o3: 0000000000000000
[617635.588312] o4: 0000000000000000 o5: 0000000000000001 sp: fff80006c807f001 ret_pc: 00000000007df7b0
[617635.588328] RPC: <find_next_bit+0x10/0x20>
[617635.588334] l0: 0000000000ca7800 l1: 0000000000c609b8 l2: 000000000000000e l3: 00000000004aca78
[617635.588340] l4: fff8000170000078 l5: 0000000000000110 l6: fff8000170000020 l7: fff80001008d4000
[617635.588346] i0: 0000000000000000 i1: 0000000000000100 i2: 0000000000000017 i3: 0000000000000100
[617635.588353] i4: 0000000000000e84 i5: fff800409ed96ac0 i6: fff80006c807f0b1 i7: 00000000004ad114
[617635.588366] I7: <select_task_rq_fair+0x7f4/0x1160>
[617635.588369] Call Trace:
[617635.588378]  [00000000004ad114] select_task_rq_fair+0x7f4/0x1160
[617635.588396]  [00000000004a14ac] try_to_wake_up+0x34c/0x7e0
[617635.588403]  [00000000004a19d0] wake_up_q+0x50/0xa0
[617635.588419]  [0000000000511808] futex_wake+0x128/0x160
[617635.588427]  [0000000000513160] do_futex+0x100/0xa80
[617635.588434]  [0000000000513bec] SyS_futex+0x10c/0x180
[617635.588447]  [0000000000406234] linux_sparc_syscall+0x34/0x44
[617635.588461] Caller[00000000004ad114]: select_task_rq_fair+0x7f4/0x1160
[617635.588470] Caller[00000000004a14ac]: try_to_wake_up+0x34c/0x7e0
[617635.588478] Caller[00000000004a19d0]: wake_up_q+0x50/0xa0
[617635.588485] Caller[0000000000511808]: futex_wake+0x128/0x160
[617635.588492] Caller[0000000000513160]: do_futex+0x100/0xa80
[617635.588501] Caller[0000000000513bec]: SyS_futex+0x10c/0x180
[617635.588508] Caller[0000000000406234]: linux_sparc_syscall+0x34/0x44
[617635.588515] Caller[fff80001007cd5b0]: 0xfff80001007cd5b0
[617635.588518] Instruction DUMP:
[617635.588522]  821062c0 
[617635.588526]  b0102000 
[617635.588529]  82004002 
[617635.588534] <c6586970>
[617635.588537]  c4586978 
[617635.588540]  80a0c002 
[617635.588545]  12680008 
[617635.588548]  01000000 
[617635.588552]  c4006038 
[617635.588555] 
[617635.588561] BUG: sleeping function called from invalid context at ./include/linux/percpu-rwsem.h:33
[617635.588566] in_atomic(): 1, irqs_disabled(): 1, pid: 243636, name: cilk_for_ptr_it
[617635.588570] INFO: lockdep is turned off.
[617635.588575] irq event stamp: 0
[617635.588580] hardirqs last  enabled at (0): [<          (null)>]           (null)
[617635.588599] hardirqs last disabled at (0): [<00000000004689d0>] copy_process.isra.1+0x450/0x19e0
[617635.588608] softirqs last  enabled at (0): [<00000000004689d0>] copy_process.isra.1+0x450/0x19e0
[617635.588612] softirqs last disabled at (0): [<          (null)>]           (null)
[617635.588620] CPU: 0 PID: 243636 Comm: cilk_for_ptr_it Tainted: G      D    O    4.12.0-rc3-00011-gf511c0b17b08-dirty #331
[617635.588623] Call Trace:
[617635.588632]  [000000000049cf5c] ___might_sleep+0x21c/0x240
[617635.588640]  [000000000049cfe8] __might_sleep+0x68/0xa0
[617635.588651]  [0000000000480098] exit_signals+0x18/0x280
[617635.588658]  [00000000004716ec] do_exit+0x10c/0xcc0
[617635.588667]  [000000000042a298] die_if_kernel+0x298/0x320
[617635.588676]  [0000000000433f44] kernel_mna_trap_fault+0xe4/0x120
[617635.588682]  [00000000004341ac] kernel_unaligned_trap+0x20c/0x520
[617635.588689]  [000000000042b234] sun4v_do_mna+0x54/0xa0
[617635.588698]  [0000000000406d10] sun4v_mna+0x5c/0x6c
[617635.588704]  [00000000004a3c4c] idle_cpu+0x2c/0x60
[617635.588711]  [00000000004ad114] select_task_rq_fair+0x7f4/0x1160
[617635.588719]  [00000000004a14ac] try_to_wake_up+0x34c/0x7e0

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1656294

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Fri, 2 Jun 2017 11:17:18 +0200

> On Wed, May 31, 2017 at 05:10:08PM -0400, David Miller wrote:
>> A fix for this is in Linus's tree and was submitted to -stable last
>> night:
> 
> What remains to be fixed though is that the gcc-7 testsuite
> *reproducibly* kills the kernel on sparc64 when building with more than
> around 20 jobs:

Well, I already have a release gcc bug to fix so pretty much I have no
time to look into bugs in unreleased versions of gcc sorry.

[toc] | [prev] | [next] | [standalone]

#1656385

On 06/02/2017 04:22 PM, David Miller wrote:
>> What remains to be fixed though is that the gcc-7 testsuite
>> *reproducibly* kills the kernel on sparc64 when building with more than
>> around 20 jobs:
> 
> Well, I already have a release gcc bug to fix so pretty much I have no
> time to look into bugs in unreleased versions of gcc sorry.

Isn't a bug in the kernel if an application is able to crash to the point
that the machine has to be hard-rebooted?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1656406

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Fri, 2 Jun 2017 18:33:45 +0200

> On 06/02/2017 04:22 PM, David Miller wrote:
>>> What remains to be fixed though is that the gcc-7 testsuite
>>> *reproducibly* kills the kernel on sparc64 when building with more than
>>> around 20 jobs:
>> 
>> Well, I already have a release gcc bug to fix so pretty much I have no
>> time to look into bugs in unreleased versions of gcc sorry.
> 
> Isn't a bug in the kernel if an application is able to crash to the point
> that the machine has to be hard-rebooted?

It can be a bug in the compiler too and not necessarily the kernel's
fault which is what I think is happening in your case.

[toc] | [prev] | [next] | [standalone]

#1657069

On 06/02/2017 07:28 PM, David Miller wrote:
>> Isn't a bug in the kernel if an application is able to crash to the point
>> that the machine has to be hard-rebooted?
> 
> It can be a bug in the compiler too and not necessarily the kernel's
> fault which is what I think is happening in your case.

So, in your point of view it's perfectly fine if an application is able
to crash the whole kernel with just user privileges?

Shouldn't the kernel be able to cope with that?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1657082

Hi Adrian,
John Paul Adrian Glaubitz wrote,

> On 06/02/2017 07:28 PM, David Miller wrote:
> >> Isn't a bug in the kernel if an application is able to crash to the point
> >> that the machine has to be hard-rebooted?
> > 
> > It can be a bug in the compiler too and not necessarily the kernel's
> > fault which is what I think is happening in your case.
> 
> So, in your point of view it's perfectly fine if an application is able
> to crash the whole kernel with just user privileges?
> 
> Shouldn't the kernel be able to cope with that?

I think he means your kernel you are running might be miscompiled
with gcc 7.1.

What kernel version you are running? Which compiler you used to
generate the running kernel? If it is gcc 7.1, what is if you try to
reproduce the crash with the same kernel version compiled with gcc
6.3?
Wouldn't this show if it is a compiler or kernel bug?

best regards
 Waldemar

[toc] | [prev] | [next] | [standalone]

#1657089

Hi Waldemar!

On 06/04/2017 04:40 PM, Waldemar Brodkorb wrote:
>> So, in your point of view it's perfectly fine if an application is able
>> to crash the whole kernel with just user privileges?
>>
>> Shouldn't the kernel be able to cope with that?
> 
> I think he means your kernel you are running might be miscompiled
> with gcc 7.1.

The kernel wasn't compiled by 7.1. It was built with 6.3:

[    0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 4.38.8 2017/02/22 13:51'
[    0.000000] PROMLIB: Root node compatible: sun4v
[    0.000000] Linux version 4.12.0-rc1-sparc64-smp (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170510 (Debian 6.3.0-17) ) #1 SMP Debian
4.12~rc1-1~exp1~sparc64 (2017-05-17)

> What kernel version you are running?

This has been haunting us since around kernel 4.6 or so. It also
only shows when building with many parallel jobs.

> Which compiler you used to generate the running kernel?

6.3.0 20170510 from the gcc-6 branch.

> If it is gcc 7.1, what is if you try to
> reproduce the crash with the same kernel version compiled with gcc
> 6.3?

It's simply gcc-7's testsuite that's crashing the kernel since kernel
versions around 4.6. We haven't done any kernel compiles with gcc-7.1
yet since gcc-7.1 not yet the default compiler, we're just building the
package in Debian experimental.

> Wouldn't this show if it is a compiler or kernel bug?

Yes and I think the data suggests it's rather a kernel bug than a bug
in gcc.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1657161

From: Waldemar Brodkorb <wbx@openadk.org>
Date: Sun, 4 Jun 2017 16:40:45 +0200

> Hi Adrian,
> John Paul Adrian Glaubitz wrote,
> 
>> On 06/02/2017 07:28 PM, David Miller wrote:
>> >> Isn't a bug in the kernel if an application is able to crash to the point
>> >> that the machine has to be hard-rebooted?
>> > 
>> > It can be a bug in the compiler too and not necessarily the kernel's
>> > fault which is what I think is happening in your case.
>> 
>> So, in your point of view it's perfectly fine if an application is able
>> to crash the whole kernel with just user privileges?
>> 
>> Shouldn't the kernel be able to cope with that?
> 
> I think he means your kernel you are running might be miscompiled
> with gcc 7.1.

That's exactly what I am saying.

[toc] | [prev] | [next] | [standalone]

#1657162

On 06/04/2017 10:22 PM, David Miller wrote:
>> I think he means your kernel you are running might be miscompiled
>> with gcc 7.1.
> 
> That's exactly what I am saying.

[    0.000000] Linux version 4.12.0-rc1-sparc64-smp (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170510 (Debian 6.3.0-17) ) #1 SMP Debian
4.12~rc1-1~exp1~sparc64 (2017-05-17)

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1657160

On 06/04/2017 10:21 PM, David Miller wrote:
> It's the compiler.  It's not compiling the kernel properly.  What part
> of that do you not understand?  The kernel, if miscompiled itself,
> cannot do anything about it.

How do you know it's the compiler? This has not happened with earlier
versions of the kernel using the same compiler. Again, we're not
using gcc-7.1

> The kernel expects that the compiler is able to compile the kernel
> properly.  Period.

I'm not arguing that.

> I know this might in fact be news to you, but that is a pretty
> fundamental expectation.  And when the compiler has bugs, it will not
> compile the kernel properly and therefore the kernel won't work.

Again, how do you know it's the compiler?

> Therefore the compiler in that situation needs to be fixed, not the
> kernel.  And furthermore, you are dealing wiht an unreleased version
> of gcc which is stil under development, having lots of changes made,
> bugs fixed, etc.  It's a moving target.

The kernel was not compiled with gcc-7.1. I *never* said that. We're
not using Gentoo here, this is Debian. The kernel was compiled with
the current stable gcc-6 version.

> In my point of view if I have to choose between working on bugs
> showing up in the kernel with released versions of gcc, vs unreleased
> versions of gcc, due to time constraints.  I will always put effort
> into released versions of gcc.

I don't understand why you keep bringing this up. I *never* said the
kernel was built with gcc-7.1. It wasn't.

> Why can't you understand this fundamental issue of my having
> constraints like time?  If you don't like this, find some other
> person to fix your bug or even better, do it yourself you have
> access to all of the code just like I or anyone else does.

I don't understand why you're attacking me personally here when
I'm pointing out an important issue with the kernel on SPARC.

You're the person who is most knowledgeable with the code and
the bug seems pretty darn serious. Hence I was reporting it.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1657164

On 06/04/2017 10:34 PM, David Miller wrote:
> Please post your sparc64 system specs.

It's a SPARC-T5 running Debian inside an LDOM with 94 GiB RAM
and 128 active CPU threads.

I don't know the exact specs as the machine is owned by Anatoly
Pugachev. I'm CC'ing him so he can disclose the remaining specs.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1657166

On 06/04/2017 10:30 PM, David Miller wrote:
> All of my testing is being done with gcc-6.3 vanilla and current
> kernels, and in fact I'm doing parallel "make -j128" gcc and glibc
> testsuite runs and not hitting any problems at all.

Did you try to build and run the gcc-7 testsuite? Because we don't
see this with the gcc-6 testsuite.

The environment is a clean Debian unstable sparc64 chroot with glibc-2.24
and gcc-6.3.0.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#1657168

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Sun, 4 Jun 2017 22:33:21 +0200

> On 06/04/2017 10:30 PM, David Miller wrote:
>> All of my testing is being done with gcc-6.3 vanilla and current
>> kernels, and in fact I'm doing parallel "make -j128" gcc and glibc
>> testsuite runs and not hitting any problems at all.
> 
> Did you try to build and run the gcc-7 testsuite? Because we don't
> see this with the gcc-6 testsuite.
> 
> The environment is a clean Debian unstable sparc64 chroot with glibc-2.24
> and gcc-6.3.0.

I'm currently running the testsuite with gcc mainline.

Please post your sparc64 system specs.

[toc] | [prev] | [next] | [standalone]

#1657167

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Sun, 4 Jun 2017 22:26:50 +0200

> You're the person who is most knowledgeable with the code and
> the bug seems pretty darn serious. Hence I was reporting it.

Ok, please report this again with a simple reproducable test case
and I will try to reproduce it and work on it here.

All of my testing is being done with gcc-6.3 vanilla and current
kernels, and in fact I'm doing parallel "make -j128" gcc and glibc
testsuite runs and not hitting any problems at all.

So something is definitely different from your environment and mine.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web