[Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64

[K.Prasad]

On Tue, Jan 19, 2010 at 02:03:35AM -0800, Roland McGrath wrote:
> > It is also not clear to me if disabling pre-emption for the user-space
> > (albeit for a very tiny time-window) is incorrect and if their side-effects
> > are known. If otherwise, I think we should choose to operate in pre-empt
> > safe mode and avoid all costs associated when done without it.
> 
> I never really gave much consideration to returning to user mode with
> preemption disabled.  It would not really have occurred to me that was
> even possible.  I can't say it seems to me like it could ever be a very
> good idea.  I find it hard even to start listing the cans of worms that
> might be opened by that.  Perhaps the powerpc maintainers have a clearer
> picture of it than I do.
> 
> What does it mean when there is something that prevents it from returning
> to user mode?  i.e., TIF_SIGPENDING or TIF_NEED_RESCHED, or whatever.  It
> could do a lot in the kernel before it gets back to user mode.  What if in
> there somewhere it blocks voluntarily?
> 
> Similarly, what does it mean if you get to user mode but the single-stepped
> instruction is a load/store that gets a page fault?  What if it blocks in
> the page fault handler?
> 
> For that matter, what about a page fault for the kernel-mode case?
> 
> Perhaps I'm imagining gremlins where there aren't any, but I just cannot
> really get my head around this "disable preemption while running some
> unknown instruction that normally runs with preemption enabled" thing--let
> alone "disable preemption while returning to user mode".
> 
> 
> Thanks,
> Roland

I posted a patch which re-enables pre-emption after a hw-breakpoint is
processed (linuxppc-dev ref: 20100121084640.GA3252 at in.ibm.com). It does
lead to clumsiness (due to the new variables to track states, prior
breakpoints, etc.) but with the reasons you pointed out, it is much
better than having uncertain/incorrect code.

Thanks for your comments.
-- K.Prasad