From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: David Gibson <dwg@au1.ibm.com>
Cc: Michael Neuling <mikey@neuling.org>,
Benjamin Herrenschmidt <benh@au1.ibm.com>,
linuxppc-dev@ozlabs.org, Alan Stern <stern@rowland.harvard.edu>,
paulus@samba.org, Roland McGrath <roland@redhat.com>
Subject: Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
Date: Fri, 29 May 2009 19:24:26 +0530 [thread overview]
Message-ID: <20090529135426.GA12307@in.ibm.com> (raw)
In-Reply-To: <20090529041849.GD8621@yookeroo.seuss>
On Fri, May 29, 2009 at 02:18:49PM +1000, David Gibson wrote:
> On Mon, May 25, 2009 at 06:45:22AM +0530, K.Prasad wrote:
> > +/*
> > + * Handle debug exception notifications.
> > + */
> > +int __kprobes hw_breakpoint_handler(struct die_args *args)
> > +{
> > + int rc = NOTIFY_STOP;
> > + struct hw_breakpoint *bp;
> > + struct pt_regs *regs = args->regs;
> > + unsigned long dar = regs->dar;
> > + int cpu, stepped = 1;
> > +
> > + /* Disable breakpoints during exception handling */
> > + set_dabr(0);
> > +
> > + cpu = get_cpu();
> > + /* Determine whether kernel- or user-space address is the trigger */
> > + bp = (hbp_kernel_pos == HBP_NUM) ? current->thread.hbp[0] :
> > + per_cpu(this_hbp_kernel[0], cpu);
> > + /*
> > + * bp can be NULL due to lazy debug register switching
> > + * or due to the delay between updates of hbp_kernel_pos
> > + * and this_hbp_kernel.
> > + */
> > + if (!bp)
> > + goto out;
> > +
> > + if (dar == bp->info.address)
> > + per_cpu(dabr_data, cpu) = (hbp_kernel_pos == HBP_NUM) ?
> > + current->thread.dabr : kdabr;
> > + else {
> > + /*
> > + * This exception is triggered not because of a memory access on
> > + * the monitored variable but in the double-word address range
> > + * in which it is contained. We will consume this exception,
> > + * considering it as 'noise'.
> > + */
> > + rc = NOTIFY_STOP;
> > + goto out;
> > + }
> > + (bp->triggered)(bp, regs);
>
> This will fire the handler function before the instruction has
> executed. I remember seeing a comment in the other patchset saying
> the function would be triggered after execution, but I'm not sure if
> that was in generic of x86-specific code.
>
Yes, I see that the comment
" * @triggered: callback invoked after target address access"
in include/asm-generic/hw_breakpoint.h which has to be changed. I will
do the same in a follow-on patch to the generic interface after its
integration.
> > +
> > + stepped = emulate_step(regs, regs->nip);
> > + /*
> > + * Single-step the causative instruction manually if
> > + * emulate_step() could not execute it
> > + */
> > + if (stepped == 0) {
> > + regs->msr |= MSR_SE;
> > + goto out;
> > + }
> > + set_dabr(per_cpu(dabr_data, cpu));
> > + per_cpu(dabr_data, cpu) = 0;
>
> This curly arrangement of put_cpu() / get_cpu() could probably do with
> some more comments...
>
The put_cpu() usage in hw_breakpoint_handler() and
single_step_dabr_instruction() is actually wrapped with comments.
Do you want a comment about the usage of the per_cpu data variable used
above, or a more descriptive comment in places where put_cpu() is use?
> > +out:
> > + /* Enable pre-emption only if single-stepping is finished */
> > + if (stepped)
> > + put_cpu_no_resched();
> > + return rc;
> > +}
> > +
> > +/*
> > + * Handle single-step exceptions following a DABR hit.
> > + */
> > +int __kprobes single_step_dabr_instruction(struct die_args *args)
> > +{
> > + struct pt_regs *regs = args->regs;
> > + int cpu = get_cpu();
> > + int ret = NOTIFY_DONE;
> > + siginfo_t info;
> > + unsigned long this_dabr_data = per_cpu(dabr_data, cpu);
> > +
> > + /*
> > + * Check if we are single-stepping as a result of a
> > + * previous HW Breakpoint exception
> > + */
> > + if (this_dabr_data == 0)
> > + goto out;
> > +
> > + regs->msr &= ~MSR_SE;
> > + /* Deliver signal to user-space */
> > + if (this_dabr_data < TASK_SIZE) {
> > + info.si_signo = SIGTRAP;
> > + info.si_errno = 0;
> > + info.si_code = TRAP_HWBKPT;
> > + info.si_addr = (void __user *)(per_cpu(dabr_data, cpu));
> > + force_sig_info(SIGTRAP, &info, current);
> > + }
>
> Ok, this is a behaviour change - the old do_dabr() code fired the
> SIGTRAP before the instruction completed, but this will fire it
> after. It seems simpler and safer to move this into ptrace's
> triggered function.
>
Thanks, I realise that this changes the user-space behaviour.
The one-shot hardware breakpoint exception behaviour and also
single-stepping the instruction have changed.
I will modify the hw_breakpoint_handler() to overcome this problem.
Thanks,
K.Prasad
next prev parent reply other threads:[~2009-05-29 13:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090525004730.944465878@prasadkr_t60p.in.ibm.com>
2009-05-25 1:14 ` [Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure K.Prasad
2009-05-29 3:20 ` David Gibson
2009-05-29 9:53 ` K.Prasad
2009-05-25 1:15 ` [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces K.Prasad
2009-05-29 4:18 ` David Gibson
2009-05-29 13:54 ` K.Prasad [this message]
2009-05-25 1:16 ` [Patch 3/6] Modify ptrace code to use " K.Prasad
2009-05-25 1:16 ` [Patch 4/6] Modify process and processor handling code to recognise hardware debug registers K.Prasad
2009-05-29 4:29 ` David Gibson
2009-05-25 1:17 ` [Patch 5/6] Modify Data storage exception code to recognise DABR match first K.Prasad
2009-05-25 1:17 ` [Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage K.Prasad
[not found] <20090603162741.197115376@prasadkr_t60p.in.ibm.com>
2009-06-03 16:35 ` [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces K.Prasad
2009-06-05 5:11 ` David Gibson
2009-06-10 6:43 ` K.Prasad
2009-06-15 6:40 ` David Gibson
2009-06-15 7:18 ` K.Prasad
2009-06-17 4:45 ` David Gibson
[not found] <20090610090316.898961359@prasadkr_t60p.in.ibm.com>
2009-06-10 9:08 ` K.Prasad
2009-06-17 4:32 ` David Gibson
2009-06-18 18:20 ` K.Prasad
2009-06-19 5:04 ` David Gibson
2009-07-03 8:11 ` K.Prasad
[not found] <20090726235854.574539012@prasadkr_t60p.in.ibm.com>
2009-07-27 0:13 ` K.Prasad
2009-07-31 6:16 ` David Gibson
2009-08-03 20:59 ` K.Prasad
2009-08-05 2:55 ` David Gibson
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=20090529135426.GA12307@in.ibm.com \
--to=prasad@linux.vnet.ibm.com \
--cc=benh@au1.ibm.com \
--cc=dwg@au1.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=paulus@samba.org \
--cc=roland@redhat.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 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.