Linux-parisc archive on lore.kernel.org
 help / Atom feed
* [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
       [not found] <20181122002801.501220343@goodmis.org>
@ 2018-11-22  0:28 ` Steven Rostedt
       [not found]   ` <20181123073033.2083020863@mail.kernel.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Steven Rostedt @ 2018-11-22  0:28 UTC (permalink / raw)
  To: linux-kernel
  Cc: Linus Torvalds, Ingo Molnar, Andrew Morton, Thomas Gleixner,
	Peter Zijlstra, linux-arch, Joel Fernandes, Masami Hiramatsu,
	Josh Poimboeuf, Andy Lutomirski, Frederic Weisbecker,
	James E.J. Bottomley, Helge Deller, linux-parisc, stable

From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>

The function_graph_entry() function does the work of calling the function
graph hook function and the management of the shadow stack, simplifying the
work done in the architecture dependent prepare_ftrace_return().

Have parisc use the new code, and remove the shadow stack management as well as
having to set up the trace structure.

This is needed to prepare for a fix of a design bug on how the curr_ret_stack
is used.

Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Cc: stable@kernel.org
Fixes: 03274a3ffb449 ("tracing/fgraph: Adjust fgraph depth before calling trace return callback")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
 arch/parisc/kernel/ftrace.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

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 */
 
-- 
2.19.1



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
       [not found]   ` <20181123073033.2083020863@mail.kernel.org>
@ 2018-11-23  9:06     ` Helge Deller
  2018-11-23 17:12       ` Steven Rostedt
  0 siblings, 1 reply; 8+ messages in thread
From: Helge Deller @ 2018-11-23  9:06 UTC (permalink / raw)
  To: Sasha Levin, Steven Rostedt, linux-kernel
  Cc: Linus Torvalds, James E.J. Bottomley, linux-parisc, stable, stable

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
  2018-11-23  9:06     ` Helge Deller
@ 2018-11-23 17:12       ` Steven Rostedt
  2018-11-23 18:34         ` Sasha Levin
  0 siblings, 1 reply; 8+ messages in thread
From: Steven Rostedt @ 2018-11-23 17:12 UTC (permalink / raw)
  To: Helge Deller
  Cc: Sasha Levin, linux-kernel, Linus Torvalds, James E.J. Bottomley,
	linux-parisc, stable, stable

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
  2018-11-23 17:12       ` Steven Rostedt
@ 2018-11-23 18:34         ` Sasha Levin
  2018-11-23 19:26           ` Steven Rostedt
  0 siblings, 1 reply; 8+ messages in thread
From: Sasha Levin @ 2018-11-23 18:34 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Helge Deller, linux-kernel, Linus Torvalds, James E.J. Bottomley,
	linux-parisc, stable, stable

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
  2018-11-23 18:34         ` Sasha Levin
@ 2018-11-23 19:26           ` Steven Rostedt
  2018-11-23 20:00             ` Sasha Levin
  0 siblings, 1 reply; 8+ messages in thread
From: Steven Rostedt @ 2018-11-23 19:26 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Helge Deller, linux-kernel, Linus Torvalds, James E.J. Bottomley,
	linux-parisc, stable, stable

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
  2018-11-23 19:26           ` Steven Rostedt
@ 2018-11-23 20:00             ` Sasha Levin
  2018-11-24 18:46               ` Steven Rostedt
  0 siblings, 1 reply; 8+ messages in thread
From: Sasha Levin @ 2018-11-23 20:00 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Helge Deller, linux-kernel, Linus Torvalds, James E.J. Bottomley,
	linux-parisc, stable, stable

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
  2018-11-23 20:00             ` Sasha Levin
@ 2018-11-24 18:46               ` Steven Rostedt
  2018-12-03 14:54                 ` Sasha Levin
  0 siblings, 1 reply; 8+ messages in thread
From: Steven Rostedt @ 2018-11-24 18:46 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Helge Deller, linux-kernel, Linus Torvalds, James E.J. Bottomley,
	linux-parisc, stable, stable

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()
  2018-11-24 18:46               ` Steven Rostedt
@ 2018-12-03 14:54                 ` Sasha Levin
  0 siblings, 0 replies; 8+ messages in thread
From: Sasha Levin @ 2018-12-03 14:54 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Helge Deller, linux-kernel, Linus Torvalds, James E.J. Bottomley,
	linux-parisc, stable, stable

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20181122002801.501220343@goodmis.org>
2018-11-22  0:28 ` [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry() Steven Rostedt
     [not found]   ` <20181123073033.2083020863@mail.kernel.org>
2018-11-23  9:06     ` Helge Deller
2018-11-23 17:12       ` Steven Rostedt
2018-11-23 18:34         ` Sasha Levin
2018-11-23 19:26           ` Steven Rostedt
2018-11-23 20:00             ` Sasha Levin
2018-11-24 18:46               ` Steven Rostedt
2018-12-03 14:54                 ` Sasha Levin

Linux-parisc archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-parisc/0 linux-parisc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-parisc linux-parisc/ https://lore.kernel.org/linux-parisc \
		linux-parisc@vger.kernel.org linux-parisc@archiver.kernel.org
	public-inbox-index linux-parisc


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-parisc


AGPL code for this site: git clone https://public-inbox.org/ public-inbox