This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hitachi djprobe mechanism


* Keshavamurthy, Anil S (anil.s.keshavamurthy@intel.com) wrote:
> Andi and others,
> 	Sending an IPI to each other CPU's (all but self) and make *spin
> on a lock* during the modification will *freeze* the system. Please do
> not *spin* inside an IPI.
> 
> My observation:
> Here is what I had discovered, CPU2 had taken an
> read_lock(&tasklist_lock) and CPU had entered IPI and is now busy *spin
> on a lock*.
> CPU3 had called write_lock_irq(&tasklist_lock) where CPU3 first disables
> the local irq and disables preemption and then is trying to 
> acquire the lock which is already taken by CPU2 and since CPU2 never
> releases this lock as it is busy spin wait, CPU3 never enters IPI :-(
> 

Yep, I see the problem : you cannot control other locks that would have been
taken by other CPUs with interrupts disabled.

Is there any way to send a non-maskable IPI ? This could solve this problem.


Mathieu

> Cheers,
> -Anil
> 
> 
> 
> 
> 
> >-----Original Message-----
> >From: systemtap-owner@sources.redhat.com 
> >[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Andi Kleen
> >Sent: Monday, August 01, 2005 8:38 AM
> >To: Mathieu Desnoyers
> >Cc: Andi Kleen; Karim Yaghmour; Masami Hiramatsu; Masami 
> >Hiramatsu; Roland McGrath; Richard J Moore; 
> >systemtap@sources.redhat.com; sugita@sdl.hitachi.co.jp; 
> >Satoshi Oshima; michel.dagenais@polymtl.ca
> >Subject: Re: Hitachi djprobe mechanism
> >
> >On Sun, Jul 31, 2005 at 06:59:41PM -0400, Mathieu Desnoyers wrote:
> >> * Andi Kleen (ak@suse.de) wrote:
> >> > 
> >> > One way would be to just search the task list for any 
> >tasks blocked with an IP
> >> > inside the patched region. If yes rewait for another 
> >quiescent period.
> >> > 
> >> > 
> >> 
> >> If you stop other cpus'scheduler when you do that, then it's ok.
> >
> >You don't need to stop them, a snapshot of the task list is enough
> >since you only care about preempted sleeping processes at a single 
> >point of time.
> >
> >Anyways, this discussion is theoretic because the IPI approach
> >is probably better.
> >
> >> 
> >> I just though about an interesting way to implement the IPI, 
> >which would work
> >> very well (and safely) for any case where the instruction to 
> >overwrite is >= 5
> >> bytes. The idea :
> >> 
> >> - Send IPI to each other cpu
> >>   IP args : * address we plan to write to
> >>             * the new instruction we plan to write
> >>   (The IPI handler could then make an infinite loop, reading 
> >the address,
> >>   waiting for it to contain the new instruction.)
> >
> >Seems far too complicated, just make it spin on a lock during 
> >the modification.
> >
> >
> >-Andi
> >
> 
OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]