linux-kernel - Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1603071802330.3656@cbobk.fhfr.pm>
Date:	Mon, 7 Mar 2016 18:05:32 +0100 (CET)
From:	Jiri Kosina <jikos@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	Sedat Dilek <sedat.dilek@...il.com>,
	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, 7 Mar 2016, Alan Stern wrote:

> >      319:       9c                      pushfq
> >      31a:       41 5c                   pop    %r12
> >      31c:       48 89 df                mov    %rbx,%rdi
> >      31f:       e8 00 00 00 00          callq  324 <usbhid_close+0x44>
> >      324:       41 54                   push   %r12
> >      326:       9d                      popfq
> 
> spin_unlock_irq(&usbhid->lock); while attempting to preserve the Z
> flag.  The problem is that this code sequence will also preserve the
> Interrupt Flag!

You are right Alan, thanks a lot, for reason I could not understand I 
completely missed the pushf/popf last time I was looking at the generated 
assembly!

OK, a little bit of googling revealed related discussion on LLVM 
mailinglist:

	http://lists.llvm.org/pipermail/llvm-dev/2015-July/088780.html

Seems like it has been reported already, but noone dared to fix it yet.	

This basically makes LLVM unusable for compiling the kernel.

-- 
Jiri Kosina
SUSE Labs