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
