[lkml]   [2013]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/1] uprobes: Teach handler_chain() to filter out the probed task
On 01/08, Srikar Dronamraju wrote:
> * Oleg Nesterov <> [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


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

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


 \ /
  Last update: 2013-01-08 20:41    [W:0.081 / U:5.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site