linux-kernel - Re: Kernel panic on Google Pixel devices due to regulator patch

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

Message-ID: <20191218113458.GA3219@sirena.org.uk>
Date:   Wed, 18 Dec 2019 11:34:58 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Siddharth Kapoor <ksiddharth@...gle.com>
Cc:     lee.jones@...aro.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, gregkh@...uxfoundation.org
Subject: Re: Kernel panic on Google Pixel devices due to regulator patch

On Tue, Dec 17, 2019 at 11:51:55PM +0800, Siddharth Kapoor wrote:

> I would like to share a concern with the regulator patch which is part of
> 4.9.196 LTS kernel.

That's an *extremely* old kernel.

> https://lore.kernel.org/lkml/20190904124250.25844-1-broonie@kernel.org/

That's the patch "[PATCH] regulator: Defer init completion for a while
after late_initcall" which defers disabling of idle regulators for a
while.

Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.

> We have reverted the patch in Pixel kernels and would like you to look into
> this and consider reverting it upstream as well.

I've got nothing to do with the stable kernels so there's nothing I can
do here, sorry.  However if this is triggering anything it's almost
certainly some kind of timing issue (this code isn't new, it's just
being run a bit later) and is only currently working through luck so I
do strongly recommend trying to figure out the actual problem since it's
liable to come back and bite you later - we did find one buggy driver in
mainline as a result of this change, it's possible you've got another
one.  

Possibly your GPU supplies need to be flagged as always on, possibly
your GPU driver is forgetting to enable some supplies it needs, or
possibly there's a missing always-on constraint on one of the regulators
depending on how the driver expects this to work (if it's a proprietary
driver it shouldn't be using the regulator API itself).  I'm quite
surprised you've not seen any issue before given that the supplies would
still be being disabled earlier.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)