public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Bin Liu <b-liu@ti.com>
To: Felipe Balbi <balbi@kernel.org>
Cc: <linux-usb@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH v2] usb: gadget: fix spinlock dead lock in gadgetfs
Date: Thu, 26 May 2016 11:36:22 -0500	[thread overview]
Message-ID: <20160526163622.GB26723@uda0271908> (raw)
In-Reply-To: <87mvnclr97.fsf@linux.intel.com>

Hi,

On Thu, May 26, 2016 at 07:26:44PM +0300, Felipe Balbi wrote:
> 
> >> Bin Liu <b-liu@ti.com> writes:
> >> > On Wed, May 25, 2016 at 02:18:34PM -0500, Bin Liu wrote:
> >> >> [   40.467381] =============================================
> >> >> [   40.473013] [ INFO: possible recursive locking detected ]
> >> >> [   40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted
> >> >> [   40.483466] ---------------------------------------------
> >> >> [   40.489098] usb/733 is trying to acquire lock:
> >> >> [   40.493734]  (&(&dev->lock)->rlock){-.....}, at: [<bf129288>] ep0_complete+0x18/0xdc [gadgetfs]
> >> >> [   40.502882]
> >> >> [   40.502882] but task is already holding lock:
> >> >> [   40.508967]  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
> >> >> [   40.517811]
> >> >> [   40.517811] other info that might help us debug this:
> >> >> [   40.524623]  Possible unsafe locking scenario:
> >> >> [   40.524623]
> >> >> [   40.530798]        CPU0
> >> >> [   40.533346]        ----
> >> >> [   40.535894]   lock(&(&dev->lock)->rlock);
> >> >> [   40.540088]   lock(&(&dev->lock)->rlock);
> >> >> [   40.544284]
> >> >> [   40.544284]  *** DEADLOCK ***
> >> >> [   40.544284]
> >> >> [   40.550461]  May be due to missing lock nesting notation
> >> >> [   40.550461]
> >> >> [   40.557544] 2 locks held by usb/733:
> >> >> [   40.561271]  #0:  (&f->f_pos_lock){+.+.+.}, at: [<c02a6114>] __fdget_pos+0x40/0x48
> >> >> [   40.569219]  #1:  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
> >> >> [   40.578523]
> >> >> [   40.578523] stack backtrace:
> >> >> [   40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37
> >> >> [   40.590246] Hardware name: Generic AM33XX (Flattened Device Tree)
> >> >> [   40.596625] [<c010ffbc>] (unwind_backtrace) from [<c010c1bc>] (show_stack+0x10/0x14)
> >> >> [   40.604718] [<c010c1bc>] (show_stack) from [<c04207fc>] (dump_stack+0xb0/0xe4)
> >> >> [   40.612267] [<c04207fc>] (dump_stack) from [<c01886ec>] (__lock_acquire+0xf68/0x1994)
> >> >> [   40.620440] [<c01886ec>] (__lock_acquire) from [<c0189528>] (lock_acquire+0xd8/0x238)
> >> >> [   40.628621] [<c0189528>] (lock_acquire) from [<c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c)
> >> >> [   40.637440] [<c06ad6b4>] (_raw_spin_lock_irqsave) from [<bf129288>] (ep0_complete+0x18/0xdc [gadgetfs])
> >> >> [   40.647339] [<bf129288>] (ep0_complete [gadgetfs]) from [<bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc])
> >> >> [   40.657842] [<bf10a728>] (musb_g_giveback [musb_hdrc]) from [<bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc])
> >> >> [   40.668772] [<bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs])
> >> >> [   40.678963] [<bf12a944>] (ep0_read [gadgetfs]) from [<c0284470>] (__vfs_read+0x20/0x110)
> >> >> [   40.687414] [<c0284470>] (__vfs_read) from [<c0285324>] (vfs_read+0x88/0x114)
> >> >> [   40.694864] [<c0285324>] (vfs_read) from [<c0286150>] (SyS_read+0x44/0x9c)
> >> >> [   40.702051] [<c0286150>] (SyS_read) from [<c0107820>] (ret_fast_syscall+0x0/0x1c)
> >> >> 
> >> >> Cc: <stable@vger.kernel.org> # v3.16+
> >> >> Signed-off-by: Bin Liu <b-liu@ti.com>
> >> >> ---
> >> >> v2:
> >> >>   - lock protects setup_req(), only unlock for usb_ep_queue()
> >> >>   - use GFP_KERNEL in usb_ep_queue()
> >> >>   - fix the same in two places in gadgetfs_setup() too
> >> >
> >> > Never mind. Sent the patch too soon. It gives the following problem.
> >> >
> >> > [  179.810367] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2724
> >> > _raw_spin_unlock_irq+0x24/0x2c
> >> > [  179.819719] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> >> 
> >> thanks for letting us know. I'm dropping this from my queue. Please
> >> resend final patch once you have it ;-)
> >
> > It turned out to be a very easy fix ;)
> >
> > I have v3 ready, but checkpatch.pl complains the followings. I don't
> > think this patch should fix them, since the whole driver is coded like
> > that. Any comments?
> 
> Let's fix it with a follow-up patch. Can you do that one too, btw? I can
> do it, if you don't wanna deal with that; but I'm also open to receiving
> free patches heh

I'd like to do it, but I have a pile of other suff to do. (I still
remember I owe you a g-zero test with dwc3...)

Regards,
-Bin.



  reply	other threads:[~2016-05-26 16:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-25 18:19 [PATCH] usb: gadget: fix spinlock dead lock in gadgetfs Bin Liu
2016-05-25 18:51 ` Alan Stern
2016-05-25 19:18   ` [PATCH v2] " Bin Liu
2016-05-25 19:24     ` Bin Liu
2016-05-26  6:27       ` Felipe Balbi
2016-05-26 15:38         ` Bin Liu
2016-05-26 16:26           ` Felipe Balbi
2016-05-26 16:36             ` Bin Liu [this message]
2016-05-26 16:43               ` [PATCH v3] " Bin Liu

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=20160526163622.GB26723@uda0271908 \
    --to=b-liu@ti.com \
    --cc=balbi@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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