linux-kernel - Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

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]

Message-ID: <CA+ASDXNABgtZCj7SF=-LvBZGwWB0uo4BiWGTzpmhEZcQUkZPRA@mail.gmail.com>
Date:   Thu, 21 Dec 2017 09:20:51 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Sukumar Ghorai <sukumar.ghorai@...el.com>,
        Amit K Bag <amit.k.bag@...el.com>,
        Oliver Neukum <oneukum@...e.com>,
        Marcel Holtmann <marcel@...tmann.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Todd Broch <tbroch@...omium.org>,
        Rajat Jain <rajatja@...omium.org>,
        Miao Chou <mcchou@...omium.org>, sadashiva.rao.pv@...el.com,
        Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the
 usb-wakeup feature

On Thu, Dec 21, 2017 at 12:30 AM, gregkh@...uxfoundation.org
<gregkh@...uxfoundation.org> wrote:
> As Linus's tree is also broken, being bug-compatible here is good,
> right?  I can just apply the revert/fix patch when it lands in that
> tree, and all will be ok.
>
> Or is Linus's tree not broken now?  Sorry, this whole thread has been
> really confusing...

Linus' tree is broken in 2 ways:

1. It includes this patch:
"Bluetooth: btusb: fix QCA Rome suspend/resume"
which is wrong, and we're on our way to reverting it upstream and
backporting that to -stable.

2. It includes $subject patch. I'm not quite so sure, but I believe
it's not 100% "wrong"; it's just tougher for user space to deal with,
since now by default, all sorts of BT devices are set to be wakeup
sources. We can account for that in user space by being more careful
with initiating BT activity before suspend, but we don't currently do
that (at least not with the BlueZ in ChromeOS).
A related portion of this problem is that we briefly thought that this
patch resolved regressions with 1. In the end, it might mask some, but
it does not actually fix the problem. But then, you only included this
patch because somebody suggested it could resolve 1...

In the end, I'd say that #2 never belonged in -stable at all, and #1
was just "buggy" (so we're reverting it and letting the revert trickle
into -stable). I'm not sure I have a strong reason to revert #2
upstream, but I think I have an argument for not including it in
-stable.

I'm not sure what you mean by "bug-compatible"; if I wanted to use a
buggy kernel, I'd use Linus' tree :)

Or as I think I understand your point: the key point is that #2 might
not be actually a "bug", but a feature that user space has to be more
careful with. That may be a candidate for mainline, but not for
-stable, as I understand the current rules.

Brian