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

["K.Prasad" <prasad@linux.vnet.ibm.com>]

On Mon, Dec 14, 2009 at 11:26:26AM -0800, Roland McGrath wrote:
<snipped>
> I understand the reason for using stepping.  (I have advised in the past
> that I thought this magical implicit step logic was too hairy to roll in
> under the covers and that a low-level facility expressing the different
> hardware semantics to a kernel API would be OK.  I do agree with the
> motivation of cross-arch uniformity of the semantics.  I don't object to
> making it magically right--I just expressed general skepticism/fear about
> getting that right so that I didn't want to try writing that magic.  Now
> I'm just responding about the particular details I've noticed about that
> can of worms.  It's certainly great if you can resolve all that.  But I'll
> note that I am still by no means confident that the details I have raised
> cover all the worms in that can.)
> 
> What remains less than clear is how preemption relates.  For any per-thread
> hw_breakpoint, there is no high-level reason to care one way or the other.
> The thread, its HW breakpoints, its register state including state of
> stepping, are all part of per-thread state and no reason to do any less (or
> more) preemption than normally happens.
> 

I get that reasoning now...I'd been unduly worried about pre-emption
and hence the introduction of pre-emption disabled state.

But of course, in the existing design, the per-cpu variables would be
affected because if pre-emption was to occur. I'll see how that can be
factored in, while retaining the abstraction provided by the interfaces.

> > Disabling pre-emption is necessary to ensure that hw-breakpoints are
> > enabled immediately after the causative instruction has finished
> > execution (the control flow may go astray if pre-emption occurs between
> > i1 and i2).
> 
> I don't understand what "go astray" means here.  The only thing I can think
> of is the effect on any per-cpu variables you are using in hw_breakpoint
> implementation.
> 

As stated above, I was worried about a pre-emption happening between a
return from breakpoint exception handler and the execution of the
causative instruction....but as I learn, it seems fine now. It is just that
the kernel code needs to be tweaked keeping this in mind.

Thanks,
K.Prasad