From: Sedat Dilek <sedat.dilek@gmail.com>
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>
Subject: Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning
Date: Mon, 27 Jun 2016 21:50:21 +0200 [thread overview]
Message-ID: <CA+icZUU7y5ATSLV_0TGzi5m5deWADLmAMBkAT32FKGyUWNSJSA@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFxQdV1bPmfSMXmH9HRqhmP4g79Lp=XMYqNqZ+SxJtH=fA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]
On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>
>> Of course, there are other ways to save a single flag value (such as
>> setz). It's up to the compiler developers to decide what they think is
>> best.
>
> Using 'setcc' to save eflags somewhere is definitely the right thing to do.
>
> Using pushf/popf in generated code is completely insane (unless done
> very localized in a controlled area).
>
> It is, in fact, insane and wrong even in user space, since eflags does
> contain bits that user space itself might be modifying.
>
> In fact, even IF may be modified with iopl 3 (thing old X server
> setups), but ignoring that flag entirely, you have AC that acts in
> very similar ways (system-wide alignment control) that user space
> might be using to make sure it doesn't have unaligned accesses.
>
> It's rare, yes. But still - this isn't really limited to just the kernel.
>
> But perhaps more importantly, I suspect using pushf/popf isn't just
> semantically the wrong thing to do, it's just plain stupid. It's
> likely slower than the obvious 'setcc' model. Agner Fog's table shows
> it "popf" as being 25-30 uops on several microarchitectures. Looks
> like it's often microcode.
>
> Now, pushf/popf may well be fairly cheap on *some* uarchitectures, but
> it really sounds like a bad idea to use it when not absolutely
> required. And that is completely independent of the fact that is
> screws up the IF bit.
>
> But yeah, for the kernel we at a minimum need a way to disable that
> code generation, even if the clang guys might have some insane reason
> to keep it for other cases.
>
I am testing my new llvm-toolchain v3.8.1 and a pending x86/hweight
fix [1] encouraged me to look at this again.
In [2] I found a simple test program from Michael Hordijk.
( See thread "[LLVMdev] optimizer clobber EFLAGS". )
This is what I see...
$ 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>
21: e8 00 00 00 00 callq 26 <bar+0x26>
26: 31 c0 xor %eax,%eax
28: 48 83 c4 08 add $0x8,%rsp
2c: 5b pop %rbx
2d: 5d pop %rbp
2e: c3 retq
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?
I asked parallelly the people involved in [2] if there are any news on that.
- Sedat -
[1] http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=f5967101e9de12addcda4510dfbac66d7c5779c3
[2] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088766.html
[-- Attachment #2: clang-eflag.c --]
[-- Type: text/x-csrc, Size: 952 bytes --]
// Using Clang/LLVM 3.6.0 we are observing a case where the optimizations
// are clobbering EFLAGS on x86_64. This is inconvenient when the status of
// bit 9 (IF), which controls interrupts, changes.
//
// Here's a simple test program. Assume that the external function foo()
// modifies the IF bit in EFLAGS.
//
// And it's compiled using the following command line:
//
// $ clang -O2 -c -o clang-eflag.o clang-eflag.c
//
// Check objdump output using the following command line:
//
// $ objdump -S clang-eflag.o
//
// For more details see "[LLVMdev] optimizer clobber EFLAGS"
// <http://lists.llvm.org/pipermail/llvm-dev/2015-July/088766.html>
#include <stdlib.h>
#include <stdbool.h>
void foo(void);
int a;
int bar(void)
{
foo();
bool const zero = a -= 1;
asm volatile ("" : : : "cc");
foo();
if (zero) {
return EXIT_FAILURE;
}
foo();
return EXIT_SUCCESS;
}
[-- Attachment #3: clang-eflag.o --]
[-- Type: application/x-object, Size: 1128 bytes --]
next prev parent reply other threads:[~2016-06-27 19:50 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 15:59 [PATCH] usbhid: Fix lockdep unannotated irqs-off warning Sedat Dilek
2016-03-07 16:28 ` Sedat Dilek
2016-03-07 16:41 ` Alan Stern
2016-03-07 17:03 ` Steven Rostedt
2016-03-07 17:05 ` Jiri Kosina
2016-03-07 17:15 ` Sedat Dilek
2016-03-07 17:27 ` David Laight
2016-03-07 18:07 ` Alan Stern
2016-03-07 18:30 ` Linus Torvalds
2016-06-27 19:50 ` Sedat Dilek [this message]
2016-06-27 20:03 ` Sedat Dilek
2016-06-27 20:14 ` Linus Torvalds
2016-06-27 20:27 ` Sedat Dilek
2016-06-27 20:36 ` Linus Torvalds
2016-03-07 17:11 ` Steven Rostedt
2016-03-07 17:18 ` Sedat Dilek
2016-03-07 17:24 ` Jiri Kosina
2016-03-07 17:30 ` Steven Rostedt
2016-03-07 18:04 ` Andy Lutomirski
2016-03-07 19:10 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2015-09-28 8:10 Sedat Dilek
2015-09-28 11:33 ` Jiri Kosina
2015-09-29 8:40 ` Sedat Dilek
2015-09-29 9:27 ` Jiri Kosina
2015-09-29 18:54 ` Sedat Dilek
2015-09-29 19:08 ` Steven Rostedt
2015-09-29 19:32 ` Sedat Dilek
[not found] ` <CA+icZUWH2vR_vpYu4hCS578U3ssmoiF0pLYUfM-Xo-57e8uN=g@mail.gmail.com>
2015-09-30 6:41 ` Sedat Dilek
2015-09-30 8:50 ` Steven Rostedt
2015-09-30 7:35 ` Jiri Kosina
2015-09-30 8:56 ` Steven Rostedt
2015-09-30 9:46 ` Sedat Dilek
2015-09-30 10:13 ` Steven Rostedt
2015-09-30 10:39 ` Sedat Dilek
[not found] ` <CA+icZUXSzScTmMgLZwPQq9RMH9cUsD5_iDxKTVuG0rrGqH-8Cw@mail.gmail.com>
2015-10-01 2:01 ` Steven Rostedt
2015-10-01 5:34 ` Sedat Dilek
2015-10-01 6:05 ` Sedat Dilek
[not found] ` <CA+icZUUyaHqHP2v52juhGhoTNS9xX7LT2YxkOppLz6f9Z+FBEA@mail.gmail.com>
[not found] ` <CA+icZUWagGMVNs5gBPRBhYO0LsY2A1hK3KSLabp9ZpDVOTmtig@mail.gmail.com>
2015-10-13 0:57 ` Steven Rostedt
2016-03-01 10:05 ` Sedat Dilek
2016-03-01 15:07 ` Steven Rostedt
2016-03-01 15:17 ` Peter Zijlstra
2016-03-02 15:00 ` Sedat Dilek
2016-03-02 15:17 ` Peter Zijlstra
2016-03-02 15:34 ` Sedat Dilek
2016-03-02 15:53 ` Sedat Dilek
2016-03-02 15:56 ` Steven Rostedt
2016-03-02 16:08 ` Sedat Dilek
2016-03-02 16:11 ` Sedat Dilek
2016-03-02 16:21 ` Sedat Dilek
2016-03-02 16:24 ` Peter Zijlstra
2016-03-02 16:35 ` Steven Rostedt
2016-03-02 16:42 ` Peter Zijlstra
2016-03-02 16:42 ` Sedat Dilek
2016-03-02 16:52 ` Sedat Dilek
2016-03-01 15:59 ` Alan Stern
2016-03-02 6:25 ` Sedat Dilek
2016-03-04 16:04 ` Alan Stern
2016-03-05 22:30 ` Sedat Dilek
2016-03-06 8:51 ` Sedat Dilek
2016-03-06 17:23 ` Alan Stern
2016-03-02 6:36 ` Sedat Dilek
2016-03-02 8:34 ` Sedat Dilek
2016-03-02 8:37 ` Jiri Kosina
2016-03-02 9:11 ` Sedat Dilek
[not found] ` <CA+icZUX3tJvRor6CbOZFBecTAUZzyWzjLzJSEdb3c12yKRAT3g@mail.gmail.com>
2015-09-29 13:13 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+icZUU7y5ATSLV_0TGzi5m5deWADLmAMBkAT32FKGyUWNSJSA@mail.gmail.com \
--to=sedat.dilek@gmail.com \
--cc=David.Laight@aculab.com \
--cc=benjamin.tissoires@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jiangshanlai@gmail.com \
--cc=jikos@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.