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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 6 Feb 2011 13:03:13 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Minchan Kim <minchan.kim@...il.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [BUG] usb_set_device_state

On Sunday, February 06, 2011, Rafael J. Wysocki wrote:
> On Sunday, February 06, 2011, Alan Stern wrote:
> > On Sun, 6 Feb 2011, Rafael J. Wysocki wrote:
> > 
> > > On Saturday, February 05, 2011, Alan Stern wrote:
> > > > On Sun, 6 Feb 2011, Minchan Kim wrote:
> > > > 
> > > > > I got following message during booting mmotm-02-04.
> > ...
> > > > > It seems usb_set_device_state disable irq by spin_lock_irqsave.
> > > > > But it calls device_set_wakeup_capable which ends up calling sysfs_merge_group.
> > > > > It calls mutex_lock. :(
> > > > > 
> > > > > Is it already known BUG?
> > > > 
> > > > No, it was newly introduced by changes to the 
> > > > device_set_wakeup_capable() routine.  Rafael, this sort of problem may 
> > > > occur in other places too, since previously there was no requirement 
> > > > that device_set_wakeup_capable() be called in process context.
> > > 
> > > I'm aware of that, but it's only happend in a handful of network drivers so far.
> > > 
> > > I think this is a new case in -mm, though, isn't it?
> > 
> > I'm not sure.  The USB core does call device_set_wakeup_capable()  
> > while holding one or more spinlocks in usb_set_device_state(), and that
> > routine is called in several places.  You ought to be able to duplicate 
> > the error on your own system simply by plugging in a USB hub.
> 
> No, I'm not.  At least not with 2.6.37.
> 
> Also, I think the problem would have been reported before if it had been that
> easy to reproduce with the mainline kernel.

Or do I need to enable a specific CONFIG_ option to reproduce it?

Rafael
--
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