This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- Cc: Andi Kleen <ak at suse dot de>, Karim Yaghmour <karim at opersys dot com>, Masami Hiramatsu <masami dot hiramatsu at gmail dot com>, Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>, Roland McGrath <roland at redhat dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, systemtap at sources dot redhat dot com, sugita at sdl dot hitachi dot co dot jp, Satoshi Oshima <soshima at redhat dot com>, michel dot dagenais at polymtl dot ca
- Date: Mon, 1 Aug 2005 12:01:21 -0400
- Subject: Re: Hitachi djprobe mechanism
- References: <44BDAFB888F59F408FAE3CC35AB4704101E98ABB@orsmsx409>
* 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