Re: bad return value in __mutex_lock_check_stamp

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 12/15/2013 05:18 PM, Nicholas Mc Guire wrote:
>>> Bad return value in _mutex_lock_check_stamp - this problem only would show 
>>> up with 3.12.1 rt4 applied but CONFIG_PREEMPT_RT_FULL not enabled 
>>> currently it would be returning what ever vprintk_emit ended up with 
>>> (atleast on x86), which probably is not the intended behavior. Added a
>>> return 0; as in the case with CONFIG_PREEMPT_RT_FULL enabled.
>>
>> Interesting. How do you trigger this? This BUG()-only function should
>> get completely removed by gcc because
>> - ctx argument should be always NULL
>> - BUG() has unreachable() so gcc knows it does not return.
>>
> poped up with randconfig seed 0xBE96A834

Ach. Could you send me the defconfig (offlist) please? I'm trying to
check this later.

> Don't get it - why could gcc optimize it out ? it gets called
> in the mutex slowpath (kernel/mutex.c) if CONFIG_PREEMPT_RT_FULL
> is not set ?

Well, yes. There are two of that __mutex_lock_check_stamp() function,
one  in kernel/mutex.c and the other in rtmutex.c. In the non-RT case,
the www-mutex code is used from mutex.c
In rtmutex.c we end up in the BUG() only function. However all callers
of __rt_mutex_slowlock() have (or should have) ww_ctx set to NULL so we
never end up in __mutex_lock_check_stamp(). The compiler should see
this because all callers are static or static inline.

Your patch is correct, I am just curious why it triggers on your side.
It didn't trigger here why I come up with piece code during v3.12.

> Am I confusing some ifdefs ?
> 
> thx!
> hofrat
> 

Sebastian