linux-kernel - Re: [PATCH] Revert "xhci: plat: Register shutdown for xhci

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] [day] [month] [year] [list]

Date:   Sat, 14 Apr 2018 15:48:30 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Harsh Shandilya <msfjarvis@...il.com>
Cc:     Greg Hackmann <ghackmann@...gle.com>,
        Adam Wallis <awallis@...eaurora.org>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH] Revert "xhci: plat: Register shutdown for xhci_plat"

On Fri, Apr 13, 2018 at 12:34:00PM +0530, Harsh Shandilya wrote:
> On 13 April 2018 11:51:28 AM IST, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> >On Fri, Apr 13, 2018 at 08:12:31AM +0530, Harsh Shandilya wrote:
> >> On 13 April 2018 5:59:51 AM IST, Greg Hackmann <ghackmann@...gle.com>
> >wrote:
> >> >Pixel 2 field testers reported that when they tried to reboot their
> >> >phones with some USB devices plugged in, the reboot would get wedged
> >> >and
> >> >eventually trigger watchdog reset.  Once the Pixel kernel team found
> >a
> >> >reliable repro case, they narrowed it down to this commit's 4.4.y
> >> >backport.  Reverting the change made the issue go away.
> >> 
> >> Are you allowed to make the repro steps public? I'm writing this from
> >> a walleye and would be grateful if I could test for this in the
> >> modifed tree I'm running atm.  -- 
> >
> >I was told the steps are pretty simple:
> >	- reboot the phone a lot
> >eventually it will hang.  There's a fix in the code aurora kernel tree
> >for this that they never sent upstream for some odd reason (they sent
> >the first patch, why not the second?)
> >
> >I'll go revert this for now, thanks for the patch!
> >
> >greg k-h
> 
> That'd make sense, I only tried rebooting like five times before I had to run for a class.
> 
> As far as CAF is concerned, I feel the not submitting upstream,
> working extra to write patches which have usually better variants
> already upstream, seems to be common. All USB changes were dropped
> when they merged kernel-common into msm-3.18 with no real explanation
> which has been an annoyance more than once during merging -stable in
> my fork of msm-3.18. While I understand their situation of maintaining
> upwards of 5 million lines of code not upstream, it still feels sloppy
> to not merge stable updates and do extra work instead. /* End rant */

CAF fixed this back on Feb 1 in their tree, yet did not send that
upstream, or to anyone else:
	https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LV.HB.1.1.5-03810-8x96.0&id=a7a5307ee04ad349d365ad50f304605a9cd9bd0a

Feel free to rant some more, I'm going to go revert the original
upstream patch as that is half-completed, and obviously broken :(

thanks,

greg k-h