linux-kernel - Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

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]

Message-ID: <20180217152459.GA22308@kroah.com>
Date:   Sat, 17 Feb 2018 16:24:59 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Brian Norris <briannorris@...omium.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Leif Liddy <leif.linux@...il.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Daniel Drake <drake@...lessm.com>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome
 suspend/resume fix with a "rewritten" version

On Sat, Feb 17, 2018 at 07:12:17AM -0800, Guenter Roeck wrote:
> On 02/17/2018 05:43 AM, Greg Kroah-Hartman wrote:
> > On Fri, Feb 16, 2018 at 10:52:20AM -0800, Guenter Roeck wrote:
> > > On Fri, Feb 16, 2018 at 10:10:44AM -0800, Brian Norris wrote:
> > > > On Fri, Feb 16, 2018 at 07:48:50AM +0100, Greg Kroah-Hartman wrote:
> > > > > On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote:
> > > > > > On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote:
> > > > > > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > > > > > 
> > > > > > Consider this an objection:
> > > > > > 
> > > > > > I'm currently arguing that this is unnecessarily regressing power
> > > > > > consumption here:
> > > > > > 
> > > > > > https://patchwork.kernel.org/patch/10149195/
> > > > > > 
> > > > > > I'll leave it up to you what to do with this, but if this ends up in
> > > > > > Chromium OS kernels, I'm likely to revert it there...
> > > > > 
> > > > > Is that patch in Linus's tree yet?  If so, I'll be glad to also apply it
> > > > > here.
> > > > 
> > > > The link is the original patch, where I'm (too late?) complaining about
> > > > its side effects. Hans and Marcel are discussing potential alternatives.
> > > > This stuff happens in -rc kernels. But you're already ready to push it
> > > > out to -stable users? I can try to push another few reverts into Linus's
> > > > tree if that really helps, or else you can wait on pushing these to
> > > > -stable until 4.16 settles down.
> > > 
> > > FWIW, here are the various commit SHAs.
> > > 
> > > Upstream:			61f5acea8737
> > > v4.15 (queued for v4.15.4):	e766a2d7f7c2
> > > v4.14 (queued for v4.14.20):	736385472dfa
> > > v4.9 (queued for v4.9.82):	1c6fc2167678
> > > v4.4 (queued for v4.4.116):	575538a5371d
> > > 
> > > I didn't check older stable kernels.
> > 
> > Thanks, but I've now released all of these with this patch committed, so
> > we are now "bug compatible" :)
> > 
> 
> FWIW, seems to me that trying to be "bug compatible" with -rc1 upstream
> kernels may not really be a good idea for stable releases.

It's a tough trade-off.  If I dropped this patch, the normal mode of
operation would be for it to get merged into device kernels and then
forgotten about.  Only if/when the user with the problem moves to a
newer release a long time later would the regression normally appear
again, and everyone would have to remember what happened and try to
piece it all together again as to what commit caused the issue.

By you adding the revert to your device kernel now, you have a record of
this being a problem, how upstream isn't fixing the issue, and when/if
you do move to a newer kernel, that bugfix will still be there in your
patch stack to forward port.

Yeah, you all are normally better than that, and I trust that you will
push to get this resolved, hopefully soon.  But for the most part, this
method works best overall for the majority of the cases like this as not
all bug reporters are persistent, and if not, the maintainer usually
forgets about it as no one is saying anything and they have other things
to work on.

Well, bluetooth is known to not have responsive maintainers, so who am I
kidding here, odds are it's only going to get fixed as Hans is
involved, despite the bluetooth maintainers :)

thanks,

greg k-h