[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzGd6k3G3PbzmCTYCRsTi7Htw5cx53_4Jey34n=WmCWHQ@mail.gmail.com>
Date: Mon, 27 Jun 2016 13:14:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Sedat Dilek <sedat.dilek@...il.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
David Laight <David.Laight@...lab.com>,
Jiri Kosina <jikos@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Tejun Heo <tj@...nel.org>,
Lai Jiangshan <jiangshanlai@...il.com>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning
On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
>
> $ objdump -S clang-eflag.o
>
> clang-eflag.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> 0000000000000000 <bar>:
> 0: 55 push %rbp
> 1: 48 89 e5 mov %rsp,%rbp
> 4: 53 push %rbx
> 5: 50 push %rax
> 6: e8 00 00 00 00 callq b <bar+0xb>
> b: ff 0d 00 00 00 00 decl 0x0(%rip) # 11 <bar+0x11>
> 11: 9c pushfq
> 12: 5b pop %rbx
> 13: e8 00 00 00 00 callq 18 <bar+0x18>
> 18: b8 01 00 00 00 mov $0x1,%eax
> 1d: 53 push %rbx
> 1e: 9d popfq
> 1f: 75 07 jne 28 <bar+0x28>
Yeah, the above is pure garbage.
> So, the issue is still alive.
>
> What do you mean by "for the kernel we at a minimum need a way to
> disable that code generation"?
> Can this be fixed in the Linux-kernel?
No. This will never be fixed in the kernel. It's a compiler bug.
The compiler generates shit code. It's absolutely atrociously bad even
if you ignore any kernel issues, because that kind of code just
performs badly (the compiler should have used "setcc" or something
similar to just set the comparison value, not save and restore eflags.
And quite frankly, any compiler writer that thinks it is good code is
not somebody I want touching a compiler that the kernel depends on
anyway.
But it is not just bad code for the kernel, it's actively buggy code,
since it corrupts the IF.
Until this gets fixed in LLVM, there's no way in hell that we will
ever have a kernel compiled with that piece of shit.
Really. If the LLVM developers cannot fix their crap code generation,
it's not worth touching that shit with a ten-foot pole.
I'd love to be able to compile the kernel with LLVM, but the fact that
the broken eflags code apparently _still_ hasn't been fixed makes me
just go "not worth it".
And if the LLVM developers don't see this as an obvious bug, it's even
less worth it - because that shows not just that the compiler is
broken, but that the developers involved with it are broken too.
Linus
Powered by blists - more mailing lists