[ added stable folks ]
On Sun, 7 Jul 2019 11:17:09 -0700 Linus Torvalds torvalds@linux-foundation.org wrote:
On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski luto@kernel.org wrote:
FWIW, I'm leaning toward suggesting that we apply the trivial tracing fix and backport *that*. Then, in -tip, we could revert it and apply this patch instead.
You don't have to have the same fix in stable as in -tip.
It's fine to send something to stable that says "Fixed differently by commit XYZ upstream". The main thing is to make sure that stable doesn't have fixes that then get lost upstream (which we used to have long long ago).
But isn't it easier for them to just pull the quick fix in, if it is in your tree? That is, it shouldn't be too hard to make the "quick fix" that gets backported on your tree (and probably better testing), and then add the proper fix on top of it. The stable folks will then just use the commit sha to know what to take, and feel more confident about taking it.
-- Steve
On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
[ added stable folks ]
On Sun, 7 Jul 2019 11:17:09 -0700 Linus Torvalds torvalds@linux-foundation.org wrote:
On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski luto@kernel.org wrote:
FWIW, I'm leaning toward suggesting that we apply the trivial tracing fix and backport *that*. Then, in -tip, we could revert it and apply this patch instead.
You don't have to have the same fix in stable as in -tip.
It's fine to send something to stable that says "Fixed differently by commit XYZ upstream". The main thing is to make sure that stable doesn't have fixes that then get lost upstream (which we used to have long long ago).
But isn't it easier for them to just pull the quick fix in, if it is in your tree? That is, it shouldn't be too hard to make the "quick fix" that gets backported on your tree (and probably better testing), and then add the proper fix on top of it. The stable folks will then just use the commit sha to know what to take, and feel more confident about taking it.
It all depends on what the "quick fix" is. The reason I want to take the exact same patch that is in Linus's tree is that 95% of the time that we do a "one off" patch for stable only, it's wrong. We _ALWAYS_ get it wrong somehow, it's crazy how bad we are at this. I don't know why this is, but we have the stats to prove it.
Because of this, I now require the "one off" stable only fixes to get a bunch of people reviewing it and write up a bunch of explaination as to why this is the way it is and why we can't just take whatever is in mainline.
thanks,
greg k-h
On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
[ added stable folks ]
On Sun, 7 Jul 2019 11:17:09 -0700 Linus Torvalds torvalds@linux-foundation.org wrote:
On Sun, Jul 7, 2019 at 8:11 AM Andy Lutomirski luto@kernel.org wrote:
FWIW, I'm leaning toward suggesting that we apply the trivial tracing fix and backport *that*. Then, in -tip, we could revert it and apply this patch instead.
You don't have to have the same fix in stable as in -tip.
It's fine to send something to stable that says "Fixed differently by commit XYZ upstream". The main thing is to make sure that stable doesn't have fixes that then get lost upstream (which we used to have long long ago).
But isn't it easier for them to just pull the quick fix in, if it is in your tree? That is, it shouldn't be too hard to make the "quick fix" that gets backported on your tree (and probably better testing), and then add the proper fix on top of it. The stable folks will then just use the commit sha to know what to take, and feel more confident about taking it.
I'd say that if the "final" fix is significantly different than what we'll end up with upstream then just do as Linus said and send us a separate backport.
If we try doing the apply fix/revert etc games it'll just be more difficult later on to parse what has happened. On the other hand, if we have a clear explanation in the backported commit as to how it's different from upstream and the reasons for doing so it'll make future us happy when we try to apply fixes on top of it.
-- Thanks, Sasha
On Wed, Jul 10, 2019 at 04:27:09PM -0400, Steven Rostedt wrote:
But isn't it easier for them to just pull the quick fix in, if it is in
Steve, I've not yet seen a quick fix that actually fixes all the problems.
Your initial one only fixes the IRQ tracing one, but leaves the context tracking one wide open.
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Peter Zijlstra -
Sasha Levin -
Steven Rostedt