[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1263562684.4244.419.camel@laptop>
Date: Fri, 15 Jan 2010 14:38:04 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc: Jim Keniston <jkenisto@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
utrace-devel <utrace-devel@...hat.com>,
Mark Wielaard <mjw@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Masami Hiramatsu <mhiramat@...hat.com>,
Maneesh Soni <maneesh@...ibm.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation
On Fri, 2010-01-15 at 14:16 +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 18:38 +0530, Srikar Dronamraju wrote:
> > * Peter Zijlstra <peterz@...radead.org> [2010-01-15 11:33:27]:
> >
> > >
> > > > Uprobes layer would need to be notified of process life-time events
> > > > like fork/clone/exec/exit.
> > >
> > > No so much the process lifetimes as the vma life times are interesting,
> > > placing a hook in the vm code to track that isn't too hard,
> > >
> > > > It also needs to know
> > > > - when a breakpoint is hit
> > > > - stop and resume a thread.
> > >
> > > A simple hook in the trap code is done quickly enough, and no reason to
> > > stop the thread, its not going anywhere when it traps.
> > >
> > >
> >
> > Some of the threads could be executing in the vicinity of the
> > breakpoint when it is getting inserted or deleted. Wont we need to
> > stop/quiesce those threads?
>
> The easy answer it so use kstopmachine to patch the code, the slightly
> more complex would be using something like:
>
> http://lkml.org/lkml/2010/1/12/300
Also, since its userspace, can't you simply play games with the
pagetables? CoW a new private copy of the page and flip the pagetables
around to the new one, then flush the pagetables on all relevant cpus
and bob's your uncle.
(You might have to play some games with making the page RO to trap
intermediate accesses, but that should work I think)
--
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