From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753371AbcCGSa2 (ORCPT ); Mon, 7 Mar 2016 13:30:28 -0500 Received: from mail-io0-f177.google.com ([209.85.223.177]:35797 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753436AbcCGSaR (ORCPT ); Mon, 7 Mar 2016 13:30:17 -0500 MIME-Version: 1.0 In-Reply-To: References: <063D6719AE5E284EB5DD2968C1650D6D41116CA6@AcuExch.aculab.com> Date: Mon, 7 Mar 2016 10:30:16 -0800 X-Google-Sender-Auth: nWQ40yGf58YgUeN48Ll2RCf-Gvc Message-ID: Subject: Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning From: Linus Torvalds To: Alan Stern Cc: David Laight , "sedat.dilek@gmail.com" , 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, 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. Linus