linux-kernel - Re: [PATCH v6 7/8] x86: patch all traced function calls using the int3-based framework

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]

Message-ID: <20140123111018.5cb064e4@gandalf.local.home>
Date:	Thu, 23 Jan 2014 11:10:18 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Petr Mladek <pmladek@...e.cz>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH v6 7/8] x86: patch all traced function calls using the
 int3-based framework

On Thu, 23 Jan 2014 15:21:42 +0100
Petr Mladek <pmladek@...e.cz> wrote:

> It means that the slowness caused by tracing "text_poke*" stuff is
> comparable with the slowness caused by "run_sync()". It might mean that
> "text_poke_bp_list" is not worth the added complexity.

I'm starting to think it's fine keeping ftrace and text_poke separate.
Ftrace is rather the NMI of text modification. It's extremely invasive
and has more corner cases than anything else. I rather not complicate
the more generic text_poke just to satisfy ftrace. Perhaps if it was
not such an arch specific change it may be worth it. As these only have
to deal with x86, and the only rational in doing it is to get ftrace to
use text_poke() (one code base for all), I think we can drop it.

Having them separate isn't that bad either, as both get heavy testing
as they both are used in normal development.

> 
> Well, the iterator-based implementation is complex but still faster.
> Also the many sync calls might be more painful for a busy system that
> heavy use of the int3 handler. So, "text_poke_bp_list" still might be
> useful.

That said, I'm sure text_poke can use some clean ups. That would be
nice as well. I think batch processing with the list may be more useful
for things like kprobes and jump labels.

-- Steve

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