linux-kernel - Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize

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, 04 Jun 2013 08:11:21 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	"Paul E. McKenney" <paulmck@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>, Tejun Heo <tj@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy
 synchronize_sched()

On Tue, 2013-06-04 at 13:03 +0200, Frederic Weisbecker wrote:

> If ftrace were to use rcu_dereference_sched() instead of rcu_dereference_raw(), I guess
> the issue would have been detected before. But I guess we want to avoid that for
> tracing recursion?

It's been detected before, just ignored as most of ftrace function
tracing has permanent objects and the synchronization doesn't really
matter for them. But for perf and SystemTap that uses dynamically
created ftrace_ops and needs to free them, it does make a difference.
Something I knew needed to be fixed but never got around to it as the
race is extremely tight (and requires root user trying to trigger it). I
haven't been ably to trigger the race, but in theory it's there.

Note the checks that rcu_dereference_sched() has to test for these kinds
of things would cause ftrace to live lock the system if it had used it.
In fact, I had to make a rcu_dereference_raw_notrace() to prevent ftrace
locking up the system when full rcu debugging is enabled.

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