linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-arch@vger.kernel.org
Subject: [RFC] desired behaviour of syscall tracing wrt fork()
Date: Sat, 13 Oct 2012 20:38:39 +0100	[thread overview]
Message-ID: <20121013193839.GU2616@ZenIV.linux.org.uk> (raw)

	There's a lovely incosistency regarding whether we call
trace_sys_exit() for child process on return from fork()/clone()/etc.
The current situation:
	* called on amd64 for 32bit newborns
	* *NOT* called on i386 or amd64 for 64bit ones
	* not called on arm
	* called on ppc, s390, sh and sparc64
	* not wired on anything else
Note that existing in-kernel users of that tracepoint (ftrace and perf)
both at least attempt to bail out in that situation.  However, the
way it's done is not guaranteed to work if we wire more architectures -
it relies on syscall_get_nr() returning negative in child, which might
or might not work everywhere.  If nothing else, it's a landmine to
avoid...

	FWIW, I'd vote for not calling syscall_trace_...() on the way
from ret_from_fork() - nothing in there really wants to be called
for newborns; e.g. TIF_SYSCALL_TRACE is explicitly turned off for
newborns, audit_syscall_exit() will not see ->in_syscall set and will
log nothing and existing users of trace_sys_exit() at least attempt
to skip doing anything on those.

	Comments?  AFAICS, it's not that much surgery to do...

                 reply	other threads:[~2012-10-13 19:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20121013193839.GU2616@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=fweisbec@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.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).