Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1742217
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2] x86, stacktrace: avoid recording save_stack_trace wrappers |
| Date | 2017-09-29 18:00 +0200 |
| Message-ID | <uv5RM-86J-13@gated-at.bofh.it> (permalink) |
| References | <umZTc-5qV-11@gated-at.bofh.it> <uuZMl-4l7-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Sep 29, 2017 at 11:23:35AM +0200, Vlastimil Babka wrote:
> The save_stack_trace() and save_stack_trace_tsk() wrappers of
> __save_stack_trace() add themselves to the call stack, and thus appear in the
> recorded stacktraces. This is redundant and wasteful when we have limited space
> to record the useful part of the backtrace with e.g. page_owner functionality.
>
> Fix this by making sure __save_stack_trace() is noinline (which matches the
> current gcc decision) and bumping the skip in the wrappers
> (save_stack_trace_tsk() only when called for the current task). This is similar
> to what was done for arm in 3683f44c42e9 ("ARM: stacktrace: avoid listing
> stacktrace functions in stacktrace") and is pending for arm64.
>
> Also make sure that __save_stack_trace_reliable() doesn't get this problem in
> the future by marking it __always_inline (which matches current gcc decision),
> per Josh Poimboeuf.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
--
Josh
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2] x86, stacktrace: avoid recording save_stack_trace wrappers Vlastimil Babka <vbabka@suse.cz> - 2017-09-29 11:30 +0200 Re: [PATCH v2] x86, stacktrace: avoid recording save_stack_trace wrappers Josh Poimboeuf <jpoimboe@redhat.com> - 2017-09-29 18:00 +0200 [tip:x86/debug] x86/stacktrace: Avoid recording save_stack_trace() wrappers tip-bot for Vlastimil Babka <tipbot@zytor.com> - 2017-09-29 22:20 +0200
csiph-web