lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 14 Jan 2015 15:06:39 -0500 (EST) From: Alan Stern <stern@...land.harvard.edu> To: Felipe Balbi <balbi@...com> cc: Robert Baldyga <r.baldyga@...sung.com>, <paulz@...opsys.com>, <gregkh@...uxfoundation.org>, <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <dinguyen@...nsource.altera.com>, <yousaf.kaukab@...el.com>, <m.szyprowski@...sung.com> Subject: Re: [PATCH v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock On Wed, 14 Jan 2015, Felipe Balbi wrote: > On Wed, Jan 14, 2015 at 07:45:31AM +0100, Robert Baldyga wrote: > > This patch fixes bug described here: > > https://lkml.org/lkml/2014/12/22/185 > > > > Signed-off-by: Robert Baldyga <r.baldyga@...sung.com> > > --- > > > > Changelog: > > > > v2: > > - fixed comment from Paul Zimmerman > > > > v1: https://lkml.org/lkml/2015/1/13/186 > > > > drivers/usb/dwc2/core_intr.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c > > index ad43c5b..02e3e2d 100644 > > --- a/drivers/usb/dwc2/core_intr.c > > +++ b/drivers/usb/dwc2/core_intr.c > > @@ -476,13 +476,13 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev) > > u32 gintsts; > > irqreturn_t retval = IRQ_NONE; > > > > + spin_lock(&hsotg->lock); > > + > > if (!dwc2_is_controller_alive(hsotg)) { > > This is really, really odd. Register accesses are atomic, so the lock > isn't really doing anything. Besides, you're calling > dwc2_is_controller_alive() from within the IRQ handler, so IRQs are > already disabled. Spinlocks sometimes do more than you think. For instance, here the lock prevents the register access from happening while some other CPU is holding the lock. If a silicon quirk causes the register access to interfere with other activities, this could be important. Alan Stern -- 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