From: Prasanna S Panchamukhi <prasanna@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: ak@suse.de, davem@davemloft.net, suparna@in.ibm.com,
richardj_moore@uk.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [3/3 PATCH] Kprobes: User space probes support- single stepping out-of-line
Date: Tue, 21 Mar 2006 07:32:57 +0530 [thread overview]
Message-ID: <20060321020257.GB3320@in.ibm.com> (raw)
In-Reply-To: <20060320124049.62861819.akpm@osdl.org>
On Mon, Mar 20, 2006 at 12:40:49PM -0800, Andrew Morton wrote:
> Prasanna S Panchamukhi <prasanna@in.ibm.com> wrote:
> >
> > > > +
> > > > + if (__copy_to_user_inatomic((unsigned long *)addr,
> > > > + (unsigned long *)uprobe->kp.ainsn.insn, size))
> > > > + return -EFAULT;
> > > > +
> > > > + regs->eip = addr;
> > > > +
> > > > + return 0;
> > > > +}
> > >
> > > If we're going to use __copy_to_user_inatomic() then we'll need some nice
> > > comments explaining why this is happening.
> > >
> > > And we'll need to actually *be* in-atomic. That means we need an
> > > open-coded inc_preempt_count() and dec_preempt_count() in there and I don't
> > > see them.
> > >
> >
> > We come here, after probe is hit, through uporbe_handler() with
> > interrupts disabled (since it is a interrupt gate). In uprobe_handler()
> > preemption is disabled and remains disabled until original instruction
> > is single stepped.
> >
> > I will add proper comments in next iteration.
>
> preempt_disable() is insufficient - it is a no-op on !CONFIG_PREEMPT.
>
> You _must_ run inc_preempt_count(). See how kmap_atomic() and
> kunmap_atomic() work.
>
Yes, I will use inc_preempt_count() instead of preempt_disable().
> > > > + */
> > > > +void __kprobes replace_original_insn(struct uprobe *uprobe,
> > > > + struct pt_regs *regs, kprobe_opcode_t opcode)
> > > > +{
> > > > + kprobe_opcode_t *addr;
> > > > + struct page *page;
> > > > +
> > > > + page = find_get_page(uprobe->inode->i_mapping,
> > > > + uprobe->offset >> PAGE_CACHE_SHIFT);
> > > > + BUG_ON(!page);
> > > > +
> > > > + __lock_page(page);
> > >
> > > Whoa. Why is __lock_page() being used here? It looks like a bug is being
> > > covered up.
> > >
> >
> > we come here with a spinlock held. I will add the comment.
>
> Then the code is buggy. __lock_page() can schedule away, causing this CPU
> to recur onto the same lock and deadlock.
Agreed. I will look at this issue and remove the __lock_page().
>
> > > > + addr = (kprobe_opcode_t *)kmap_atomic(page, KM_USER1);
> > > > + addr = (kprobe_opcode_t *)((unsigned long)addr +
> > > > + (unsigned long)(uprobe->offset & ~PAGE_MASK));
> > > > + *addr = opcode;
> > > > + /*TODO: flush vma ? */
> > >
> > > flush_dcache_page() would be needed.
> > >
> > > But then, what happens if the page is shared by other processes? Do they
> > > all start taking debug traps?
> >
> > Yes, you are right. I think single stepping inline was a bad idea, disarming
> > the probe looks to be a better option
> >
>
> You skipped my second question?
There is a small window in which other processor will not be able to see
the breakpoint if we are single step inline. But since single stepping inline
is a bad idea, we will disarm the probe forever (replace with original instrcution) if we cannot single step out-of-line.
Any suggestions?
Thanks
Prasanna
--
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Email: prasanna@in.ibm.com
Ph: 91-80-51776329
next prev parent reply other threads:[~2006-03-21 9:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 6:07 [0/3] Kprobes: User space probes support Prasanna S Panchamukhi
2006-03-20 6:09 ` [1/3 PATCH] Kprobes: User space probes support- base interface Prasanna S Panchamukhi
2006-03-20 6:10 ` [2/3 PATCH] Kprobes: User space probes support- readpage hooks Prasanna S Panchamukhi
2006-03-20 6:11 ` [3/3 PATCH] Kprobes: User space probes support- single stepping out-of-line Prasanna S Panchamukhi
2006-03-20 11:09 ` Andrew Morton
2006-03-20 11:24 ` Arjan van de Ven
2006-03-20 14:05 ` Prasanna S Panchamukhi
2006-03-20 14:13 ` Arjan van de Ven
2006-03-20 11:32 ` Nick Piggin
2006-03-20 13:52 ` Prasanna S Panchamukhi
2006-03-20 13:48 ` Prasanna S Panchamukhi
2006-03-20 20:40 ` Andrew Morton
2006-03-21 2:02 ` Prasanna S Panchamukhi [this message]
2006-03-21 10:05 ` Andrew Morton
2006-03-21 11:05 ` Richard J Moore
2006-03-21 11:13 ` Suparna Bhattacharya
2006-03-21 12:23 ` Prasanna S Panchamukhi
2006-03-20 10:53 ` [2/3 PATCH] Kprobes: User space probes support- readpage hooks Andrew Morton
2006-03-20 13:48 ` Prasanna S Panchamukhi
2006-03-21 2:12 ` Andrew Morton
2006-03-21 9:14 ` Richard J Moore
2006-03-21 11:14 ` Christoph Hellwig
2006-03-21 11:38 ` Richard J Moore
2006-03-21 12:40 ` Theodore Ts'o
2006-03-21 11:28 ` Christoph Hellwig
2006-03-21 11:42 ` Richard J Moore
2006-03-21 12:15 ` Christoph Hellwig
2006-03-21 16:17 ` Richard J Moore
2006-03-20 11:10 ` Andrew Morton
2006-03-20 13:59 ` Prasanna S Panchamukhi
2006-03-20 10:42 ` [1/3 PATCH] Kprobes: User space probes support- base interface Andrew Morton
2006-03-20 13:48 ` Prasanna S Panchamukhi
2006-03-21 11:39 ` [0/3] Kprobes: User space probes support Christoph Hellwig
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=20060321020257.GB3320@in.ibm.com \
--to=prasanna@in.ibm.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=richardj_moore@uk.ibm.com \
--cc=suparna@in.ibm.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
all inboxes | Powered by JetHome®