From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Anton Arapov <anton@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Roland McGrath <roland@hack.frob.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] ptrace: DEBUGCTLMSR_BTF fixes
Date: Tue, 07 Aug 2012 17:38:45 +0200 [thread overview]
Message-ID: <50213685.3010208@linutronix.de> (raw)
In-Reply-To: <20120807151512.GB13476@redhat.com>
On 08/07/2012 05:15 PM, Oleg Nesterov wrote:
>> So I think __switch_to_extra() should set the bit before putting the
>> task on the CPU.
>
> Why?
Pardon me? __switch_to_extra() enables BTF before putting the task on
CPU. This is fine. I was trying to say that there is no need to touch
the debug register in debugger's context since __switch_to_extra() does
it.
>> If this bit is enabled on the wrong CPU then in will
>> remain set forever if single steeping has not been / will not be
>> enabled.
>
> I don't follow, could you explain in details?
The SMP case where the debugger runs on CPU0 and tracee on CPU1.
Without your "current != child" check the enable_block_step() enables
block stepping on CPU0 and switch_to_extra() on CPU1.
> Just in case, X86_EFLAGS_TF sits in task_pt_regs(next), it has no
> effect until the task returns to usermode. We only need to ensure
> DEBUGCTLMSR_BTF was set/cleared correctly when it actually returns.
Exactly. And __switch_to_extra() is perfect for the job (if we ignore
uprobes for a moment).
> Oleg.
Sebastian
next prev parent reply other threads:[~2012-08-07 15:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-03 16:29 [PATCH 0/2] ptrace: DEBUGCTLMSR_BTF fixes Oleg Nesterov
2012-08-03 16:29 ` [PATCH 1/2] ptrace: introduce set_task_blockstep() helper Oleg Nesterov
2012-08-03 16:29 ` [PATCH 2/2] ptrace: fix set_task_blockstep()->update_debugctlmsr() logic Oleg Nesterov
2012-08-03 16:43 ` Sebastian Andrzej Siewior
2012-08-03 17:38 ` Oleg Nesterov
2012-08-03 18:28 ` Sebastian Andrzej Siewior
2012-08-07 15:13 ` Oleg Nesterov
2012-08-07 9:41 ` Sebastian Andrzej Siewior
2012-08-07 10:52 ` Sebastian Andrzej Siewior
2012-08-07 15:15 ` Oleg Nesterov
2012-08-07 15:29 ` Sebastian Andrzej Siewior
2012-08-07 15:31 ` Oleg Nesterov
2012-08-07 15:12 ` Oleg Nesterov
2012-08-06 16:14 ` [PATCH 0/2] ptrace: DEBUGCTLMSR_BTF fixes Sebastian Andrzej Siewior
2012-08-07 15:15 ` Oleg Nesterov
2012-08-07 15:38 ` Sebastian Andrzej Siewior [this message]
2012-08-07 15:46 ` Oleg Nesterov
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=50213685.3010208@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=ananth@in.ibm.com \
--cc=anton@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=roland@hack.frob.com \
--cc=srikar@linux.vnet.ibm.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.