From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Kees Cook <keescook@chromium.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>, Laura Abbott <labbott@redhat.com>,
Anton Vorontsov <anton@enomsg.org>,
Colin Cross <ccross@android.com>, Jason Baron <jbaron@akamai.com>,
Tony Luck <tony.luck@intel.com>, Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Joel Fernandes <joel@joelfernandes.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Joe Perches <joe@perches.com>, Jim Cromie <jim.cromie@gmail.com>,
Rajendra Nayak <rnayak@codeaurora.org>,
Vivek Gautam <vivek.gautam@codeaurora.org>,
Sibi Sankar <sibis@codeaurora.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-arm-msm@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ingo Molnar <mingo@kernel.org>,
Tom Zanussi <tom.zanussi@linux.intel.com>
Subject: Re: [RFC PATCH v2 2/3] pstore: Add register read/write{b,w,l,q} tracing support
Date: Sat, 25 Aug 2018 12:54:07 +0530 [thread overview]
Message-ID: <7b212c02-d7ce-4309-155f-22b36963e41c@codeaurora.org> (raw)
In-Reply-To: <CAGXu5jL6tGu9U_ANrZSfWREtySqFAJ+CQa3v5YRihZ2oHNMGGw@mail.gmail.com>
On 8/24/2018 8:59 PM, Kees Cook wrote:
> On Fri, Aug 24, 2018 at 7:45 AM, Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>> read/write{b,w,l,q} are typically used for reading from memory
>> mapped registers, which can cause hangs if accessed
>> unclocked. Tracing these events can help in debugging
>> various issues faced during initial development.
>>
>> We log this trace information in persistent ram buffer which
>> can be viewed after reset.
>>
>> We use pstore_rtb_call() to write the RTB log to pstore.
>> RTB buffer size is taken from ramoops dt node with additional
>> property called rtb-size.
>>
>> For reading the trace after mounting pstore, rtb-ramoops entry
>> can be seen in /sys/fs/pstore/ as in below sample output.
>>
>> Sample output of tracing register reads/writes in drivers:
>>
>> # mount -t pstore pstore /sys/fs/pstore
>> # tail /sys/fs/pstore/rtb-ramoops-0
>> [LOGK_READ ] ts:36468476204 data:ffff00000800d0fc <ffff0000084e9ee0> gic_check_gicv2+0x58/0x60
>> [LOGK_WRITE] ts:36468477715 data:ffff00000800d000 <ffff0000084e9fac> gic_cpu_if_up+0xc4/0x110
>> [LOGK_READ ] ts:36468478548 data:ffff00000800d000 <ffff0000084e9fd8> gic_cpu_if_up+0xf0/0x110
>> [LOGK_WRITE] ts:36468480319 data:ffff00000800d000 <ffff0000084e9fac> gic_cpu_if_up+0xc4/0x110
>> [LOGK_READ ] ts:36468481048 data:ffff00000800d00c <ffff000008081a34> gic_handle_irq+0xac/0x128
>> [LOGK_WRITE] ts:36468482923 data:ffff00000800d010 <ffff000008081aac> gic_handle_irq+0x124/0x128
>> [LOGK_READ ] ts:36468483184 data:ffff00000800d00c <ffff000008081a34> gic_handle_irq+0xac/0x128
>> [LOGK_WRITE] ts:36468485215 data:ffff00000800d010 <ffff000008081aac> gic_handle_irq+0x124/0x128
>> [LOGK_READ ] ts:36468486309 data:ffff00000800d00c <ffff000008081a34> gic_handle_irq+0xac/0x128
>> [LOGK_WRITE] ts:36468488236 data:ffff00000800d010 <ffff000008081aac> gic_handle_irq+0x124/0x128
>>
>> Output has below 5 fields:
>>
>> * Log type, Timestamp, Data from caller which is the address of
>> read/write{b,w,l,q}, Caller ip and Caller name.
>>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>
> As this is a tracing-like method, could this instead be added to
> ftrace? That would mean it could reuse all the ftrace tools and you'd
> get pstore storage for free.
>
Ftrace does not trace __raw{read,write}{b,l,w,q}() functions. I am not
sure why and how it is filtered out because I do not see any notrace
flag in those functions, maybe that whole directory is filtered out.
So adding this functionality to ftrace would mean removing the notrace
for these functions i.e., something like using
__raw{read,write}{b,l,w,q}() as the available filter functions. Also
pstore ftrace does not filter functions to trace I suppose?
Coming to the reason as to why it would be good to keep this separate
from ftrace would be:
* Ftrace can get ip and parent ip, but suppose we need extra data (field
data) as in above sample output we would not be able to get through ftrace.
* Although this patch is for tracing register read/write, we can easily
add more functionality since we have dynamic_rtb api which can be hooked
to functions and start tracing events(IRQ, Context ID) something similar
to tracepoints.
Initially thought of having tracepoints for logging register read/write
but I do not know if we can export tracepoint data to pstore since the
main usecase is to debug unknown resets and hangs.
* This can be something similar to mmiotrace in x86 and kept seperate
from function tracer.
Thanks,
Sai Prakash
next prev parent reply other threads:[~2018-08-25 7:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-24 14:45 [RFC PATCH v2 0/3] Register read/write tracing with dynamic debug and pstore Sai Prakash Ranjan
2018-08-24 14:45 ` [RFC PATCH v2 1/3] tracing: Add support for logging data to uncached buffer Sai Prakash Ranjan
2018-08-24 14:45 ` [RFC PATCH v2 2/3] pstore: Add register read/write{b,w,l,q} tracing support Sai Prakash Ranjan
2018-08-24 15:29 ` Kees Cook
2018-08-25 7:24 ` Sai Prakash Ranjan [this message]
2018-08-27 16:15 ` Steven Rostedt
2018-08-28 13:17 ` Sai Prakash Ranjan
2018-08-28 16:02 ` Steven Rostedt
2018-08-28 17:26 ` Sai Prakash Ranjan
2018-08-24 14:45 ` [RFC PATCH v2 3/3] dynamic_debug: Add support for dynamic register trace Sai Prakash Ranjan
2018-09-06 10:05 ` Will Deacon
2018-09-06 18:06 ` Sai Prakash Ranjan
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=7b212c02-d7ce-4309-155f-22b36963e41c@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=anton@enomsg.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=ccross@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=jbaron@akamai.com \
--cc=jim.cromie@gmail.com \
--cc=joe@perches.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=rnayak@codeaurora.org \
--cc=rostedt@goodmis.org \
--cc=sibis@codeaurora.org \
--cc=tom.zanussi@linux.intel.com \
--cc=tony.luck@intel.com \
--cc=vivek.gautam@codeaurora.org \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).