linux-kernel - Re: [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches

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] [day] [month] [year] [list]

Date:	Thu, 4 Nov 2010 14:45:56 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 0/15]  0: Uprobes Patches

On Fri, Oct 29, 2010 at 04:18:58PM +0530, Srikar Dronamraju wrote:
> Current issues: Given a vma; finding all tasks that have this vma
> mapped. The current solution seems to walk thro all tasks in the system
> and check if each task's mm field. But this could be inefficient
> especially if the vma is part of all processes like libc etc.

It's pretty much guaranteed to be inefficient, yes.

> I dont think we can use mm->owner to walk thro all the tasks that map to
> this mm_struct.

I don't see a way around that if we have to find the task by the vma.

You'll have to start with vma->vm_mm->owner and then walk the list
of thread siblings inside the heavy weight process.

> Slot allocation delays: Using a per-thread slot instead of a per-probe
> slot leads to a 3.5X degradation in performance. If we need to use
> per-probe slots, we would have to have maintain metadata, i.e the slot
> to virtual address mapping per process. However Peter prefers that we
> reduce such metadata.

The performance numbers are pretty drastic.  But I'll let Peter comment
on the desire in more detail.  I'm really not in enough touch with this
code anymore to give too useful comments.

> >From a perf/ftrace perspective:

I really prefer the new interface.  But as said before I'm just a user
here and I don't care how it's implemented underneath.  I'll defer to
Peter and others knowing the code in more detail to make the trade offs
between the different low level implementations.

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