[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200710230328.33915.arnd@arndb.de>
Date: Tue, 23 Oct 2007 03:28:31 +0200
From: Arnd Bergmann <arnd@...db.de>
To: gregkh@...e.de
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>, matthew@....cx,
ralf@...ux-mips.org, adobriyan@...il.com, viro@....linux.org.uk,
viro@...iv.linux.org.uk, LKML <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-usb-devel@...ts.sourceforge.net
Subject: USB HCD: avoid duplicate local_irq_disable()
usb_hcd_flush_endpoint() has a retry loop that starts with a spin_lock_irq(),
but only gives up the spinlock, not the irq_disable before jumping to the
rescan label.
Split the spin_lock_irq into the retryable part and the local_irq_disable()
that is only done once as a micro-optimization and slight cleanup.
Signed-off-by: Arnd Bergmann <arnd@...db.de>
---
On Tuesday 23 October 2007, I wrote:
> I tried the trivial annotation below and (with lockdep enabled) got a few
> warnings at boot time, but only one that I could still find in the log
> buffer:
One more such example that was not found by lockdep. I guess this counts
as a false positive, as it is clearly harmless, but working around
it is a small optimization for the case where local_irq_disable()
is a hypervisor call.
Should we try to fix this class of (non-)problem in other places?
Will this patch cause a different warning with lockdep since now we
are pairing spin_lock() with spin_unlock_irq()?
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1312,8 +1312,9 @@ void usb_hcd_flush_endpoint(struct usb_device *udev,
hcd = bus_to_hcd(udev->bus);
/* No more submits can occur */
+ local_irq_disable();
rescan:
- spin_lock_irq(&hcd_urb_list_lock);
+ spin_lock(&hcd_urb_list_lock);
list_for_each_entry (urb, &ep->urb_list, urb_list) {
int is_in;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists