Message-ID: <20100122070232.GA2975@linux.vnet.ibm.com>
Date:	Fri, 22 Jan 2010 12:32:32 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	utrace-devel <utrace-devel@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Maneesh Soni <maneesh@...ibm.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	Avi Kivity <avi@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Mel Gorman <mel@....ul.ie>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments and
 actions to be taken ]

Here is a summary of the Comments and actions that need to be taken for
the current uprobes patchset. Please let me know if I missed or
misunderstood any of your comments.  

1. Uprobes depends on trap signal.
	Uprobes depends on trap signal rather than hooking to the global
die notifier. It was suggested that we hook to the global die notifier.

	In the next version of patches, Uprobes will use the global die
	notifier and look at the per-task count of the probes in use to
	see if it has to be consumed.

	However this would reduce the ability of uprobe handlers to
	sleep. Since we are dealing with userspace, sleeping in handlers
	would have been a good feature. We are looking at ways to get
	around this limitation.


2. XOL vma vs Emulation vs Single Stepping Inline vs using Protection
Rings.
	XOL VMA is an additional process address vma.  This is
	opposition to add an additional vma without user actually
	requesting for the same.

	XOL vma and single stepping inline are the two architecture
	independent implementations. While other implementations are
	more architecture specific. Single stepping inline wouldnt go
	well with multithreaded process.

	Even though XOL vma has its own issues, we will go with it since
	other implementations seem to have more complications.

	we would look forward to implementing boosters later. 
	Later on, if we come across another techniques with lesser
	side-effects than the XOL vma, we would switch to using them.


3. Current Uprobes looks at process life times and not vma lifetimes. 
Also it needs threads to quiesce when inserting and removing
breakpoints.
	
	Current uprobes was quiesing threads of a process before
	insertion and deletion. This resulted in uprobes having to track
	process lifetimes. An alternative method to track vma lifetimes
	was suggested.

	Next version would update the copy of the page and flip the
	pagetables as suggested by Peter. Hence it would no more depend on
	threads quiescing.

	However this would need hooks in munmap/rmap so that uprobes can
	remove breakpoints that are placed in that vma.
	
	This would also mean removing the rcu_deference we were using.

4. Move the ftrace plugin to use trace events.

	Since ftrace plugins are relegated to obsolescence, it was
	suggested we use trace events which would have much wider scope.	

	Next version will use trace events.

5. rename UBP to user_bkpt

6. updating the authors for all files that are getting added.

I shall work towards v2 of uprobes and send across the patches at the
earliest.

--
Thanks and Regards
Srikar
--
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