From: wade_farnsworth@mentor.com (Wade Farnsworth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: support syscall tracing
Date: Wed, 15 Aug 2012 12:35:36 -0700 [thread overview]
Message-ID: <502BFA08.6010708@mentor.com> (raw)
In-Reply-To: <20120815172731.GL29448@mudshark.cambridge.arm.com>
Will Deacon wrote:
> On Wed, Aug 15, 2012 at 05:58:44PM +0100, Wade Farnsworth wrote:
>> We need to set current_thread_info()->syscall, since it's used in the
>> call to syscall_get_nr() in perf_syscall_{enter,exit}.
>
> Damn. I think that also means we have a bug, given that the SYSCALL_TRACE
> code can set this to -1, which gets used as an index into a bitmap by the
> looks of it. Considering that we have to pass the syscall number to
> trace_sys_enter anyway, it also seems broken.
>
I agree. Looking at the other architectures, it seems the analogous
function to ptrace_syscall_trace can return -1 under certain
circumstances, but the original syscall value should be passed onto
trace_sys_enter and returned from syscall_get_nr(). So, I'm thinking
that we should modify our behavior accordingly. What this means for us
is that we never store -1 in the thread_info syscall field, and then
pass that into trace_sys_enter instead of the ptrace_syscall_trace
return value. Do you see any problems with this approach?
>> What about moving the setting of ->syscall to
>> syscall_trace_{enter,exit}? That would preserve ptrace_syscall_trace()
>> for the TIF_SYSCALL_TRACE case only, but ensure that the field is set
>> the TRACEPOINT case as well. Thoughts?
>
> I'd be tempted to set the thing unconditionally before checking the thread
> flag at the top of ptrace_syscall_trace. This hangs off the slowpath anyway
> and it makes everything a lot more readable.
>
OK, I'll make that change.
Wade
next prev parent reply other threads:[~2012-08-15 19:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 15:14 [PATCH v2] ARM: support syscall tracing Wade Farnsworth
2012-08-15 16:21 ` Will Deacon
2012-08-15 16:58 ` Wade Farnsworth
2012-08-15 17:27 ` Will Deacon
2012-08-15 19:35 ` Wade Farnsworth [this message]
2012-08-15 20:21 ` Wade Farnsworth
2012-08-16 9:54 ` Will Deacon
2012-08-16 14:33 ` Wade Farnsworth
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=502BFA08.6010708@mentor.com \
--to=wade_farnsworth@mentor.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).