linux-kernel - Re: [PATCH -tip v3&10 02/18] kprobes: Introduce generic insn

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:	Tue, 2 Mar 2010 19:32:07 -0500
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	systemtap <systemtap@...rces.redhat.com>,
	DLE <dle-develop@...ts.sourceforge.net>,
	Jim Keniston <jkenisto@...ibm.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Anders Kaseorg <andersk@...lice.com>,
	Tim Abbott <tabbott@...lice.com>,
	Andi Kleen <andi@...stfloor.org>,
	Jason Baron <jbaron@...hat.com>
Subject: Re: [PATCH -tip v3&10 02/18] kprobes: Introduce generic insn_slot
	framework

* Masami Hiramatsu (mhiramat@...hat.com) wrote:
> Masami Hiramatsu wrote:
> > Mathieu Desnoyers wrote:
> >> * Masami Hiramatsu (mhiramat@...hat.com) wrote:
> >>> Make insn_slot framework support various size slots.
> >>> Current insn_slot just supports one-size instruction buffer slot. However,
> >>> kprobes jump optimization needs larger size buffers.
> >>
> >> OK, so you end up having one insn slot cache for kprobes and one insn
> >> slot (eventually) for the static jump patching (which needs larger
> >> instruction slots than kprobes). That seems like a good way to ensure
> >> you do not use more memory than necessary.
> >>
> >> We could possibly go even further and automatically use the right insn
> >> slot cache given the size of the instruction entry that must be added (a
> >> bit like the memory allocator which have different pools for each
> >> allocation order).
> > 
> > Sure, that will be simpler interface.
> > 
> >> Possibly that using the terminology of "memory pools" rather than
> >> "cache" could be a better fit too. So what this really becomes is an
> >> instruction slot allocator and garbage collector.
> > 
> > Ah, right. It would be better to rename kprobe_insn_pool() :)
> 
> Hmm, I tried it. And finally, I found that this doesn't help
> to simplify code... Maybe it is better to postpone it until
> another user needs this feature.

I guess it's a tradeoff between the genericity of the API you provide
and the complexity of the code that provides this API. So as you say,
maybe it's better to wait until more users appears before improving the
API.

Thanks,

Mathieu

> 
> Thank you,
> 
> -- 
> Masami Hiramatsu
> e-mail: mhiramat@...hat.com
> 

-- 
Mathieu Desnoyers
Operating System Efficiency Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/