From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5995 invoked by alias); 20 Feb 2006 05:48:20 -0000 Received: (qmail 5981 invoked by uid 22791); 20 Feb 2006 05:48:18 -0000 X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from fmr20.intel.com (HELO orsfmr005.jf.intel.com) (134.134.136.19) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Feb 2006 05:48:17 +0000 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.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 k1K5m30E003950; Mon, 20 Feb 2006 05:48:03 GMT Received: from pdsmsxvs01.pd.intel.com (pdsmsxvs01.pd.intel.com [172.16.12.122]) by orsfmr100.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 k1K5lpVp004503; Mon, 20 Feb 2006 05:48:03 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 M2006022013480215677 ; Mon, 20 Feb 2006 13:48:02 +0800 Received: from pdsmsx403.ccr.corp.intel.com ([172.16.12.55]) by pdsmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 13:48:02 +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: [3/3] Userspace probes prototype-take2 Date: Mon, 20 Feb 2006 05:48:00 -0000 Message-ID: <99FA2ED298A9834DB1BF5DE8BDBF24132B538C@pdsmsx403> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [3/3] Userspace probes prototype-take2 thread-index: AcY12VlxALWGK11WQjiIE2WBljOwbAABNcgw From: "Zhang, Yanmin" To: Cc: X-OriginalArrivalTime: 20 Feb 2006 05:48:02.0385 (UTC) FILETIME=[366FD410:01C635E1] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 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/msg00567.txt.bz2 >>-----Original Message----- >>From: Prasanna S Panchamukhi [mailto:prasanna@in.ibm.com] >>Sent: 2006=C4=EA2=D4=C220=C8=D5 12:52 >>To: Zhang, Yanmin >>Cc: systemtap@sources.redhat.com >>Subject: Re: [3/3] Userspace probes prototype-take2 >> >>Yanmin, >> >>On Mon, Feb 20, 2006 at 11:15:31AM +0800, Zhang, Yanmin wrote: >>> I lost an important comment. The patch is not aware of signal processin= g. After kernel prepares the single-step-inst on the stack, >>if a signal is delivered to the thread, kernel will save some states into= stack and switch to signal handler function, so single-step-inst >>on the stack might be erased. >> >>AFAIK this problem can be addressed in the following ways. >> >>1. Leave the sufficient stack space for the kernel to deliver the >>signals and then copy the instructions on the stack. [YM] signal action handler itself could be nested again, so it looks not a = good approach. >> >>2. Synchronize usage of stack between signal processing and user space pr= obes. [YM] This approach looks not good. Another issue if doing so is that the si= ngle-step-insn itself might change esp. >> >>3. Block the signal processing by disabling interrupts and preemption from >>the time we copy the instruction on the stack untill we single step on the >>original instruction. Or even wait for the signal processing to be >>complete and then setup the stack for single stepping on the original >>instructions and single step. [YM] We could do not check signal when exiting from kernel if trying to sin= gle-step. It's easy to be implemented, but community might argue. I prefer = this one. For example, add a new flag, TIF_UPROBING, at thread_info->flags.= And check it at appropriate time. >> >>Your suggestion are welcome to provide better solutions to this problem. >> >>Thanks >>Prasanna