public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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: <99FA2ED298A9834DB1BF5DE8BDBF24132B538E@pdsmsx403> (raw)

>>-----Original Message-----
>>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Prasanna S Panchamukhi
>>Sent: 2006年2月20日 13:38
>>To: Zhang, Yanmin
>>Cc: systemtap@sources.redhat.com
>>Subject: Re: [3/3] Userspace probes prototype-take2
>>
>>Yanmin,
>>
>>
>>Please see my comments inline below.
>>
>>Thanks
>>Prasanna
>>> >>
>>> >>2. This patch works only with PREEMPT config option disabled, to work
>>> >>in PREEMPT enabled condition handlers must be re-written and must
>>> >>be seperated out from kernel probes allowing preemption.
>>> One of my old comments is an external device interrupt might happen when cpu is single-stepping the original instruction, then the
>>task might be switched to another cpu. If we disable irq when exiting to user space to single step the instruction, kernel might switch
>>the task off just on the exit kernel path. 1) uprobe_page; 2) kprobe_ctlblk, These 2 resources shouldn't be pre cpu, or we need get
>>another approach. How could you resolve the task switch issue?
>>
>>My new design does not use the kprobe handlers and per cpu kprobe data
>>structures itself  so that task switch issue will be resolved.
>>We register a separte set of uprobe handlers and use uprobe data structure.
>>Also now we will be handling uprobes serially and synchronize using some lock/mutex, but later on we have scale it up for better performance.
>>
>>> >>+static int __kprobes copy_insn_on_new_page(struct uprobe *uprobe ,
>>> >>+			struct pt_regs *regs, struct vm_area_struct *vma)
>>> >>+{
>>> >>+	unsigned long addr, *vaddr, stack_addr = regs->esp;
>>> >>+	int size = MAX_INSN_SIZE * sizeof(kprobe_opcode_t);
>>> >>+	struct uprobe_page *upage;
>>> >>+	struct page *page;
>>> >>+	pte_t *pte;
>>> >>+
>>> >>+
>>> >>+	if (vma->vm_flags & VM_GROWSDOWN) {
>>> >>+		if (((stack_addr - sizeof(long long))) < (vma->vm_start + size))
>>> >>+			return -ENOMEM;
>>> >>+
>>> >>+		addr = vma->vm_start;
>>> >>+	} else if (vma->vm_flags & VM_GROWSUP) {
>>> >>+		if ((vma->vm_end - size) < (stack_addr + sizeof(long long)))
>>> >>+			return -ENOMEM;
>>> >>+
>>> >>+		addr = vma->vm_end - size;
>>> >>+	} else
>>> >>+		return -EFAULT;
>>> >>+
>>> The multi-thread case is not resolved here. One of typical multi-thread model is that the all threads share the same vma and every
>>thread has 8-k stack.
>>
>>>If 2 threads trigger uprobe (although might be not the same uprobe) at the same time, one thread might erase single-step instruction
>>of another.
>>
>>Do these threads share the same stack pages?
[YM] No. They share the same vma. And copy_insm_onstack might happen to fail on the 2 threads at the same time.

             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=99FA2ED298A9834DB1BF5DE8BDBF24132B538E@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).