From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752171AbcF0U1M (ORCPT <rfc822;w@1wt.eu>);
	Mon, 27 Jun 2016 16:27:12 -0400
Received: from mail-vk0-f65.google.com ([209.85.213.65]:34646 "EHLO
	mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751857AbcF0U1J (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 27 Jun 2016 16:27:09 -0400
MIME-Version: 1.0
Reply-To: sedat.dilek@gmail.com
In-Reply-To: <CA+55aFzGd6k3G3PbzmCTYCRsTi7Htw5cx53_4Jey34n=WmCWHQ@mail.gmail.com>
References: <063D6719AE5E284EB5DD2968C1650D6D41116CA6@AcuExch.aculab.com>
 <Pine.LNX.4.44L0.1603071303070.1611-100000@iolanthe.rowland.org>
 <CA+55aFxQdV1bPmfSMXmH9HRqhmP4g79Lp=XMYqNqZ+SxJtH=fA@mail.gmail.com>
 <CA+icZUU7y5ATSLV_0TGzi5m5deWADLmAMBkAT32FKGyUWNSJSA@mail.gmail.com> <CA+55aFzGd6k3G3PbzmCTYCRsTi7Htw5cx53_4Jey34n=WmCWHQ@mail.gmail.com>
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Mon, 27 Jun 2016 22:27:07 +0200
Message-ID: <CA+icZUXDdWmW12hdug=Pr3OMontf6XckrA9ZkP3=C6FE=R1yMA@mail.gmail.com>
Subject: Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
        David Laight <David.Laight@aculab.com>, Jiri Kosina <jikos@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>, Tejun Heo <tj@kernel.org>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Benjamin Tissoires <benjamin.tissoires@redhat.com>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>,
        Andy Lutomirski <luto@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        USB list <linux-usb@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek <sedat.dilek@gmail.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.
>

Thanks for the quick answer.

I just grepped for some "buzzwords" people gave me in this
email-thread and I was looking at (llvm.git HEAD - upcoming v3.9
release) and found these comments in [1]

[ lib/Target/X86/X86InstrInfo.cpp ]

void X86InstrInfo::copyPhysReg()
...
// PUSHF/POPF is also potentially incorrect because it affects other flags
// such as TF/IF/DF, which LLVM doesn't model.
...

- Sedat -

[1] https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X86/X86InstrInfo.cpp#L4516