Re: Hitachi djprobe mechanism

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

* Keshavamurthy Anil S (anil.s.keshavamurthy@intel.com) wrote:
> Your suggestion has several limitations, the moment you replace cli with int3, 
> some thread on some cpu might hit this int3 which needs to be handled 
> and not only that, after this is handled this thread might starts to execute
> nop instruction which is right after int3 and at which point in time this 
> thread might be prempted. Again we end up in the same situation as before.
> 
> Also checking that no other CPU has interrupt disabled using an IPI involves
> tight spining in the IPI callback handler which is prone to deadlock.
> 

The goal of this int3 is indeed that, if another thread on another CPU falls
into it, the int3 handler will change its own return address to fall into the
push instruction, right after the nops.

For the IPI :

- the on_each_cpu should be called from a context where no spinlock is held. The
  context from which it is called could be protected by a flag which would cause
  any concurrent processor to fail if they try to follow the same "code
  alteration" function.
- the IPI handler does not need to spin at all. It just returns. It only has to
  inform us about when interrupt disabled zone has ended. As this zone will not
  be reentered due to the int3 instruction, everything is fine.

Or did I miss something ?


Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68