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]
Message-ID: <4FC787D8.4010904@hitachi.com>
Date:	Fri, 01 Jun 2012 00:01:44 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	yrl.pp-manager.tt@...achi.com
Subject: Re: Re: [RFC PATCH -tip  0/9]ftrace, kprobes: Ftrace-based kprobe
 optimization

(2012/05/30 20:39), Steven Rostedt wrote:
> On Wed, 2012-05-30 at 15:59 +0900, Masami Hiramatsu wrote:
> 
>> Hmm, I'm not so sure how the notrace and filter works.
>> What happens if I set a foo function-entry on filter
>> and keep notrace empty?
>>  - only foo's nop is replaced with call?
>>  - or all functions including foo is traced?
> 
> From Documentation/trace/ftrace.txt:
> 
> "If a function exists in both set_ftrace_filter
>  and set_ftrace_notrace, the function will _not_ be traced."
> 
> The filters work exactly the same. If notrace always take precedence
> over filter. If you have foo and bar in filter, and put foo in notrace,
> then only bar is traced.
> 
> "filter" means "limit tracing only to these functions"
> "notrace" means "do not trace this function"
> 
> Think of 'filter' as a way of making the 'available_filter_functions'
> smaller. It filters the list. But 'notrace' is just like adding a
> 'notrace' tag. It stops it from being traced regardless.

OK, that's same as what I expected. In that case,
all __kprobes functions are already filtered out
by kprobes itself. So we don't need to set that anymore.

Hmm, CFLAGS_REMOVE_kprobes.o can also keep kprobes from
function tracer. So I'd like to try to use that instead
of including notrace into __kprobes.
However, in that case, kprobe users must remove -pg from
their kernel modules too, and take care that they must
call only notrace kernel APIs...

Perhaps, we'd better introduce new kprobe flag which allow
kprobe to accept new probe on ftrace, so that user can
explicitly understand what he will do.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ