On Fri, Mar 08, 2019 at 01:10:09PM -0800, Zubin Mithra wrote:
From: Peter Zijlstra peterz@infradead.org
commit 38d589f2fd08f1296aea3ce62bebd185125c6d81 upstream
With the ultimate goal of keeping rt_mutex wait_list and futex_q waiters consistent it's necessary to split 'rt_mutex_futex_lock()' into finer parts, such that only the actual blocking can be done without hb->lock held.
Split split_mutex_finish_proxy_lock() into two parts, one that does the blocking and one that does remove_waiter() when the lock acquire failed.
When the rtmutex was acquired successfully the waiter can be removed in the acquisiton path safely, since there is no concurrency on the lock owner.
This means that, except for futex_lock_pi(), all wait_list modifications are done with both hb->lock and wait_lock held.
[bigeasy@linutronix.de: fix for futex_requeue_pi_signal_restart]
Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: dvhart@infradead.org Cc: bristot@redhat.com Link: http://lkml.kernel.org/r/20170322104152.001659630@infradead.org Signed-off-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Zubin Mithra zsm@chromium.org
Syzkaller reported a GPF in rt_mutex_top_waiter when fuzzing a 4.4 kernel. The corresponding call trace is below:
Now queued up, thanks.
greg k-h