linux-kernel - Re: ftrace: preemptoff selftest not working

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081118170635.GB4417@osiris.boeblingen.de.ibm.com>
Date:	Tue, 18 Nov 2008 18:06:35 +0100
From:	Heiko Carstens <heiko.carstens@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: ftrace: preemptoff selftest not working

On Tue, Nov 18, 2008 at 03:47:51PM +0100, Ingo Molnar wrote:
> 
> * Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > 
> > On Tue, 18 Nov 2008, Ingo Molnar wrote:
> > > 
> > > * Steven Rostedt <rostedt@...dmis.org> wrote:
> > > 
> > > > > Hence the trace buffer will be empty. The patch below makes the 
> > > > > selftests working for me, since then they run in preemptible 
> > > > > context. But it is ugly and I'm not proposing it for upstream ;)
> > > > > 
> > > > > Just wanted to make you aware that there is a bug.
> > > > 
> > > > Yep, this might be a better answer than what I put into linux-tip 
> > > > (and my git repo).
> > > > 
> > > > See:
> > > > 
> > > >   ftrace: force pass of preemptoff selftest
> > > > 
> > > > The cause of the bug was the conversion of the BKL back to a 
> > > > spinlock, and making it non preempt.  The initcall code is called 
> > > > with the BKL applied which now means it can not preempt. This breaks 
> > > > the preempt tracer selftest.
> > > > 
> > > > My solution was to just force a pass if this is detected. Perhaps 
> > > > moving the test might be better.
> > > 
> > > it would be better to just drop the BKL in that selftest. (or in all 
> > > selftests - an elevated preempt count will skew a number of things)
> > 
> > I have no problem with that, but does the BKL play any role for 
> > being held? I have no idea why it is taken in boot up, so I'm 
> > hestiant to touch it.
> 
> we can drop it in selected initcalls just fine. Its only role is 
> old-style init functions racing with other async contexts of 
> themselves.

Something like below works fine for me...

Signed-off-by: Heiko Carstens <heiko.carstens@...ibm.com>
---

 kernel/trace/trace.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: linux-2.6/kernel/trace/trace.c
===================================================================
--- linux-2.6.orig/kernel/trace/trace.c
+++ linux-2.6/kernel/trace/trace.c
@@ -482,6 +482,13 @@ int register_tracer(struct tracer *type)
 	}
 
 #ifdef CONFIG_FTRACE_STARTUP_TEST
+	/*
+	 * When this gets called we hold the BKL which means that preemption
+	 * is disabled. Various trace selftests however need to disable
+	 * and enable preemption for successful tests. So we drop the BKL here
+	 * and grab it after the tests again.
+	 */
+	unlock_kernel();
 	if (type->selftest) {
 		struct tracer *saved_tracer = current_trace;
 		struct trace_array *tr = &global_trace;
@@ -515,6 +522,7 @@ int register_tracer(struct tracer *type)
 		}
 		printk(KERN_CONT "PASSED\n");
 	}
+	lock_kernel();
 #endif
 
 	type->next = trace_types;
--
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/