From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23002 invoked by alias); 6 Feb 2008 12:52:27 -0000 Received: (qmail 22995 invoked by uid 22791); 6 Feb 2008 12:52:26 -0000 X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_31,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Feb 2008 12:52:09 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m16Cq7Vg020903; Wed, 6 Feb 2008 07:52:07 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m16Cq5E7010078; Wed, 6 Feb 2008 07:52:05 -0500 Received: from [10.13.248.71] (vpn-248-71.boston.redhat.com [10.13.248.71]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m16Cplcs014233; Wed, 6 Feb 2008 07:51:48 -0500 Message-ID: <47A9AD63.6060200@redhat.com> Date: Wed, 06 Feb 2008 12:52:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: "Luck, Tony" CC: Ananth N Mavinakayanahalli , Jim Keniston , "Li, Shaohua" , LKML , ia64 , systemtap-ml Subject: Re: [RFC][PATCH] kprobes: kprobe-booster for ia64 References: <47A8E995.1090400@redhat.com> <1FE6DD409037234FAB833C420AA843EC84804C@orsmsx424.amr.corp.intel.com> In-Reply-To: <1FE6DD409037234FAB833C420AA843EC84804C@orsmsx424.amr.corp.intel.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00220.txt.bz2 Hello Tony, Thank you for review. Luck, Tony wrote: > +/* Insert a long branch code */ > +static void __kprobes set_brl_inst(void *from, void *to) > +{ > + s64 rel = ((s64) to - (s64) from) >> 4; > + bundle_t *brl; > + brl = (bundle_t *) ((u64) from & ~0xf); > + brl->quad0.template = 0x05; /* [MLX](stop) */ > + brl->quad0.slot0 = NOP_M_INST; /* nop.m 0x0 */ > + brl->quad0.slot1_p0 = ((rel >> 20) & 0x7fffffffff) << 2; > + brl->quad1.slot1_p1 = (((rel >> 20) & 0x7fffffffff) << 2) >> (64 - 46); > + /* brl.cond.sptk.many.clr rel<<4 (qp=0) */ > + brl->quad1.slot2 = BRL_INST(rel >> 59, rel & 0xfffff); > +} > > Is this function operating directly on the instruction bundle in the > kernel code? If so, the bundle will contain some "interesting" > intermediate values as each of the "brl->xxx = yyy;" are processed. > If another cpu should try to execute this bundle while the modifications > are in progress, then the results will be not what you want. No, this function writes brl on kprobe's instruction buffer (kprobe.ainsn.insn->bundle[1]) when preparing the kprobe. So, other cpu never execute it, and we don't need to write it atomically. > On cpu models that support st16 you could construct the brl instruction > and use a single st16 to update the whole bundle atomically. > > -Tony Thank you again, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com