Re: [PATCH 1/1] uprobes: Teach handler_chain() to filter out the probed task

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

* Oleg Nesterov <oleg@redhat.com> [2013-01-08 20:00:18]:

> On 01/08, Srikar Dronamraju wrote:
> >
> > * Oleg Nesterov <oleg@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.
> 

okay, then looks good.

> 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. 

Okay

> 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 ?
> 
yes, thats what I think they can assume.

> 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.

If we document explicitly that filter wont be called, then this should
be okay.

> 
> > > +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);
> >