From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8204 invoked by alias); 28 Jul 2005 23:53:19 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 8185 invoked by uid 22791); 28 Jul 2005 23:53:13 -0000 In-Reply-To: <20050728133456.A32210@unix-os.sc.intel.com> Subject: Re: Hitachi djprobe mechanism Sensitivity: To: Keshavamurthy Anil S Cc: Keshavamurthy Anil S , Mathieu Desnoyers , Masami Hiramatsu , Karim Yaghmour , Masami Hiramatsu , michel.dagenais@polymtl.ca, Roland McGrath , Satoshi Oshima , sugita@sdl.hitachi.co.jp, systemtap@sources.redhat.com X-Mailer: Lotus Notes Release 6.5.1IBM February 19, 2004 Message-ID: From: Richard J Moore Date: Thu, 28 Jul 2005 23:53:00 -0000 X-MIMETrack: Serialize by Router on D06MC062/06/M/IBM(Release 6.53HF247 | January 6, 2005) at 29/07/2005 00:53:08 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2005-q3/txt/msg00151.txt.bz2 There are more efficient ways of implementing a jmp type hook - see the kernel hooks package, where we evloved past this string of 5 no-ops implementation Here we moved an immediate value - 1 byte - into a reg and jumped on the reg being non-zero. To spring the hook we stored the one immediate byte in the mov instruction. This technique works quite well on IA64 where one can use a predicate register for the same purpose. - - Richard J Moore IBM Advanced Linux Response Team - Linux Technology Centre MOBEX: 264807; Mobile (+44) (0)7739-875237 Office: (+44) (0)1962-817072 Keshavamurthy Anil S cc 28/07/2005 Keshavamurthy Anil S 21:34 , Karim Yaghmour , Masami Hiramatsu Please respond , Masami to Hiramatsu Keshavamurthy , Roland Anil S McGrath , Richard J Moore/UK/IBM@IBMGB, systemtap@sources.redhat.com, sugita@sdl.hitachi.co.jp, Satoshi Oshima , michel.dagenais@polymtl.ca bcc Subject Re: Hitachi djprobe mechanism On Thu, Jul 28, 2005 at 02:32:36PM -0400, Mathieu Desnoyers wrote: > 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. Ah..I see you point now. > > 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. If we are not spinning in IPI then I am fine. > > Or did I miss something ? However I have one more issues to mentioni(for discussion sake), when we have several nop instructions(may be 4 nop instruction) in a landing zone, we have no guarantee that all of these nop instructions are with in a page boundary. This is very important because when you replace these instruction with a 5 byte jump instruction, this 5 byte jump instruction should be with in a page boundary else the processor will generate unaligned instruction access voilation or it might generate page fault while trying to execute an instruction which is a very bad thing. How are we going to address this issues? Thanks, Anil