| Message ID | 20181122003332.500796758@goodmis.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | None | expand |
HI Sasha, On 23.11.18 08:30, Sasha Levin wrote: > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: 03274a3ffb44 tracing/fgraph: Adjust fgraph depth before calling trace return callback. > > The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138, v4.4.164, v3.18.126. > > v4.19.3: Build OK! > v4.14.82: Build OK! > v4.9.138: Build OK! > v4.4.164: Failed to apply! Possible dependencies: > Unable to calculate > > v3.18.126: Failed to apply! Possible dependencies: > Unable to calculate > > How should we proceed with this patch? My suggestion, although I didn't looked too much on it: Apply it to v4.9 and higher only. I think I started fixing trace functionality on parisc around 4.6, which is probably why applying it fails on v4.4 and v3.x Helge
On Fri, 23 Nov 2018 10:06:05 +0100 Helge Deller <deller@gmx.de> wrote: > > How should we proceed with this patch? > > My suggestion, although I didn't looked too much on it: > Apply it to v4.9 and higher only. > I think I started fixing trace functionality on parisc around 4.6, > which is probably why applying it fails on v4.4 and v3.x The problem is, if you backport the generic patches, it will completely break any arch that isn't updated. This also includes the archs that are no longer supported upstream, as they were not changed to handle the generic updates either. -- Steve
On Fri, Nov 23, 2018 at 12:12:53PM -0500, Steven Rostedt wrote: >On Fri, 23 Nov 2018 10:06:05 +0100 >Helge Deller <deller@gmx.de> wrote: > > >> > How should we proceed with this patch? >> >> My suggestion, although I didn't looked too much on it: >> Apply it to v4.9 and higher only. >> I think I started fixing trace functionality on parisc around 4.6, >> which is probably why applying it fails on v4.4 and v3.x > >The problem is, if you backport the generic patches, it will completely >break any arch that isn't updated. This also includes the archs that >are no longer supported upstream, as they were not changed to handle >the generic updates either. Does this mean that someone (Steve) will send a backport of this to all relevant stable trees? Right now it looks like the series will randomly apply on a mix of trees, which can't be good. -- Thanks, Sasha
On Fri, 23 Nov 2018 13:34:15 -0500 Sasha Levin <sashal@kernel.org> wrote: > Does this mean that someone (Steve) will send a backport of this to all > relevant stable trees? Right now it looks like the series will randomly > apply on a mix of trees, which can't be good. Nope. I stated that in my 0 patch. -- Steve
On Fri, Nov 23, 2018 at 02:26:17PM -0500, Steven Rostedt wrote: >On Fri, 23 Nov 2018 13:34:15 -0500 >Sasha Levin <sashal@kernel.org> wrote: > >> Does this mean that someone (Steve) will send a backport of this to all >> relevant stable trees? Right now it looks like the series will randomly >> apply on a mix of trees, which can't be good. > >Nope. I stated that in my 0 patch. That's not good though, if you don't intend for them to be automagically backported to stable trees by Greg, then they shouldn't be tagged at all and if someone is interested then he can provide a backport. What will happen with these is that once Greg's scripts process Linus's tree he'll end up with this patch series inconsistently backported to stable trees, which is not what you want here. Sure, we can wait for the "added to the xyz stable tree" mails and object then, but why risk breaking the trees? -- Thanks. Sasha
On Fri, 23 Nov 2018 15:00:11 -0500 Sasha Levin <sashal@kernel.org> wrote: > On Fri, Nov 23, 2018 at 02:26:17PM -0500, Steven Rostedt wrote: > >On Fri, 23 Nov 2018 13:34:15 -0500 > >Sasha Levin <sashal@kernel.org> wrote: > > > >> Does this mean that someone (Steve) will send a backport of this to all > >> relevant stable trees? Right now it looks like the series will randomly > >> apply on a mix of trees, which can't be good. > > > >Nope. I stated that in my 0 patch. > > That's not good though, if you don't intend for them to be automagically > backported to stable trees by Greg, then they shouldn't be tagged at all > and if someone is interested then he can provide a backport. For the most part they will be fine going back a few releases. But how far back is questionable before they start getting into issues. I talked a bit about this to Greg on IRC and he seemed fine with me adding the stable tag. If they don't port back properly, it wont be a silent failure. They will either build or they wont. I'm suspect that you build all supported archs for your stable trees, right? If the patch fails to build, then either have someone that cares for that arch back port it, or don't back port the series. Simple as that. > > What will happen with these is that once Greg's scripts process Linus's > tree he'll end up with this patch series inconsistently backported to > stable trees, which is not what you want here. It's not like it won't work and then start to work again. Once they start failing in older versions, they will probably fail in all versions before that. > > Sure, we can wait for the "added to the xyz stable tree" mails and > object then, but why risk breaking the trees? Again, it's not much different than other stable patches that need to be fixed for older trees. If they build, they are fine, if they don't then they need to be fixed. You'll know right at build time. -- Steve
On Sat, Nov 24, 2018 at 01:46:34PM -0500, Steven Rostedt wrote: >On Fri, 23 Nov 2018 15:00:11 -0500 >Sasha Levin <sashal@kernel.org> wrote: >> What will happen with these is that once Greg's scripts process Linus's >> tree he'll end up with this patch series inconsistently backported to >> stable trees, which is not what you want here. > >It's not like it won't work and then start to work again. Once they >start failing in older versions, they will probably fail in all >versions before that. > >> >> Sure, we can wait for the "added to the xyz stable tree" mails and >> object then, but why risk breaking the trees? > >Again, it's not much different than other stable patches that need to >be fixed for older trees. If they build, they are fine, if they don't >then they need to be fixed. You'll know right at build time. So the only tree it applied and built was 4.19, all older trees failed on at least one arch. I'm going to remove any parts of this series from all other trees. -- Thanks, Sasha
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c index 6fa8535d3cce..e46a4157a894 100644 --- a/arch/parisc/kernel/ftrace.c +++ b/arch/parisc/kernel/ftrace.c @@ -30,7 +30,6 @@ static void __hot prepare_ftrace_return(unsigned long *parent, unsigned long self_addr) { unsigned long old; - struct ftrace_graph_ent trace; extern int parisc_return_to_handler; if (unlikely(ftrace_graph_is_dead())) @@ -41,19 +40,9 @@ static void __hot prepare_ftrace_return(unsigned long *parent, old = *parent; - trace.func = self_addr; - trace.depth = current->curr_ret_stack + 1; - - /* Only trace if the calling function expects to */ - if (!ftrace_graph_entry(&trace)) - return; - - if (ftrace_push_return_trace(old, self_addr, &trace.depth, - 0, NULL) == -EBUSY) - return; - - /* activate parisc_return_to_handler() as return point */ - *parent = (unsigned long) &parisc_return_to_handler; + if (!function_graph_enter(old, self_addr, 0, NULL)) + /* activate parisc_return_to_handler() as return point */ + *parent = (unsigned long) &parisc_return_to_handler; } #endif /* CONFIG_FUNCTION_GRAPH_TRACER */