Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-13 Thread Sebastian Andrzej Siewior
On 2017-02-13 12:20:52 [+0100], Peter Zijlstra wrote: > > --- a/include/linux/mutex_rt.h > > +++ b/include/linux/mutex_rt.h > > @@ -43,7 +43,12 @@ extern void __lockfunc _mutex_unlock(str > > #define mutex_lock_killable(l) _mutex_lock_killable(l) > > #define mutex_trylock(l)

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-13 Thread Sebastian Andrzej Siewior
On 2017-02-13 12:20:52 [+0100], Peter Zijlstra wrote: > > --- a/include/linux/mutex_rt.h > > +++ b/include/linux/mutex_rt.h > > @@ -43,7 +43,12 @@ extern void __lockfunc _mutex_unlock(str > > #define mutex_lock_killable(l) _mutex_lock_killable(l) > > #define mutex_trylock(l)

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-13 Thread Peter Zijlstra
On Fri, Feb 10, 2017 at 06:50:50PM +0100, Sebastian Andrzej Siewior wrote: > Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol > which won't link and therefore fail on a non-GPL kernel module. > This does not happen on !RT and is a regression on RT which we would like to

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-13 Thread Peter Zijlstra
On Fri, Feb 10, 2017 at 06:50:50PM +0100, Sebastian Andrzej Siewior wrote: > Alex Goins reported that mutex_destroy() on RT will force a GPL only symbol > which won't link and therefore fail on a non-GPL kernel module. > This does not happen on !RT and is a regression on RT which we would like to

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-11 Thread Thomas Gleixner
On Sat, 11 Feb 2017, Ingo Molnar wrote: > > * Sebastian Andrzej Siewior wrote: > > > On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > > > Is the > > > > > > WARN_ON(rt_mutex_is_locked(lock)); > > > > > > in rt_mutex_destroy() valuable in

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-11 Thread Thomas Gleixner
On Sat, 11 Feb 2017, Ingo Molnar wrote: > > * Sebastian Andrzej Siewior wrote: > > > On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > > > Is the > > > > > > WARN_ON(rt_mutex_is_locked(lock)); > > > > > > in rt_mutex_destroy() valuable in non-CONFIG_DEBUG_MUTEXES kernels, > > > such

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-11 Thread Ingo Molnar
* Sebastian Andrzej Siewior wrote: > On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > > Is the > > > > WARN_ON(rt_mutex_is_locked(lock)); > > > > in rt_mutex_destroy() valuable in non-CONFIG_DEBUG_MUTEXES kernels, > > such that it would be better to always call

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-11 Thread Ingo Molnar
* Sebastian Andrzej Siewior wrote: > On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > > Is the > > > > WARN_ON(rt_mutex_is_locked(lock)); > > > > in rt_mutex_destroy() valuable in non-CONFIG_DEBUG_MUTEXES kernels, > > such that it would be better to always call it, and not noop away

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Alex Goins
This should work. Reviewed-by: Alex Goins Thanks, Alex On Fri, 10 Feb 2017, Sebastian Andrzej Siewior wrote: > On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > > Is the > > > > WARN_ON(rt_mutex_is_locked(lock)); > > > > in rt_mutex_destroy() valuable in

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Alex Goins
This should work. Reviewed-by: Alex Goins Thanks, Alex On Fri, 10 Feb 2017, Sebastian Andrzej Siewior wrote: > On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > > Is the > > > > WARN_ON(rt_mutex_is_locked(lock)); > > > > in rt_mutex_destroy() valuable in non-CONFIG_DEBUG_MUTEXES

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Sebastian Andrzej Siewior
On 2017-02-03 08:49:24 [-0800], Andy Ritger wrote: > > So your problem is simply that your non-GPL module can't link anymore > > with -RT. Would it help you if I simply replace the export for > > mutex_destroy with EXPORT_SYMBOL and leave it the function as is? > > Yes, definitely. So this is

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Sebastian Andrzej Siewior
On 2017-02-03 08:49:24 [-0800], Andy Ritger wrote: > > So your problem is simply that your non-GPL module can't link anymore > > with -RT. Would it help you if I simply replace the export for > > mutex_destroy with EXPORT_SYMBOL and leave it the function as is? > > Yes, definitely. So this is

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Sebastian Andrzej Siewior
On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > Is the > > WARN_ON(rt_mutex_is_locked(lock)); > > in rt_mutex_destroy() valuable in non-CONFIG_DEBUG_MUTEXES kernels, > such that it would be better to always call it, and not noop away > mutex_destroy() > non-CONFIG_DEBUG_MUTEXES

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Sebastian Andrzej Siewior
On 2017-02-10 10:09:29 [-0800], Andy Ritger wrote: > Is the > > WARN_ON(rt_mutex_is_locked(lock)); > > in rt_mutex_destroy() valuable in non-CONFIG_DEBUG_MUTEXES kernels, > such that it would be better to always call it, and not noop away > mutex_destroy() > non-CONFIG_DEBUG_MUTEXES

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Andy Ritger
On Fri, Feb 10, 2017 at 06:50:50PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-02-03 08:49:24 [-0800], Andy Ritger wrote: > > > So your problem is simply that your non-GPL module can't link anymore > > > with -RT. Would it help you if I simply replace the export for > > > mutex_destroy with

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Andy Ritger
On Fri, Feb 10, 2017 at 06:50:50PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-02-03 08:49:24 [-0800], Andy Ritger wrote: > > > So your problem is simply that your non-GPL module can't link anymore > > > with -RT. Would it help you if I simply replace the export for > > > mutex_destroy with

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-03 Thread Andy Ritger
On Fri, Feb 03, 2017 at 04:54:34PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-30 09:35:34 [-0800], Andy Ritger wrote: > > The problem is that various static inline functions such as > > reservation_object_fini() indirectly call mutex_destroy. On DEBUG_MUTEX > > kernels, mutex_destroy is

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-03 Thread Andy Ritger
On Fri, Feb 03, 2017 at 04:54:34PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-30 09:35:34 [-0800], Andy Ritger wrote: > > The problem is that various static inline functions such as > > reservation_object_fini() indirectly call mutex_destroy. On DEBUG_MUTEX > > kernels, mutex_destroy is

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-03 Thread Sebastian Andrzej Siewior
On 2017-01-30 09:35:34 [-0800], Andy Ritger wrote: > The problem is that various static inline functions such as > reservation_object_fini() indirectly call mutex_destroy. On DEBUG_MUTEX > kernels, mutex_destroy is EXPORT_SYMBOL_GPL. So your problem is simply that your non-GPL module can't link

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-03 Thread Sebastian Andrzej Siewior
On 2017-01-30 09:35:34 [-0800], Andy Ritger wrote: > The problem is that various static inline functions such as > reservation_object_fini() indirectly call mutex_destroy. On DEBUG_MUTEX > kernels, mutex_destroy is EXPORT_SYMBOL_GPL. So your problem is simply that your non-GPL module can't link

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-01-30 Thread Andy Ritger
On Thu, Jan 26, 2017 at 06:01:09PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-24 18:45:50 [-0800], Alex Goins wrote: > > mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. The RT Linux > > patches replace mutex_destroy() with rt_mutex_destroy(). This patch aligns > >

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-01-30 Thread Andy Ritger
On Thu, Jan 26, 2017 at 06:01:09PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-24 18:45:50 [-0800], Alex Goins wrote: > > mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. The RT Linux > > patches replace mutex_destroy() with rt_mutex_destroy(). This patch aligns > >

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-01-26 Thread Sebastian Andrzej Siewior
On 2017-01-24 18:45:50 [-0800], Alex Goins wrote: > mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. The RT Linux > patches replace mutex_destroy() with rt_mutex_destroy(). This patch aligns > rt_mutex_destroy() with mutex_destroy() by using the same no-op inline > technique. > >

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-01-26 Thread Sebastian Andrzej Siewior
On 2017-01-24 18:45:50 [-0800], Alex Goins wrote: > mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. The RT Linux > patches replace mutex_destroy() with rt_mutex_destroy(). This patch aligns > rt_mutex_destroy() with mutex_destroy() by using the same no-op inline > technique. > >

[PATCH RT] Align rt_mutex inlining with upstream behavior

2017-01-24 Thread Alex Goins
mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. The RT Linux patches replace mutex_destroy() with rt_mutex_destroy(). This patch aligns rt_mutex_destroy() with mutex_destroy() by using the same no-op inline technique. Signed-off-by: Alex Goins Reviewed-by: Andy

[PATCH RT] Align rt_mutex inlining with upstream behavior

2017-01-24 Thread Alex Goins
mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. The RT Linux patches replace mutex_destroy() with rt_mutex_destroy(). This patch aligns rt_mutex_destroy() with mutex_destroy() by using the same no-op inline technique. Signed-off-by: Alex Goins Reviewed-by: Andy Ritger ---