From: "Zhang, Yanmin" <yanmin.zhang@intel.com>
To: <prasanna@in.ibm.com>
Cc: <systemtap@sources.redhat.com>
Subject: RE: [3/3] Userspace probes prototype-take2
Date: Mon, 20 Feb 2006 05:48:00 -0000 [thread overview]
Message-ID: <99FA2ED298A9834DB1BF5DE8BDBF24132B538C@pdsmsx403> (raw)
>>-----Original Message-----
>>From: Prasanna S Panchamukhi [mailto:prasanna@in.ibm.com]
>>Sent: 2006年2月20日 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 processing. 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 probes.
[YM] This approach looks not good. Another issue if doing so is that the single-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 single-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
next reply other threads:[~2006-02-20 5:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-20 5:48 Zhang, Yanmin [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-20 5:48 Zhang, Yanmin
2006-02-20 3:32 Zhang, Yanmin
2006-02-20 5:07 ` Prasanna S Panchamukhi
2006-02-20 3:16 Zhang, Yanmin
2006-02-20 4:51 ` Prasanna S Panchamukhi
2006-02-17 9:19 Zhang, Yanmin
2006-02-20 5:36 ` Prasanna S Panchamukhi
2006-02-08 14:10 [1/3] " Prasanna S Panchamukhi
2006-02-08 14:12 ` [2/3] " Prasanna S Panchamukhi
2006-02-08 14:13 ` [3/3] " Prasanna S Panchamukhi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99FA2ED298A9834DB1BF5DE8BDBF24132B538C@pdsmsx403 \
--to=yanmin.zhang@intel.com \
--cc=prasanna@in.ibm.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).