From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999AbcF0UDt (ORCPT ); Mon, 27 Jun 2016 16:03:49 -0400 Received: from mail-vk0-f43.google.com ([209.85.213.43]:33116 "EHLO mail-vk0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751639AbcF0UDr (ORCPT ); Mon, 27 Jun 2016 16:03:47 -0400 MIME-Version: 1.0 Reply-To: sedat.dilek@gmail.com In-Reply-To: References: <063D6719AE5E284EB5DD2968C1650D6D41116CA6@AcuExch.aculab.com> From: Sedat Dilek Date: Mon, 27 Jun 2016 22:03:45 +0200 Message-ID: Subject: Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning To: Linus Torvalds Cc: Alan Stern , David Laight , Jiri Kosina , Steven Rostedt , Tejun Heo , Lai Jiangshan , Benjamin Tissoires , Paul McKenney , Andy Lutomirski , LKML , USB list , Greg Kroah-Hartman , Peter Zijlstra , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 27, 2016 at 9:50 PM, Sedat Dilek wrote: > On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds > wrote: >> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern 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. Just for the sake of completeness: I use the latest Linux v4.4.y LTS for testing (here: v4.4.14) with a custom llvmlinux-amd64 patchset (on demand I can send it to you). ( With CONFIG_TRACING_SUPPORT=n and CONFIG_PARAVIRT=n ) - Sedat -