[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131104155131.GD4440@redhat.com>
Date: Mon, 4 Nov 2013 16:51:31 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Namhyung Kim <namhyung.kim@....com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Hyeoncheol Lee <cheol.lee@....com>,
Hemant Kumar <hkshaw@...ux.vnet.ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch
methods (v6)
On 11/04, Namhyung Kim wrote:
> On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
> > On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
> >> - this only allows to read the data from the same binary.
> >
> > Right. This is also an unnecessary restriction. We should be able to
> > access data in other binary.
>
> Hmm.. I guess this gonna be not simple
Yes ;)
- perhaps it can only be
> supported for per-process uprobe with known virtual addresses?
"Known" is very limited. Even in the simplest case (like your test-case
from from 0/13), you simply can't know the address of "int glob" if you
compile it with "-pie -fPIC".
As for other binaries (say libc) the problem is even worse, and
randomize_va_space adds even more pain.
But in any case, I strongly believe that it doesn't make any sense to
rely on tu->inode in get_user_vaddr().
Oleg.
--
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