Re: [PATCH] hid: usbhid: hid-core: fix recursive deadlock

On Wed, 18 Nov 2015 17:58:56 -0600
Josh Cartwright [off-list ref] wrote:

On Wed, Nov 18, 2015 at 11:05:44PM +0200, Ioan-Adrian Ratiu wrote:

quoted

On Wed, 18 Nov 2015 21:37:42 +0100 (CET)
Jiri Kosina [off-list ref] wrote:
  

quoted

On Wed, 18 Nov 2015, Ioan-Adrian Ratiu wrote:
  

quoted

The critical section protected by usbhid->lock in hid_ctrl() is too
big and in rare cases causes a recursive deadlock because of its call
to hid_input_report().

This deadlock reproduces on newer wacom tablets like 056a:033c because
the wacom driver in its irq handler ends up calling hid_hw_request()
from wacom_intuos_schedule_prox_event() in wacom_wac.c. What this means
is that it submits a report to reschedule a proximity read through a
sync ctrl call which grabs the lock in hid_ctrl(struct urb *urb)
before calling hid_input_report(). When the irq kicks in on the same
cpu, it also tries to grab the lock resulting in a recursive deadlock.

The proper fix is to shrink the critical section in hid_ctrl() to
protect only the instructions which modify usbhid, thus move the lock
after the hid_input_report() call and the deadlock dissapears.    

I think the proper fix actually is to spin_lock_irqsave() in hid_ctrl(), 
isn't it?
  

That was my first attempt, yes, but the deadlock still happens with
interrupts disabled. It is very weird, I know.  

I think your best course of action is to figure out why this is the
case, instead of continuing with trying to solve the symptoms.  Do you
have actual callstacks showing the cases where you hit?  That might be
useful to share (your lockdep picture cuts out the callstacks).

Also, have you tried without the PREEMPT_RT patch in the picture at all?

  Josh

Yes, of course I tried it without PREEMPT_RT_FULL :) This happens on vanilla
mainline kernels (only after 4.4-rc1 which introduced support for this kind of
tablets).

I also backported all the wacom patches to 4.1 non-RT and the same deadlock
happens.

I've sent another email with some lockdep traces and printk's on a running
vanilla linux-next, maybe it didn't get through, here are the links again:

First part of lockdep report:
http://imgur.com/clLsCWe

Second part:
http://imgur.com/Wa2PzRl

Here are some printk's of mine while reproducing + debugging the issue:
http://imgur.com/SETOHT7

I'll continue to research this more in depth, but progress is slow because I
don't have much time, I'm doing this in my spare time because it's my
girlfriend's tablet.