From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21957 invoked by alias); 6 Jan 2006 05:22:17 -0000 Received: (qmail 21948 invoked by uid 22791); 6 Jan 2006 05:22:16 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,BAYES_05,DNS_FROM_RFC_POST X-Spam-Check-By: sourceware.org Received: from fmr19.intel.com (HELO orsfmr004.jf.intel.com) (134.134.136.18) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 05:22:15 +0000 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k065MAPp032719; Fri, 6 Jan 2006 05:22:10 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k065M34Q029825; Fri, 6 Jan 2006 05:22:09 GMT Received: from pdsmsx331.ccr.corp.intel.com ([172.16.12.58]) by pdsmsxvs01.pd.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006010613220912038 ; Fri, 06 Jan 2006 13:22:09 +0800 Received: from pdsmsx404.ccr.corp.intel.com ([172.16.12.64]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Jan 2006 13:22:09 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Subject: RE: Review patches of user space kprobe Date: Fri, 06 Jan 2006 05:22:00 -0000 Message-ID: <8126E4F969BA254AB43EA03C59F44E840464C384@pdsmsx404> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review patches of user space kprobe Thread-Index: AcYR4zJOr6dukyBzRymXh7tj+BeBDQAmxKWw From: "Zhang, Yanmin" To: Cc: , "Keshavamurthy, Anil S" , "Mao, Bibo" X-OriginalArrivalTime: 06 Jan 2006 05:22:09.0181 (UTC) FILETIME=[2410F4D0:01C61281] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00027.txt.bz2 >>-----Original Message----- >>From: Prasanna S Panchamukhi [mailto:prasanna@in.ibm.com] >>Sent: 2006=C4=EA1=D4=C25=C8=D5 18:33 >>To: Zhang, Yanmin >>Cc: systemtap@sources.redhat.com; Keshavamurthy, Anil S; Mao, Bibo >>Subject: Re: Review patches of user space kprobe >> >> >>>General question: >>>1) How to insert an uprobe at anonymous page (VMA)? I think there are 2 = =3D >>>cases related to the question. >>> a) Many applications execute codes produced themselves, such like JIT = =3D >>>(Just-In-Time) of JVM. >> >>At present we do not support it, need to look into such a case. >> >>> b) Some executables include TEXTREL section. When they are loaded into = =3D >>>memory and linked dynamically, the text section might be changed, and =3D >>>kernel will do a Copy-On-Write to create a new anonymous page and map =3D >>>the new page to the process address space. So after the process starts, = =3D >>>we couldn't insert uprobe on its copied pages. >>>Should a new interface be added to support it? The parameters could be = =3D >>>process id and offset in the process address space. Of course, it could = =3D >>>be an enhancement and implemented later. >> >>User space probes support insertion of probes on dynamically linked libra= ries >>and even probes can be inserted on the text pages that are not even loaded >>into the memory. It doesn't resolve case b).=20 >> >>>3) Can function register_userspace_probe do not call register_kprobe? I = =3D >>>think it's not necessary. It's just my feeling. It's up to you to make = =3D >>>decision. :) >> >>register_kprobe already does most of what userspace probe registeration n= eeds. Function register_kprobe is not big. Current register_userspace_probe calls= register_kprobe, then register_kprobe calls back to uprobe-specific functi= ons. It looks confusing. Why not to just bypass register_kprobe? >> >>>2) Function get_inode_ops should take care of errors and its caller, =3D >>>register_userspace_probe should check if the return value of =3D >>>get_inode_ops is IS_ERR. If so, the error code should be returned =3D >>>instead of a hard-coded -ENOSYS. >> >>Next patch release will take care of these things. >> >>>>>>+ spin_unlock(&mapping->i_mmap_lock); >>>>>>+ return vma; >>>It's not safe to return vma without lock. There is a race condition. If = =3D >>>vma is released by another thread, kernel might be crazy when this =3D >>>thread tries to access it later. >> >>>If the page is mapped to many vma in different processes, function =3D >>>find_get_vma just returns one vma. It's not enough. >>>I'd like to suggest to do the flush_icache in the vma_prio_tree_foreach = =3D >>>loop. >> >>could you please elaborate this. Under smp environment, if a page (inode,offset) is mapped to the address sp= aces of many processes, then when a uprobe is registered on the page, uprob= e->vma is just point to one of them. Then, insert_kprobe_user=3D>arch_arm_u= probe=3D>flush_icache_user_range, only this vma (or address space) is flush= ed.