From: "Steven Rostedt (Red Hat)" <[email protected]> When crossing over to a new page, commit the current work. This will allow readers to get data with less latency, and also simplifies the work to get timestamps working for interrupted events.
Signed-off-by: Steven Rostedt <[email protected]> --- kernel/module.c | 18 ++++++++++++++++-- kernel/trace/ring_buffer.c | 7 +++++++ 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index 8f051a106676..c0ae7c18c2fa 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -284,11 +284,25 @@ static void module_assert_mutex(void) static void module_assert_mutex_or_preempt(void) { #ifdef CONFIG_LOCKDEP + static int once; + if (unlikely(!debug_locks)) return; - WARN_ON(!rcu_read_lock_sched_held() && - !lockdep_is_held(&module_mutex)); + /* + * Would be nice to use WARN_ON_ONCE(), but the warning + * that causes a stack trace may call __module_address() + * which may call here, and we trigger the warning again, + * before the WARN_ON_ONCE() updates its flag. + * To prevent the recursion, we need to open code the + * once logic. + */ + if (!once && + unlikely(!rcu_read_lock_sched_held() && + !lockdep_is_held(&module_mutex))) { + once++; + WARN_ON(1); + } #endif } diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 631541a53baf..95181e36891a 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -2129,6 +2129,8 @@ rb_reset_tail(struct ring_buffer_per_cpu *cpu_buffer, local_sub(length, &tail_page->write); } +static inline void rb_end_commit(struct ring_buffer_per_cpu *cpu_buffer); + /* * This is the slow path, force gcc not to inline it. */ @@ -2220,6 +2222,11 @@ rb_move_tail(struct ring_buffer_per_cpu *cpu_buffer, rb_reset_tail(cpu_buffer, tail, info); + /* Commit what we have for now. */ + rb_end_commit(cpu_buffer); + /* rb_end_commit() decs committing */ + local_inc(&cpu_buffer->committing); + /* fail and let the caller try again */ return ERR_PTR(-EAGAIN); -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
