linux-kernel - Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocation for Execution out of line(XOL)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Sep 2010 23:29:57 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 3/15]  3: uprobes: Slot allocation
 for Execution out of line(XOL)

> > > An alternative method would be to have 1 slot per cpu, and manage the
> > > slot content using preemption notifiers. That gives you a fixed number
> > > of slots and an unlimited number of probe points.
> > > 
> > > If the preemption happens to be a migration you need to rewrite the
> > > userspace IP to point to the new slot -- if indeed the task was inside
> > > one when it got preempted -- but that all should be doable.
> > > 
> > 
> > 3. Yes migration is an issue esp
> > -  if a thread of the same process that hit a breakpoint is scheduled into the same cpu and that newly scheduled thread hits a breakpoint. 
> > - Something similar can happen if a multithreaded process runs on a
> >   uniprocessor machine.
> 
> > 5. I think we are covered on the cpu hotplug too, (i.e not sure if we have
> > to make uprobes cpu hot plug aware.).
> 
> Not if you use a slot per cpu and use preemption notifiers, the
> preemption notifiers will migrate the slots around.


Lets say the thread while singlestepping the process gets
pre-empted. Eventually the cpu might run some other thread of the same
process before picking the first run thread. Or the first run
thread could after migration due to load balancing or whatever end up
running on  a different thread?  How do we handle these cases? 

> 
> > 6. We would still be allocating a page for the slots. Unless we want
> > to expand to more slots than available in one page, I dont see the
> > disadvantages with the current approach.
> 
> The current approach limits the number of probes to what fits in a page.
> The slot per cpu approach will have no such limit.


yes the limit on number of probes is a limitation. For now the
implementation would be straight and easy. We could either rework on the
algorithm or add more pages depending on how often uprobes gets used.

> > 2  This might complicate booster probe, because the jump
> > instruction that follows the original instruction now actually have to
> > coded every time.
> 
> Why can't you keep the whole replacement sequence in-tact? Simply copy
> it out into the slot each time.

Yes, if we use jump absolute then the replacement sequence stays
in-tact.

--
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/