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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox