[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100323152608.GC2975@redhat.com>
Date: Tue, 23 Mar 2010 11:26:08 -0400
From: "Frank Ch. Eigler" <fche@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: ananth@...ibm.com, Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Masami Hiramatsu <mhiramat@...hat.com>,
Mel Gorman <mel@....ul.ie>,
Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Roland McGrath <roland@...hat.com>,
Oleg Nesterov <oleg@...hat.com>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH v1 7/10] Uprobes Implementation
Hi -
> > Now the question is, where the complexity needs to be.
>
> Both in-tree consumers of uprobes (ftrace and perf) are capable of task
> filters. [...]
If you wish this new uprobes to be useful to tools such as gdb,
remember the value of preserving the property that processes not being
debugged are not to be interfered with. You don't want a DoS due to
some guy setting ten thousand breakpoints on glibc. Such
considerations should overrule perf/ftrace's simplifying assumptions
that after-the-fact event filtering is surely always sufficient.
- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists