From: Paul Mackerras <paulus@samba.org>
To: "K.Prasad" <prasad@linux.vnet.ibm.com>
Cc: Michael Neuling <mikey@neuling.org>,
Benjamin Herrenschmidt <benh@au1.ibm.com>,
shaggy@linux.vnet.ibm.com,
Frederic Weisbecker <fweisbec@gmail.com>,
David Gibson <dwg@au1.ibm.com>,
"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
Alan Stern <stern@rowland.harvard.edu>,
Roland McGrath <roland@redhat.com>
Subject: Re: [Patch 4/4] PPC64-HWBKPT: Enable hw-breakpoints while handling intervening signals
Date: Thu, 27 May 2010 16:32:23 +1000 [thread overview]
Message-ID: <20100527063223.GC4105@drongo> (raw)
In-Reply-To: <20100525091505.GE29003@in.ibm.com>
On Tue, May 25, 2010 at 02:45:05PM +0530, K.Prasad wrote:
> A signal delivered between a hw_breakpoint_handler() and the
> single_step_dabr_instruction() will not have the breakpoint active during
> signal handling (since breakpoint will not be restored through single-stepping
> due to absence of MSR_SE bit on the signal frame). Enable breakpoints before
> signal delivery.
>
> Restore hw-breakpoints if the user-context is altered in the signal handler.
...
> /*
> + * Restores the breakpoint on the debug registers.
> + * Invoke this function if it is known that the execution context is about to
> + * change to cause loss of MSR_SE settings.
> + */
> +void thread_change_pc(struct task_struct *tsk)
> +{
> + struct arch_hw_breakpoint *info;
> +
> + if (likely(!tsk->thread.last_hit_ubp))
> + return;
> +
> + info = counter_arch_bp(tsk->thread.last_hit_ubp);
> + set_dabr(info->address | info->type | DABR_TRANSLATION);
> +}
I think this function needs to clear current->thread.last_hit_ubp.
You also need to pass the regs to it so it can clear MSR_SE from
regs->msr.
> Index: linux-2.6.ppc64_test/arch/powerpc/kernel/signal_64.c
> ===================================================================
> --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/signal_64.c
> +++ linux-2.6.ppc64_test/arch/powerpc/kernel/signal_64.c
> @@ -33,6 +33,7 @@
> #include <asm/cacheflush.h>
> #include <asm/syscalls.h>
> #include <asm/vdso.h>
> +#include <asm/hw_breakpoint.h>
>
> #include "signal.h"
>
> @@ -312,6 +313,7 @@ int sys_swapcontext(struct ucontext __us
> || __copy_to_user(&old_ctx->uc_sigmask,
> ¤t->blocked, sizeof(sigset_t)))
> return -EFAULT;
> + thread_change_pc(current);
This is in the part of the code that is saving the old context, after
the old context has been saved. We need to do it before saving the
old context so that the saved context doesn't have the MSR_SE bit set
in its MSR image. And similarly in the 32-bit version.
In fact, we probably don't need to do anything here. We should never
get into a system call (such as sys_swapcontext or sys_sigreturn) when
single-stepping a load or store that caused a DABR match. If we do,
something very strange is happening. So I would leave out the
swapcontext changes for this version.
Paul.
next prev parent reply other threads:[~2010-05-27 6:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100525083055.342788418@linux.vnet.ibm.com>
2010-05-25 9:13 ` [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration K.Prasad
2010-05-25 11:39 ` Millton Miller
2010-05-26 6:51 ` K.Prasad
2010-05-26 9:54 ` David Howells
2010-05-26 15:13 ` Michael Ellerman
2010-05-26 17:17 ` K.Prasad
2010-05-26 17:23 ` Frederic Weisbecker
2010-05-26 17:31 ` K.Prasad
2010-05-26 17:35 ` Frederic Weisbecker
2010-05-26 17:28 ` K.Prasad
2010-05-25 9:14 ` [Patch 2/4] PPC64-HWBKPT: Implement hw-breakpoints for PowerPC BookIII S K.Prasad
2010-05-27 6:19 ` Paul Mackerras
2010-05-28 7:39 ` K.Prasad
2010-05-25 9:14 ` [Patch 3/4] PPC64-HWBKPT: Handle concurrent alignment interrupts K.Prasad
2010-05-27 6:20 ` Paul Mackerras
2010-05-28 7:41 ` K.Prasad
2010-05-25 9:15 ` [Patch 4/4] PPC64-HWBKPT: Enable hw-breakpoints while handling intervening signals K.Prasad
2010-05-27 6:32 ` Paul Mackerras [this message]
[not found] <20100524102614.040177456@linux.vnet.ibm.com>
2010-05-24 10:34 ` K.Prasad
2010-05-24 12:24 ` Paul Mackerras
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=20100527063223.GC4105@drongo \
--to=paulus@samba.org \
--cc=benh@au1.ibm.com \
--cc=dwg@au1.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=prasad@linux.vnet.ibm.com \
--cc=roland@redhat.com \
--cc=shaggy@linux.vnet.ibm.com \
--cc=stern@rowland.harvard.edu \
/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).