On 01/08, Srikar Dronamraju wrote:
>
> * Oleg Nesterov <o...@redhat.com> [2012-12-29 18:36:14]:
>
> > This patch does the first step to improve the filtering. handler_chain()
> > removes the breakpoints installed by this uprobe from current->mm if all
> > handlers return UPROBE_HANDLER_REMOVE.
> >
>
> I am thinking of tid based filter, If let say a tracer is just
> interested in a particular thread of a process, should such a hanlder
> always return 0.
In this case ->handler() should return
current->mm == PROBED_THEAD->mm ? 0 : UPROBE_HANDLER_REMOVE
> In general, does this mean if the handler is not interested for this
> particular task, but not sure if other tasks in the same process could
> be interested, then such a handler should always return 0?
Probably yes. Obviously it should return UPROBE_HANDLER_REMOVE only if
it knows for sure that current can't share ->mm with the "interesting"
task.
Because, whatever we do, remove_breakpoint() affects ->mm, not task_struct.
Our goal is eliminate do_int3(), not to skip uc->handler() call.
> If yes, should we document it (either in handler_chain() or
> near uprobe_consumer definition)
Oh yes, I do agree. We need to add some documentation. I'll try to do
this in a separate patch (although I would be happy to see the patch
from someone else ;).
> > Note: instead of checking the retcode from uc->handler, we could add
> > uc->filter(UPROBE_FILTER_BPHIT). But I think this is not optimal to
> > call 2 hooks in a row. This buys nothing, and if handler/filter do
> > something nontrivial they will probably do the same work twice.
>
> I was for having the filter called explicitly. But I am okay with it
> being called internally by the handler.
OK, thanks,
> My only small concern was
>
> - Given that we have an explicit filter, handlers (or folks writing
> handlers can misunderstand and miss filtering assuming that handlers
> would be called after filtering.
Do you mean that they can assume that uc->filter(mm) should be called at
least once before uc->handler() with the same current->mm ?
They shouldn't in any case. To remind, we can optimize filter_chain()
for example and avoid the potentially costly uc->filter() call. Say,
we can detect/remember the fact that at least one consumre has
->filter == NULL.
OTOH, UPROBE_HANDLER_REMOVE is not really pre-filtering (although I think
it helps to make the things better). It is more like uprobe_unapply_mm()
which (perhaps) we need as well. But doing uprobe_unapply_mm() from
uc->handler is a) deadlockable and b) not optimal because it has to
consult other consumers.
Anyway I agree, the folks writing handlers should understand what do they
do ;) and this needs some documentation.
> > +static void handler_chain(struct uprobe *uprobe, struct pt_regs *regs)
> > +{
> > + struct uprobe_consumer *uc;
> > + int remove = UPROBE_HANDLER_REMOVE;
> > +
> > + down_read(&uprobe->register_rwsem);
> > + for (uc = uprobe->consumers; uc; uc = uc->next) {
> > + int rc = uc->handler(uc, regs);
> > +
> > + WARN(rc & ~UPROBE_HANDLER_MASK,
> > + "bad rc=0x%x from %pf()\n", rc, uc->handler);
>
> Is this warning required?
Of course this is not strictly needed, just to catch the simple mistakes.
I can remove it.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
