From: "stephane eranian" <eranian@googlemail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
x86@kernel.org, andi@firstfloor.org, sfr@canb.auug.org.au,
"Roland McGrath" <roland@redhat.com>,
"Oleg Nesterov" <oleg@redhat.com>
Subject: Re: [patch 20/24] perfmon: system calls interface
Date: Thu, 27 Nov 2008 15:22:29 +0100 [thread overview]
Message-ID: <7c86c4470811270622s540a17d8r73462dfa93d1bc6d@mail.gmail.com> (raw)
In-Reply-To: <20081126140027.GC6562@elte.hu>
Ingo,
On Wed, Nov 26, 2008 at 3:00 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> Thirdly, the check for ->exit_state in pfm_task_incompatible() is not
> needed: we've just passed ptrace_check_attach() so we know we just
> transitioned the task to task->state == TASK_TRACED.
>
> If you _ever_ see a task exit TASK_TRACED and go zombie or dead from
> there without this code allowing it that means the whole state machine
> with ptrace is borked up by perfmon. For example i dont see where the
> perfmon-control task parents itself as the exclusive debugger (parent)
> of the debuggee-task.
>
Perfmon requires ptrace ONLY to stop the thread you want to operate
on. For instance, to read the counters in a thread via pfm_read(), you
need to have that thread stopped, so perfmon can extract the machine
state safely. But when the monitored thread runs, it does not have to
remain under the control of ptrace. All that is needed is that the thread
is stopped while we are in the perfmon syscall. I think ptrace allows this
today. We will be able to drop ptrace() once we switch to utrace in which
case, the kernel will be able to easily stop the thread when entering the
perfmon syscalls. I guess I don't quite understand the meaning of your
last sentence.
next prev parent reply other threads:[~2008-11-27 14:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 8:42 eranian
2008-11-26 12:02 ` Andi Kleen
2008-11-26 13:43 ` Ingo Molnar
2008-11-26 14:00 ` Ingo Molnar
2008-11-26 16:59 ` Oleg Nesterov
2008-11-27 12:25 ` stephane eranian
2008-11-27 12:41 ` Andi Kleen
2008-11-27 14:22 ` stephane eranian [this message]
2008-11-27 14:42 ` Ingo Molnar
2008-11-27 15:16 ` stephane eranian
2008-12-01 0:49 ` Paul Mackerras
2008-12-01 6:05 ` stephane eranian
2008-12-03 2:02 ` Roland McGrath
2008-12-04 1:05 ` Roland McGrath
2008-11-26 14:02 ` Ingo Molnar
2008-11-26 14:08 ` Ingo Molnar
2008-11-27 14:28 ` stephane eranian
2008-11-26 14:11 ` Ingo Molnar
2008-11-26 14:13 ` Ingo Molnar
2008-11-27 14:01 ` Thomas Gleixner
2008-11-27 14:07 ` stephane eranian
2008-12-01 6:10 ` stephane eranian
-- strict thread matches above, loose matches on Subject: below --
2008-11-25 21:36 eranian
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=7c86c4470811270622s540a17d8r73462dfa93d1bc6d@mail.gmail.com \
--to=eranian@googlemail.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=eranian@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®