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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 4 Nov 2010 11:03:52 -0400
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	dsterba@...e.cz, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, Andiry Xu <andiry.xu@....com>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [PATCH] USB: xhci: Use GFP_ATOMIC under spin_lock

On Wed, Nov 03, 2010 at 09:19:03AM +0100, Jiri Slaby wrote:
> On 11/02/2010 11:47 PM, David Sterba wrote:
> > coccinelle check scripts/coccinelle/locks/call_kern.cocci found that
> > in drivers/usb/host/xhci.c an allocation with GFP_KERNEL is done
> > with locks held:
> > 
> > xhci_resume
> >   spin_lock_irq(xhci->lock)
> >     xhci_setup_msix
> >       kmalloc(GFP_KERNEL)
> > 
> > Change it to GFP_ATOMIC.
> 
> Hi, I already reported that [1] and this is not enough. There are other
> sleepy calls like request_irq inside...
> 
> [1] http://lkml.org/lkml/2010/10/23/17

Andiry is looking into this.  Andiry, perhaps you don't need to take the
xHCI spinlock in xhci_resume()?  If that function is being called
because the PCI device is being resumed, you know nothing else is going
to touch the xHCI host controller.  (Except maybe the BIOS, but it isn't
going to respect xhci->lock at all.)  The USB core certainly won't touch
the host controller until it's resumed.  Maybe we could get an interrupt
with a port status change, but I think it's unlikely...

Alan, can you think of any reason the xHCI driver would need to grab its
host controller spinlock on PCI resume?

Sarah Sharp
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ