[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <24AFDCDB-55DE-4A23-A26A-750B48AC365C@gmail.com>
Date: Tue, 4 Aug 2015 02:22:16 +0900
From: Jungseok Lee <jungseoklee85@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Will Deacon <will.deacon@....com>,
Mark Rutland <Mark.Rutland@....com>,
Catalin Marinas <Catalin.Marinas@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
AKASHI Takahiro <takahiro.akashi@...aro.org>,
"broonie@...nel.org" <broonie@...nel.org>,
"david.griego@...aro.org" <david.griego@...aro.org>,
"olof@...om.net" <olof@...om.net>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC 2/3] arm64: refactor save_stack_trace()
On Aug 4, 2015, at 1:57 AM, Steven Rostedt wrote:
> On Tue, 4 Aug 2015 01:30:50 +0900
> Jungseok Lee <jungseoklee85@...il.com> wrote:
>
>
>> There are two issues in the current version.
>> 1) The change does not work correctly when function_graph feature is enabled.
>> 2) Akashi have raised an issue that size field of stack tracer is inaccurate.
>>
>> So, I think this patch set is not ready yet.
>
> Do you still want me to add code that does:
>
> if (*p == (stack_dump_trace[i] + FTRACE_STACK_FRAME_OFFSET)) {
>
> ?
>
> If you expect to need that, I can get it into the next merge window and
> you can base the code of that in the merge window after that.
It would be better to add the snippet when a new version is ready.
That way might help to figure out easily why the macro is introduced and how
it can be used in architecture code.
Best Regards
Jungseok Lee--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists