[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1263594471.5007.57.camel@localhost.localdomain>
Date: Fri, 15 Jan 2010 14:27:51 -0800
From: Jim Keniston <jkenisto@...ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: maneesh@...ibm.com, Srikar Dronamraju <srikar@...ux.vnet.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>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation
On Fri, 2010-01-15 at 12:18 +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 12:12 +0100, Peter Zijlstra wrote:
...
> >
> > Adding the probe uses the fact that (most) executable mappings are
> > MAP_PRIVATE and CoWs a private copy of the page with the modified ins,
> > right?
We've just used access_process_vm() to insert the breakpoint
instruction. (If there are situations where that's not appropriate,
please advise.)
>
> Does it clean up the CoW'ed page on removing the probe?
If I understand your question, the answer is no. We make no attempt to
reclaim COW'ed pages, even after all the probes have been removed. In
fact, once the first probe is hit and the XOL vma is created, the XOL
vma hangs around for the life of the process.
> Does that
> account for userspace having made other changes in between installing
> and removing the probe (for PROT_WRITE mappings obviously)?
We don't attempt the aforementioned cleanup, so I think the answer is
"N/A."
Jim
--
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