All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.