mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Eugene_Bordenkircher@selinc.com
Cc: linux-kernel@vger.kernel.org,
	David Brownell <david-b@pacbell.net>,
	linux-usb@vger.kernel.org, Li Yang <leoli@freescale.com>
Subject: Re: BUG/OOPS: Double Lock in fsl_usb2_udc.c
Date: Thu, 29 May 2008 01:45:35 -0700	[thread overview]
Message-ID: <20080529014535.6065fa39.akpm@linux-foundation.org> (raw)
In-Reply-To: <OF581BDA23.991E51FC-ON88257457.007166AD-88257457.007B3064@selinc.com>

On Wed, 28 May 2008 15:25:31 -0700 Eugene_Bordenkircher@selinc.com wrote:

> Hello All, 
> 
> I have recently found an instance in the drivers/usb/gadget/fsl_usb2_udc.c 
> file that causes the udc->lock spinlock to be taken twice.  The problem 
> arises when you disconnect from the DR port and then reconnect.  The 
> interrupt routine for the driver receives a 'reset' event which takes the 
> lock and calls reset_queues() which in turn calls 
> udc->driver->disconnect().  Eventually, that disconnect() call comes back 
> up to the fsl_usb2_udc driver and calls fsl_ep_disable() which attempts to 
> take the udc->lock again.  Unfortunately the lock was not released before 
> the call to disconnect(), therefore the double lock is taken. 
> 
> Looking through other drivers, I have seen them releasing the lock 
> immediately before calling disconnect(), however, without being an expert 
> with this driver, I'm not entirely sure that is the best option here. 
> 
> I have seen the behavior directly on a 2.6.23.9-rt13 kernel, but have 
> perused the latest source and the same problem appears to be there. 
> Attached below is the generated BUG trace for the 2.6.23.9-rt13 kernel. 
> 
> Please CC me directly if possible for immediate responses.  Otherwise I 
> will have to wait for the archives to post to read responses. 
> 
> Eugene T. Bordenkircher 
> 
> ---Begin BUG: 
> 
> kernel BUG at kernel/rtmutex.c:683! 
> stopped custom tracer. 
> Oops: Exception in kernel mode, sig: 5 [#1] 
> PREEMPT MPC834x ITX 
> NIP: c021629c LR: c0216270 CTR: 00000000 
> REGS: df761d70 TRAP: 0700   Not tainted  (2.6.23.9-rt13) 
> MSR: 00021032 <ME,IR,DR>  CR: 28000022  XER: 00000000 
> TASK = df632080[241] 'IRQ-38' THREAD: df760000 
> GPR00: 00000001 df761e20 df632080 00000000 11111111 00000000 df761e6c 
> 00000000 
> GPR08: df761e48 00000000 df761e50 00000000 80000000 ede5cdde 1fffd000 
> 00800000 
> GPR16: ffffffff 00000000 007fff00 00000040 00000000 007ffeb0 00000000 
> 1fff8b08 
> GPR24: 00000000 00000026 00000000 df79a320 c026b2e8 c02240bc 00009032 
> df79a320 
> NIP [c021629c] rt_spin_lock_slowlock+0x9c/0x200 
> LR [c0216270] rt_spin_lock_slowlock+0x70/0x200 
> Call Trace: 
> [df761e20] [c0216270] rt_spin_lock_slowlock+0x70/0x200 (unreliable) 
> [df761e90] [c0182828] fsl_ep_disable+0xcc/0x154 
> [df761eb0] [c0184d30] eth_reset_config+0x88/0x1d0 
> [df761ed0] [c0184ec0] eth_disconnect+0x48/0x64 
> [df761ef0] [c01831a4] reset_queues+0x60/0x78 
> [df761f00] [c0183b74] fsl_udc_irq+0x9b8/0xa58 
> [df761f50] [c003ef30] handle_IRQ_event+0x64/0x100 
> [df761f80] [c003f758] thread_simple_irq+0x6c/0xc8 
> [df761fa0] [c003f888] do_irqd+0xd4/0x2e4 
> [df761fd0] [c0032284] kthread+0x50/0x8c 
> [df761ff0] [c000f9b4] kernel_thread+0x44/0x60 
> Instruction dump: 
> 4be25fb9 2f830000 41be0014 7fe3fb78 7fc4f378 48000f69 48000168 801f0024 
> 5400003a 7c001278 21600000 7c0b0114 <0f000000> 38000004 90010008 80010008 
> note: IRQ-38[241] exited with preempt_count 1 
> BUG: sleeping function called from invalid context IRQ-38(241) at 
> kernel/rtmutex.c:637 
> in_atomic():1 [00000001], irqs_disabled():0 
> Call Trace: 
> [df761c20] [c0008674] show_stack+0x54/0x174 (unreliable) 
> [df761c50] [c0014e74] __might_sleep+0xe0/0xf4 
> [df761c60] [c02169f8] __lock_text_start+0x30/0x48 
> [df761c70] [c001e928] do_exit+0x1f8/0x7bc 
> [df761ca0] [c000d0bc] die+0x198/0x1b0 
> [df761cc0] [c000d26c] _exception+0x38/0xf8 
> [df761d60] [c000f1bc] ret_from_except_full+0x0/0x4c 
> --- Exception: 700 at rt_spin_lock_slowlock+0x9c/0x200 
>    LR = rt_spin_lock_slowlock+0x70/0x200 
> [df761e90] [c0182828] fsl_ep_disable+0xcc/0x154 
> [df761eb0] [c0184d30] eth_reset_config+0x88/0x1d0 
> [df761ed0] [c0184ec0] eth_disconnect+0x48/0x64 
> [df761ef0] [c01831a4] reset_queues+0x60/0x78 
> [df761f00] [c0183b74] fsl_udc_irq+0x9b8/0xa58 
> [df761f50] [c003ef30] handle_IRQ_event+0x64/0x100 
> [df761f80] [c003f758] thread_simple_irq+0x6c/0xc8 
> [df761fa0] [c003f888] do_irqd+0xd4/0x2e4 
> [df761fd0] [c0032284] kthread+0x50/0x8c 
> [df761ff0] [c000f9b4] kernel_thread+0x44/0x60 
> 

Thanks, useful.

Let's cc some folks.

  reply	other threads:[~2008-05-29  8:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-28 22:25 Eugene_Bordenkircher
2008-05-29  8:45 ` Andrew Morton [this message]
2008-05-29  9:23   ` David Brownell
2008-05-29 10:48     ` Li Yang

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=20080529014535.6065fa39.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Eugene_Bordenkircher@selinc.com \
    --cc=david-b@pacbell.net \
    --cc=leoli@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@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

all inboxes | Powered by JetHome®