* bad return value in __mutex_lock_check_stamp
@ 2013-12-15 14:40 Nicholas Mc Guire
2013-12-15 15:10 ` Sebastian Andrzej Siewior
0 siblings, 1 reply; 4+ messages in thread
From: Nicholas Mc Guire @ 2013-12-15 14:40 UTC (permalink / raw)
To: linux-rt-users; +Cc: Sebastian Andrzej Siewior
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
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: bad return value in __mutex_lock_check_stamp
2013-12-15 14:40 bad return value in __mutex_lock_check_stamp Nicholas Mc Guire
@ 2013-12-15 15:10 ` Sebastian Andrzej Siewior
2013-12-15 16:18 ` Nicholas Mc Guire
0 siblings, 1 reply; 4+ messages in thread
From: Sebastian Andrzej Siewior @ 2013-12-15 15:10 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: linux-rt-users
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bad return value in __mutex_lock_check_stamp
2013-12-15 15:10 ` Sebastian Andrzej Siewior
@ 2013-12-15 16:18 ` Nicholas Mc Guire
2013-12-15 16:48 ` Sebastian Andrzej Siewior
0 siblings, 1 reply; 4+ messages in thread
From: Nicholas Mc Guire @ 2013-12-15 16:18 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linux-rt-users
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bad return value in __mutex_lock_check_stamp
2013-12-15 16:18 ` Nicholas Mc Guire
@ 2013-12-15 16:48 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 4+ messages in thread
From: Sebastian Andrzej Siewior @ 2013-12-15 16:48 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: linux-rt-users
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-12-15 16:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-15 14:40 bad return value in __mutex_lock_check_stamp Nicholas Mc Guire
2013-12-15 15:10 ` Sebastian Andrzej Siewior
2013-12-15 16:18 ` Nicholas Mc Guire
2013-12-15 16:48 ` Sebastian Andrzej Siewior
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).