From: Ingo Molnar <mingo@kernel.org>
To: Anton Arapov <anton@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Christoph Hellwig <hch@infradead.org>,
Josh Stone <jistone@redhat.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] uprobes: pre-filtering
Date: Thu, 24 Jan 2013 13:30:10 +0100 [thread overview]
Message-ID: <20130124123010.GA4755@gmail.com> (raw)
In-Reply-To: <CAMeizLf1XTwaLLE2eBm+XMRQZPgBY=dUkEcpaDYdupB0T3+2Lg@mail.gmail.com>
* Anton Arapov <anton@redhat.com> wrote:
> Hello Ingo,
>
> On Thu, Jan 24, 2013 at 11:17 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Oleg Nesterov <oleg@redhat.com> wrote:
> >
> >> Ingo, please pull from
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core
> >>
> >> Mostly pre-filtering. This needs more work and perhaps more functionality.
> >> In particular, perhaps dup_mmap() should remove the unwanted breakpoints.
> >> And we can add more ->filter() hooks to, say, speedup uprobe_register().
> >> Plus we can do some optimizations to avoid register_for_each_vma() in
> >> case when we know that all mm's were previously acked/nacked.
> >>
> >> Srikar, the only patch you did not ack explicitely is 1fecb96d
> >> "Do not allocate current->utask unnecessary", but afaics you do not
> >> object.
> >>
> >> And the patch from Josh which exports uprobe_register/unregister for modules.
> >> Christoph (cc'ed) doesn't like this change, but I disagree. Whatever you
> >> think about systemtap it is the widely used tool, and uprobes can have other
> >> out-of-tree users. This is like kprobes, kprobe_register() is exported but
> >> it doesn't have a modular in-kernel user too. I do not see why should we
> >> limit the usage of uprobes.
> >>
> >>
> >>
> >> Josh Stone (1):
> >> uprobes: Add exports for module use
> >>
> >> Oleg Nesterov (26):
> >> uprobes: Move __set_bit(UPROBE_SKIP_SSTEP) into alloc_uprobe()
> >> uprobes: Kill the "uprobe != NULL" check in uprobe_unregister()
> >> uprobes: Kill the pointless inode/uc checks in register/unregister
> >> uprobes: Kill uprobe_consumer->filter()
> >> uprobes: Introduce filter_chain()
> >> uprobes: _unregister() should always do register_for_each_vma(false)
> >> uprobes: _register() should always do register_for_each_vma(true)
> >> uprobes: Introduce uprobe->register_rwsem
> >> uprobes: Change filter_chain() to iterate ->consumers list
> >> uprobes: Kill UPROBE_RUN_HANDLER flag
> >> uprobes: Kill uprobe->copy_mutex
> >> uprobes: Kill uprobe_events, use RB_EMPTY_ROOT() instead
> >> uprobes: Introduce uprobe_is_active()
> >> uprobes: Kill uprobes_mutex[], separate alloc_uprobe() and __uprobe_register()
> >> uprobes: Rationalize the usage of filter_chain()
> >> uprobes: Reintroduce uprobe_consumer->filter()
> >> uprobes: Teach handler_chain() to filter out the probed task
> >> uprobes/x86: Change __skip_sstep() to actually skip the whole insn
> >> uprobes: Change handle_swbp() to expose bp_vaddr to handler_chain()
> >> uprobes: Move alloc_page() from xol_add_vma() to xol_alloc_area()
> >> uprobes: Fold xol_alloc_area() into get_xol_area()
> >> uprobes: Turn add_utask() into get_utask()
> >> uprobes: Do not play with utask in xol_get_insn_slot()
> >> uprobes: Fix utask->xol_vaddr leak in pre_ssout()
> >> uprobes: Do not allocate current->utask unnecessary
> >> uprobes: Kill the bogus IS_ERR_VALUE(xol_vaddr) check
> >>
> >> arch/x86/kernel/uprobes.c | 4 +-
> >> include/linux/uprobes.h | 17 ++-
> >> kernel/events/uprobes.c | 433 ++++++++++++++++++++++---------------------
> >> kernel/ptrace.c | 6 +
> >> kernel/trace/trace_uprobe.c | 5 +-
> >> 5 files changed, 243 insertions(+), 222 deletions(-)
> >
> > The kernel side looks good to me - but how does 'perf uprobe'
> > make use of it in practice, how can I test it?
>
> I'm not sure whether you looking into testing specific changes in this
> pull, [...]
Yes, I was curious about specifically testing the filtering
callback changes in this pull request.
Thanks,
Ingo
next prev parent reply other threads:[~2013-01-24 12:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-13 18:59 [GIT PULL] uprobes: pre-filtering Oleg Nesterov
2013-01-24 12:17 ` Ingo Molnar
2013-01-24 12:28 ` Anton Arapov
2013-01-24 12:30 ` Ingo Molnar [this message]
2013-01-24 15:40 ` Oleg Nesterov
2013-01-24 15:41 ` Ingo Molnar
2013-01-24 17:06 ` Oleg Nesterov
2013-01-25 6:46 ` Srikar Dronamraju
2013-01-25 7:54 ` Ingo Molnar
2013-01-25 16:17 ` Oleg Nesterov
2013-01-25 18:46 ` Ingo Molnar
2013-01-25 19:34 ` Oleg Nesterov
2013-01-28 12:19 ` Srikar Dronamraju
2013-01-28 16:04 ` Oleg Nesterov
2013-01-25 11:23 ` Masami Hiramatsu
2013-01-24 17:05 ` Josh Stone
2013-01-24 17:23 ` Oleg Nesterov
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=20130124123010.GA4755@gmail.com \
--to=mingo@kernel.org \
--cc=anton@redhat.com \
--cc=hch@infradead.org \
--cc=jistone@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=srikar@linux.vnet.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.