From: Masami Hiramatsu <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Masami Hiramatsu <mhiramat@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Frederic Weisbecker <frederic@kernel.org>,
Joel Fernandes <joel@joelfernandes.org>,
Andy Lutomirski <luto@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Namhyung Kim <namhyung@kernel.org>,
"Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: [RFC][PATCH 01/14 v2] function_graph: Convert ret_stack to a series of longs
Date: Mon, 3 Jun 2019 20:30:49 +0900 [thread overview]
Message-ID: <20190603203049.bf07719eb3c0af4218812b3f@kernel.org> (raw)
In-Reply-To: <20190524080553.354f1cae@gandalf.local.home>
On Fri, 24 May 2019 08:05:53 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > +#define SHADOW_STACK_SIZE (PAGE_SIZE)
> >
> > Do we really need that big a shadow stack?
>
> Well, this is a sticky point. I allow up to 16 users at a time
> (although I can't imagine more than 5, but you never know), and each
> user adds a long and up to 4 more words (which is probably unlikely
> anyway). And then we can have deep call stacks (we are getting deeper
> each release it seems).
>
> I figured, I start with a page size, and then in the future we can make
> it dynamic, or shrink it if it proves to be too much.
I'd prefer dynamic allocation, based on the number of users or actual
stack starvation.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2019-06-03 11:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 14:20 [RFC][PATCH 00/14 v2] function_graph: Rewrite to allow multiple users Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 01/14 v2] function_graph: Convert ret_stack to a series of longs Steven Rostedt
2019-05-24 11:11 ` Peter Zijlstra
2019-05-24 12:05 ` Steven Rostedt
2019-06-03 11:30 ` Masami Hiramatsu [this message]
2019-06-04 9:04 ` Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 02/14 v2] function_graph: Add an array structure that will allow multiple callbacks Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 03/14 v2] function_graph: Allow multiple users to attach to function graph Steven Rostedt
2019-05-24 11:26 ` Peter Zijlstra
2019-05-24 12:12 ` Steven Rostedt
2019-05-24 12:27 ` Peter Zijlstra
2019-05-24 12:57 ` Steven Rostedt
2019-05-27 10:10 ` Peter Zijlstra
2019-05-27 11:08 ` Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 04/14 v2] function_graph: Remove logic around ftrace_graph_entry and return Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 05/14 v2] ftrace/function_graph: Pass fgraph_ops to function graph callbacks Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 06/14 v2] ftrace: Allow function_graph tracer to be enabled in instances Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 07/14 v2] ftrace: Allow ftrace startup flags exist without dynamic ftrace Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 08/14 v2] function_graph: Have the instances use their own ftrace_ops for filtering Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 09/14 v2] function_graph: Add "task variables" per task for fgraph_ops Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 10/14 v2] function_graph: Move set_graph_function tests to shadow stack global var Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 11/14 v2] function_graph: Move graph depth stored data " Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 12/14 v2] function_graph: Move graph notrace bit " Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 13/14 v2] function_graph: Implement fgraph_reserve_data() and fgraph_retrieve_data() Steven Rostedt
2019-05-20 14:20 ` [RFC][PATCH 14/14 v2] function_graph: Add selftest for passing local variables Steven Rostedt
2019-05-22 14:19 ` [RFC][PATCH 00/14 v2] function_graph: Rewrite to allow multiple users Masami Hiramatsu
2019-05-22 14:40 ` Steven Rostedt
2019-05-29 6:47 ` Masami Hiramatsu
2019-05-29 9:25 ` Steven Rostedt
2019-05-30 9:29 ` Masami Hiramatsu
2019-06-08 6:23 ` Steven Rostedt
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=20190603203049.bf07719eb3c0af4218812b3f@kernel.org \
--to=mhiramat@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=fche@redhat.com \
--cc=frederic@kernel.org \
--cc=joel@joelfernandes.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.