From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Michael Neuling <mikey@neuling.org>,
Benjamin Herrenschmidt <benh@au1.ibm.com>,
linuxppc-dev@ozlabs.org, paulus@samba.org,
Roland McGrath <roland@redhat.com>
Subject: Re: [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces
Date: Mon, 18 May 2009 21:40:55 +0530 [thread overview]
Message-ID: <20090518161055.GA27641@in.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0905141614360.4344-100000@iolanthe.rowland.org>
On Thu, May 14, 2009 at 04:20:04PM -0400, Alan Stern wrote:
> On Fri, 15 May 2009, K.Prasad wrote:
>
> > I see that you're referring to this code in __switch_to() :
> > if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
> > set_dabr(new->thread.dabr);
> >
> > arch_install_thread_hw_breakpoint()<--switch_to_thread_hw_breakpoint()
> > <--__switch_to() implementation is also similar.
> >
> > In __switch_to(),
> > if (unlikely(test_tsk_thread_flag(new, TIF_DEBUG)))
> > switch_to_thread_hw_breakpoint(new);
> >
> > happens only when TIF_DEBUG flag is set. This flag is cleared when the
> > process unregisters any breakpoints it had requested earlier. So, the
> > set_dabr() call is avoided for processes not using the debug register.
>
> In the x86 code, shouldn't arch_update_user_hw_breakpoint set or clear
> TIF_DEBUG, depending on whether or not there are any user breakpoints
> remaining?
>
Yes. There's a bigger issue in setting TIF_DEBUG flag through ptrace
code. It should instead be done in register_user_hw_breakpoint() and
removed through unregister_user_hw_breakpoint() when the last breakpoint
request is being unregistered.
The unregister_user_hw_breakpoint() code should be like this:
void unregister_user_hw_breakpoint(struct task_struct *tsk,
struct hw_breakpoint *bp)
{
struct thread_struct *thread = &(tsk->thread);
int i, pos = -1, clear_tsk_debug_counter = 0;
spin_lock_bh(&hw_breakpoint_lock);
for (i = 0; i < hbp_kernel_pos; i++) {
if (thread->hbp[i])
clear_tsk_debug_counter++;
if (bp == thread->hbp[i]) {
clear_tsk_debug_counter--;
pos = i;
}
}
if (pos >= 0)
__unregister_user_hw_breakpoint(pos, tsk);
if (!clear_tsk_debug_counter)
clear_tsk_thread_flag(tsk, TIF_DEBUG);
spin_unlock_bh(&hw_breakpoint_lock);
}
It needs modification in the generic HW Breakpoint code. I'm planning to
submit this as a patch over the earlier patchset (after it is pulled
into -tip tree).
> > > > +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;
> > > > + int cpu, stepped, is_kernel;
> > > > +
> > > > + /* Disable breakpoints during exception handling */
> > > > + set_dabr(0);
> > > > +
> > > > + dar = regs->dar & (~HW_BREAKPOINT_ALIGN);
> > > > + is_kernel = (dar >= TASK_SIZE) ? 1 : 0;
> > >
> > > is_kernel_addr() ?
> > >
> >
> > Ok.
>
> Shouldn't this test hbp_kernel_pos instead?
>
Testing hbp_kernel_pos should be sufficient for PPC64 with just one
breakpoint register. However the above code is more extensible to other
PowerPC implementations which have more than one breakpoint register.
> > > > + if (is_kernel)
> > > > + bp = hbp_kernel[0];
> > > > + else {
> > > > + bp = current->thread.hbp[0];
> > > > + /* Lazy debug register switching */
> > > > + if (!bp)
> > > > + return rc;
>
> Shouldn't this test be moved outside the "if" statement, as in the x86
> code?
>
Yes, I will do it. Another error here is the return code when exception
is raised from user-space address due to lazy debug register switching.
The return code should be NOTIFY_STOP (and not NOTIFY_DONE) since the
exception is a stray one and we don't want it to be propogated as a
signal to user-space. This change is required in both x86 and PPC64. I
will submit the x86 change as a separate patch.
> Alan Stern
>
Thanks,
K.Prasad
next prev parent reply other threads:[~2009-05-18 16:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090514133312.360702378@prasadkr_t60p.in.ibm.com>
2009-05-14 13:43 ` [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure K.Prasad
2009-05-18 3:35 ` Benjamin Herrenschmidt
2009-05-18 16:15 ` K.Prasad
2009-05-14 13:44 ` [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces K.Prasad
2009-05-14 14:50 ` Michael Ellerman
2009-05-14 19:50 ` [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces K.Prasad
2009-05-14 20:20 ` Alan Stern
2009-05-18 16:10 ` K.Prasad [this message]
2009-05-18 16:30 ` Alan Stern
2009-05-21 7:15 ` K.Prasad
2009-05-14 13:45 ` [RFC Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces K.Prasad
2009-05-14 13:45 ` [RFC Patch 4/6] Modify process handling code to handle hardware debug registers K.Prasad
2009-05-14 14:54 ` Michael Ellerman
2009-05-14 13:45 ` [RFC Patch 5/6] Modify Data storage exception code to recognise DABR match first K.Prasad
2009-05-14 13:46 ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage K.Prasad
2009-05-14 13:59 ` Geert Uytterhoeven
2009-05-14 14:11 ` Michael Ellerman
2009-05-14 14:18 ` Geert Uytterhoeven
2009-05-14 14:55 ` Michael Ellerman
2009-05-14 19:15 ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64hardware " K.Prasad
2009-05-14 20:21 ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware " Alan Stern
2009-05-18 16:11 ` [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64hardware " K.Prasad
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=20090518161055.GA27641@in.ibm.com \
--to=prasad@linux.vnet.ibm.com \
--cc=benh@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.