From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org,
"Martin J. Bligh" <mbligh@google.com>,
Rebecca Schultz <rschultz@google.com>
Subject: Re: [PATCH] Fix x86_64 TIF_SYSCALL_TRACE race in entry.S
Date: Sun, 28 Oct 2007 18:31:40 -0400 [thread overview]
Message-ID: <20071028223140.GA11864@Krystal> (raw)
In-Reply-To: <20071028212150.GA20321@one.firstfloor.org>
* Andi Kleen (andi@firstfloor.org) wrote:
> > Setting the thread flag being an atomic operation, I would expect
> > setting/clearing it asynchronously from another thread to be a valid
>
> It could be a very short stop. Also do you start kernel tracing that often?
>
It's not a matter of how often I start tracing, but more about what
impact I want this operation to have on a running production system. If
I start tracing on a server to try detecting particularly nasty race
conditions, I prefer not to interfere with the normal execution too
much. The same applies when we try to figure out the source of some
unexpected latencies experienced in user-space : stopping the processes
could be considered as having too much impact on the system studied.
I was already reluctant about iterating on every thread to set a flag
(this was proposed by Martin and Rebecca, in their Google ktrace
implementation), but I accepted to go forward this solution because of
the performance benefits. However, I would prefer not to go as far as
stopping each process on the system upon trace start/stop to perform
this unless it's the only solution left.
> > Here is a modified version where I add my test only in the path where we
> > know that we have work to do, therefore removing the supplementary test
> > from the performance critical path. Would it be more acceptable ?
>
> It's better, but stopping would be even better. I wouldn't
> be surprised if there are other problems with async thread flags changing.
>
Do you mean architectures other than x86_64 could also assume that the
thread flags will stay unchanged between two consecutive reads ? If
those thread flags were meant not to be asynchronously updated, why
would they require an atomic update at all ?
> Also I object to you calling this a bug. It's a new feature.
>
Agreed. ptrace seems to be correct as is. It would only be needed if we
plan to use the flags as I described TIF_KERNEL_TRACE.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2007-10-28 22:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 19:37 Adding TIF_TRACE_KERNEL to x86_64 Mathieu Desnoyers
2007-10-27 18:08 ` [PATCH] Fix x86_64 TIF_SYSCALL_TRACE race in entry.S Mathieu Desnoyers
2007-10-27 19:04 ` Andi Kleen
2007-10-28 21:15 ` Mathieu Desnoyers
2007-10-28 21:21 ` Andi Kleen
2007-10-28 22:31 ` Mathieu Desnoyers [this message]
2007-10-27 19:00 ` Adding TIF_TRACE_KERNEL to x86_64 Andi Kleen
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=20071028223140.GA11864@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=rschultz@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.