From: Ioan-Adrian Ratiu <adi@adirat.com>
To: Josh Cartwright <joshc@ni.com>
Cc: Jiri Kosina <jikos@kernel.org>,
pinglinux@gmail.com, linux-usb@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hid: usbhid: hid-core: fix recursive deadlock
Date: Thu, 19 Nov 2015 08:47:43 +0200 [thread overview]
Message-ID: <20151119084743.08d11238@adipc> (raw)
In-Reply-To: <20151118235856.GA30351@jcartwri.amer.corp.natinst.com>
On Wed, 18 Nov 2015 17:58:56 -0600
Josh Cartwright <joshc@ni.com> wrote:
> On Wed, Nov 18, 2015 at 11:05:44PM +0200, Ioan-Adrian Ratiu wrote:
> > On Wed, 18 Nov 2015 21:37:42 +0100 (CET)
> > Jiri Kosina <jikos@kernel.org> wrote:
> >
> > > On Wed, 18 Nov 2015, Ioan-Adrian Ratiu wrote:
> > >
> > > > 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.
next prev parent reply other threads:[~2015-11-19 6:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 19:25 [PATCH] hid: usbhid: hid-core: fix recursive deadlock Ioan-Adrian Ratiu
2015-11-18 20:37 ` Jiri Kosina
2015-11-18 21:05 ` Ioan-Adrian Ratiu
2015-11-18 23:58 ` Josh Cartwright
2015-11-19 6:47 ` Ioan-Adrian Ratiu [this message]
2015-11-19 9:10 ` Jiri Kosina
2015-11-19 16:33 ` Ioan-Adrian Ratiu
2015-11-19 21:34 ` Jiri Kosina
2015-11-20 20:08 ` Ioan-Adrian Ratiu
2015-11-19 8:56 ` Jiri Kosina
2015-11-20 20:19 ` [PATCH v2] " Ioan-Adrian Ratiu
2015-11-29 10:29 ` Ioan-Adrian Ratiu
2016-01-21 1:28 ` Jason Gerecke
2016-01-21 9:36 ` Jiri Kosina
2015-12-01 16:36 ` Jiri Kosina
2015-12-02 0:00 ` Ping Cheng
2015-11-18 19:46 [PATCH] " Ioan-Adrian Ratiu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151119084743.08d11238@adipc \
--to=adi@adirat.com \
--cc=jikos@kernel.org \
--cc=joshc@ni.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pinglinux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).