linux-kernel - Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 May 2015 16:52:24 +0200
From:	Oliver Neukum <oneukum@...e.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Takashi Iwai <tiwai@...e.de>, Laura Abbott <labbott@...hat.com>,
	Marcel Holtmann <marcel@...tmann.org>,
	Laura Abbott <labbott@...oraproject.org>,
	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	"bluez mailin list (linux-bluetooth@...r.kernel.org)" 
	<linux-bluetooth@...r.kernel.org>, netdev <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ming Lei <ming.lei@...onical.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	linux-usb@...r.kernel.org
Subject: Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

On Tue, 2015-05-19 at 10:26 -0400, Alan Stern wrote:
> On Tue, 19 May 2015, Takashi Iwai wrote:
> 
> > > > I am not convinced. Now we are hacking the Bluetooth core layer
> > > > (which has nothing to do with the drivers suspend/resume or
> > > > probe) to do something different so that we do not see this
> > > > warning.
> > > >
> > > > I can not do anything about the platform in question choosing a
> > > > unplug/replug for suspend/resume instead of having a proper USB
> > > > suspend and resume handling. That is pretty much out of our
> > > > control.
> 
> Actually one can do something about this.  I mean, one _can_ implement
> proper USB suspend and resume handling in the Bluetooth driver.  At
> this point the details aren't clear to me, but perhaps if the driver in
> question had a reset_resume callback then it might work better.

I doubt this would work. By losing power the BT controller is thrown
out of its cell. It looks to me like fundamentally BT needs to
fully reestablish the network from scratch after a loss of power.

> > > >  I would rather have the USB subsystem delay the probe()
> > > > callback if we tell it to.
> 
> This is possible.  I am not sure it would be the right thing to do,
> though.  What happens if the probe routine gets called early on during
> the boot-up procedure, before userspace is up and running?  The same
> thing should happen here.

Yes. Basically if you want firmware during probe the firmware
infrastructure has to be there. That is if you build such a module
statically the firmware must be included in the kernel image.

> > > >  Of just have request_firmware()
> > > > actually sleep until userspace is ready. Seriously, why is
> > > > request_firmware not just sleeping for us.
> 
> It won't work.  The request_firmware call is part of the probe 
> sequence, which in turn is part of the resume sequence.  Userspace 
> doesn't start running again until the resume sequence is finished.  If 
> request_firmware waited for userspace, it would hang.

I'd recommend the sledge hammer. Never free the firmware while the
hardware is connected or the system sleeping. If you must do this
there is a notifier chain.

	Regards
		Oliver



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