linux-kernel - Re: function_graph selftest fails with !DYNAMIC

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: <1320414269.19219.12.camel@gandalf.stny.rr.com>
Date:	Fri, 04 Nov 2011 09:44:29 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Rabin Vincent <rabin@....in>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: function_graph selftest fails with !DYNAMIC

On Wed, 2011-11-02 at 20:32 +0530, Rabin Vincent wrote:
> The function_graph selftest fails when CONFIG_DYNAMIC_FTRACE is not set
> (tested on x86-64) on current kernels:
> 
> [    0.300124] Testing tracer function: PASSED
> [    0.446092] Testing tracer function_graph: .. no entries found ..FAILED!
> 
> Bisecting goes back to this commit:
> 
> 2b499381bc50ede01b3d8eab164ca2fad00655f0 is the first bad commit

Your bisect is wrong. I ran it though ktest.pl and it gave me this
bisect commit:

commit 6331c28c962561aee59e5a493b7556a4bb585957
Author: Steven Rostedt <srostedt@...hat.com>
Date:   Wed Jul 13 15:11:02 2011 -0400

    ftrace: Fix dynamic selftest failure on some archs


I used the following test config options:

TEST_START IF ${RUN_TYPE} == bisect
TEST_TYPE = bisect
BISECT_GOOD = 2b499381bc50ede01b3d8eab164ca2fad00655f0
BISECT_BAD = b4beb4bf9934d151bf4581a54ae028927374cb2a
BISECT_TYPE = test
TEST = ssh root@bxf /work/bin/test-fgraph
BISECT_CHECK = good
MIN_CONFIG = ${THIS_DIR}/config-bisect
BUILD_NOCLEAN = 1


Where test-fgraph was a simple script:

if dmesg | grep function_graph | grep PASSED; then
	exit 0
else
	exit 1
fi


Looking at this commit I found the bug, and yes I'm quite embarrassed by
it. It happened because I left in a change to test the
!CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST case.


+#undef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
 #ifndef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST


The fact that function graph tracing failed when this was unset was not
a bug in the logic in this case, but because the mcount code in the x86
asm assumes that this is set and will do different things because of the
way the code changes.

The simple fix is:

--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -151,7 +151,6 @@ void clear_ftrace_function(void)
        ftrace_pid_function = ftrace_stub;
 }
 
-#undef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
 #ifndef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
 /*
  * For those archs that do not test ftrace_trace_stop in their


I'll write a formal patch and send it up.

Thanks for reporting!

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