The previous "Fix: statedump hang due to incorrect wait/wakeup use" was
not actually fixing the real problem.
The issue is that we should pass the expected condition to wait_event()
rather than its contrary.
This bug has been sitting there for a while. I suspect that a recent
change in the Linux scheduler behavior for newly spawned worker threads
might have contributed to trigger the hang more reliably.
The effects of this bugs are:
- possible hang of the lttng-sessiond (within the kernel) at tracing
start,
- the statedump end event is traced before all worker threads have
actually completed, which can confuse LTTng viewer state systems.
Reported-by: Phil Wilshire <sysdcs@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
schedule_delayed_work_on(cpu, &cpu_work[cpu], 0);
}
/* Wait for all threads to run */
- wait_event(statedump_wq, (atomic_read(&kernel_threads_to_run) != 0));
+ __wait_event(statedump_wq, (atomic_read(&kernel_threads_to_run) == 0));
put_online_cpus();
/* Our work is done */
printk(KERN_DEBUG "LTT state dump end\n");