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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 21 Dec 2017 09:30:52 +0100
From:   "" <>
To:     Brian Norris <>
        Sukumar Ghorai <>,
        Amit K Bag <>,
        Oliver Neukum <>,
        Marcel Holtmann <>,
        Matthias Kaehlcke <>,
        Todd Broch <>,
        Rajat Jain <>,
        Miao Chou <>,,
        Guenter Roeck <>
Subject: Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the
 usb-wakeup feature

On Wed, Dec 20, 2017 at 11:51:15AM -0800, Brian Norris wrote:
> Hi Greg,
> On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> I'm sorry, but I already objected to this one during the discussion
> here:
> [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
> in which we pointed out a regression. The $subject patch does NOT
> actually resolve the previous regression, though it might help to mask
> it. The proper approach to resolve the above regression was to revert
> the patch, not to backport the $subject patch.
> Regarding this patch, IIUC this is not a bugfix -- it's a feature
> addition (e.g., for helping with BLE mouse wakeup), and it has already
> been proven to break some user space (we have an internal bug tracking
> this, but suffice it to say that we've already tried and reverted this
> patch [1]). This patch massively increases the surface in which spurious
> bluetooth activity can wake the system, and in some cases we never can
> suspend the system at all.
> Unfortunately, Matthias was on vacation when you sent the review
> request, so our team wasn't alerted properly. Can you please back this
> out of all -stable branches?
> Or alternatively, if those I've added on CC disagree and are happy to
> deal with the fallout of this patch...well, then that's fine. We can
> revert this patch in our downstream kernels and reapply if/when we can
> account for it properly :)

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


greg k-h

Powered by blists - more mailing lists