This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: Hitachi djprobe mechanism
- From: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- To: "Andi Kleen" <ak at suse dot de>, "Mathieu Desnoyers" <compudj at krystal dot dyndns dot org>
- Cc: "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 08:49:23 -0700
- Subject: RE: Hitachi djprobe mechanism
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 :-(
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
>