linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Brown <broonie@kernel.org>
Cc: Siddharth Kapoor <ksiddharth@google.com>,
	lee.jones@linaro.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: Kernel panic on Google Pixel devices due to regulator patch
Date: Wed, 18 Dec 2019 17:24:24 +0100	[thread overview]
Message-ID: <20191218162424.GA482612@kroah.com> (raw)
In-Reply-To: <20191218161806.GF3219@sirena.org.uk>

On Wed, Dec 18, 2019 at 04:18:06PM +0000, Mark Brown wrote:
> On Wed, Dec 18, 2019 at 03:22:19PM +0100, Greg KH wrote:
> > On Wed, Dec 18, 2019 at 01:11:14PM +0000, Mark Brown wrote:
> > > On Wed, Dec 18, 2019 at 01:21:57PM +0100, Greg KH wrote:
> 
> > > > It is, but it's the latest stable kernel (well close to), and your patch
> > > > was tagged by you to be backported to here, so if there's a problem with
> > > > a stable branch, I want to know about it as I don't want to see
> > > > regressions happen in it.
> 
> > > I don't track what's in older stable kernels, it wanted to go back at
> > > least one kernel revision but the issue has been around since forever.
> 
> > Ok, you can always mark patches that way if you want to :)
> 
> That's what a tag to stable with no particular revision attached to it
> is isn't it?

No, that means "drag it as far back as Greg can easily do it" :)

> > > If you don't want to be messing with timing luck then you probably want
> > > to be having a look at what Sasha's bot is doing, it's picking up a lot
> > > of things that are *well* into this sort of territory (and the bad
> > > interactions with out of tree code territory).  I personally would not
> > > be using stable these days if I wasn't prepared to be digging into
> > > something like this.
> 
> > I watch what his bot is doing, and we have tons of testing happening as
> > well, which is reflected by the fact that THIS WAS CAUGHT HERE.  This is
> 
> You don't have anywhere near the level of testing that you'd need to
> cover what the bot is trying to pull in, the subsystem and driver
> coverage is extremely thin relative to the enthusiasm with which things
> are being picked up.  All the pushback I see in review is on me for 
> being conservative about what gets pulled into stable and worrying about
> interactions with out of tree code.
> 
> > a sign that things are working, it's just that some SoC trees are slower
> > than mainline by a few months, and that's fine.  It's worlds better than
> > the SoC trees that are no where close to mainline, and as such, totally
> > insecure :)
> 
> What you appear to have caught here is an interaction with some
> unreviewed vendor code - how much of that is going on in the vendor
> trees you're not testing?  If we want to encourage people to pull in
> stable we should be paying attention to that sort of stuff.

I get weekly merge reports from all of the major SoC vendors when they
pull these releases into their tree and run through their full suite of
tests.  So I am paying attention to this type of thing.

What I need to figure out here is what is going wrong and why the SoC's
testing did not catch this.  That's going to take a bit longer...

thanks,

greg k-h

  reply	other threads:[~2019-12-18 16:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJRo92+eD9F6Q60yVY2PfwaPWO_8Dts8QwH7mhpJaem7SpLihg@mail.gmail.com>
2019-12-18 11:34 ` Kernel panic on Google Pixel devices due to regulator patch Mark Brown
2019-12-18 12:21   ` Greg KH
2019-12-18 13:11     ` Mark Brown
2019-12-18 14:22       ` Greg KH
2019-12-18 16:18         ` Mark Brown
2019-12-18 16:24           ` Greg KH [this message]
2019-12-18 17:03             ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191218162424.GA482612@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=broonie@kernel.org \
    --cc=ksiddharth@google.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).