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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 23 May 2014 15:32:31 +0100
From:	Will Deacon <will.deacon@....com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"sarah.a.sharp@...ux.intel.com" <sarah.a.sharp@...ux.intel.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"khilman@...aro.org" <khilman@...aro.org>
Subject: Re: Runtime PM workqueue killing system performance with USB

On Thu, May 22, 2014 at 07:14:40PM +0100, Alan Stern wrote:
> On Thu, 22 May 2014, Will Deacon wrote:
> 
> > > Anyway, there are two possible ways of handling this.  One is to avoid 
> > > changing the error code to -EBUSY when the device in question is a root 
> > > hub.  Just let it go into a runtime-PM error state; it won't matter 
> > > since the controller doesn't support runtime PM anyway.  You can test 
> > > this by changing the "if (status != 0)" line in usb_runtime_suspend to
> > > 
> > > 	if (status != 0 && udev->parent)
> > 
> > I'd tried something like this already, but I prefer your patch below. Plus,
> > this hack results in a failure being logged to dmesg on the initial suspend
> > attempt.
> > 
> > > The other approach is to disable runtime PM for the root hub when the 
> > > host controller driver doesn't have a bus_suspend or bus_resume method.
> > > This seems like a cleaner approach; the patch below implements it.
> > 
> > Thanks for this! I can confirm that your patch below fixes the issue for me,
> > so:
> > 
> >   Reported-by: Will Deacon <will.deacon@....com>
> >   Tested-by: Will Deacon <will.deacon@....com>
> 
> You know, I think it might be best to make both changes.  Even though 
> runtime PM will be disabled by default, the user can always override 
> this setting.  If that happens, the suspend should fail with the proper 
> error code instead of going into a loop.
> 
> Do you mind if I add the change to usb_runtime_suspend() in the patch?

That sounds sensible -- if runtime PM is being forced on, then errors are
worth reporting.

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