On Fri, 6 Nov 2015, Thomas Gleixner wrote: > On Wed, 4 Nov 2015, Yimin Deng wrote: > > It seems that the purpose to call the remove_waiter() is to remove the > > waiter added by “plist_add(&waiter->list_entry, &lock->wait_list);” in > > the task_blocks_on_rt_mutex(). But in the scenario above there's no > > waiter on the lock yet and > > the waiter has not been added into the wait list of the lock in the > > task_blocks_on_rt_mutex() due to the failure “-EAGAIN”. So it reported > > kernel BUG in the rt_mutex_top_waiter(). > > > > I modified it as below and the issue seems disappear. > > - if (unlikely(ret)) > > + if (unlikely(ret && (-EAGAIN != ret))) > > remove_waiter(lock, waiter); > > > > Could the scenario above be possible? If so, how to resolve this issue? > > Thanks! > > Yes it is possible. Nice detective work! > > Your solution is correct, but actually it's not sufficient, because we > have another possibility to return early without being queued > (-EDEADLOCK). Find the full solution below. > > Thanks for tracking that down! Btw, please update to 3.12.48-rt66. It contains quite some bugfixes in the area of futex/rtmutex. Thanks, tglx
