bad return value in __mutex_lock_check_stamp

bad return value in __mutex_lock_check_stamp

[Nicholas Mc Guire]

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.

Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
---
 kernel/rtmutex.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 4e9691f..148eef7 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -1007,6 +1007,7 @@ static inline int __sched
 __mutex_lock_check_stamp(struct rt_mutex *lock, struct ww_acquire_ctx *ctx)
 {
 	BUG();
+	return 0;
 }
 
 #endif
-- 
1.7.2.5

Re: bad return value in __mutex_lock_check_stamp

[Sebastian Andrzej Siewior]

On 12/15/2013 03:40 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.

Sebastian

Re: bad return value in __mutex_lock_check_stamp

[Nicholas Mc Guire]

On Sun, 15 Dec 2013, Sebastian Andrzej Siewior wrote:

> On 12/15/2013 03:40 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

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 ?

Am I confusing some ifdefs ?

thx!
hofrat

Re: bad return value in __mutex_lock_check_stamp

[Sebastian Andrzej Siewior]

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