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]
Date:	Mon, 7 Mar 2016 17:28:25 +0100
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Jiri Kosina <jikos@...nel.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, Mar 7, 2016 at 4:59 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern <stern@...land.harvard.edu> wrote:
>> On Sat, 5 Mar 2016, Sedat Dilek wrote:
>>
>>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern <stern@...land.harvard.edu> wrote:
>>> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
>>> >
>>> >> On 3/1/16, Alan Stern <stern@...land.harvard.edu> wrote:
>>> >> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
>>> >> >
>>> >> >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt <rostedt@...dmis.org>
>>> >> >> wrote:
>>> >> >> > On Sat, 3 Oct 2015 12:05:42 +0200
>>> >> >> > Sedat Dilek <sedat.dilek@...il.com> wrote:
>>> >> >> >
>>> >> >> >> So, at the beginning... dunno WTF is causing the problems - no
>>> >> >> >> workaround for CLANG.
>>> >> >> >
>>> >> >> > Probably need to compile with gcc and with clang and look at the binary
>>> >> >> > differences. Or at least what objdump shows.
>>> >> >> >
>>> >> >>
>>> >> >> [ Hope to address this issue to the correct people - CCed some people
>>> >> >> I taped on their nerves ]
>>> >> >>
>>> >> >> Not sure if I should open a new thread?
>>> >> >> Please, some clear statements on this.
>>> >> >> Thanks.
>>> >> >>
>>> >> >> The issue is still visible and alive.
>>> >
>>> > I think it would be worthwhile to doublecheck the time at which
>>> > interrupts get disabled.  Sedat, please try your plug/unplug the USB
>>> > mouse test with the patch below.
>>> >
>>> > Alan Stern
>>> >
>>> >
>>> >
>>> > Index: usb-4.4/drivers/hid/usbhid/hid-core.c
>>> > ===================================================================
>>> > --- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
>>> > +++ usb-4.4/drivers/hid/usbhid/hid-core.c
>>> > @@ -1393,8 +1393,11 @@ static void usbhid_disconnect(struct usb
>>> >
>>> >  static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
>>> >  {
>>> > +       if (raw_irqs_disabled())  pr_info("usbhid irqs disabled A\n");
>>> >         del_timer_sync(&usbhid->io_retry);
>>> > +       if (raw_irqs_disabled())  pr_info("usbhid irqs disabled B\n");
>>> >         cancel_work_sync(&usbhid->reset_work);
>>> > +       if (raw_irqs_disabled())  pr_info("usbhid irqs disabled C\n");
>>> >  }
>>> >
>>> >  static void hid_cease_io(struct usbhid_device *usbhid)
>>> >
>>>
>>> With your patch I get the dmesg attached.
>>
>>> [   22.234758] usbhid irqs disabled A
>>> [   22.234857] usbhid irqs disabled B
>>> [   22.234912] BUG: sleeping function called from invalid context atkernel/workqueue.c:2688
>>
>> That's a smoking gun.  It means everyone has been looking in the wrong
>> place.  Can you provide an objdump listing of usbhid_close()?  The
>> routine starts like this:
>>
>> void usbhid_close(struct hid_device *hid)
>> {
>>         struct usbhid_device *usbhid = hid->driver_data;
>>
>>         mutex_lock(&hid_open_mut);
>>
>>         /* protecting hid->open to make sure we don't restart
>>          * data acquistion due to a resumption we no longer
>>          * care about
>>          */
>>         spin_lock_irq(&usbhid->lock);
>>         if (!--hid->open) {
>>                 spin_unlock_irq(&usbhid->lock);
>>                 hid_cancel_delayed_stuff(usbhid);
>>
>> It appears that the spin_unlock_irq() call isn't working.
>>
>> For extra thoroughness, try putting one of those raw_irqs_disabled()
>> checks just before and one just after the spin_lock_irq() line above.
>> Maybe also before the mutex_lock() line.
>>
>> Alan Stern
>>
>
> Hmm, we are there where I was looking at...
>
> Please, read the reply of Jiri [1], we did some tweaking.
> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !
>

Shall I enable CONFIG_TRACE_IRQFLAGS (CONFIG_PROVE_LOCKING=n disables it)?

- Sedat -

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ