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)
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
>
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 th
* 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
>
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 k
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 wh
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 kernels?
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
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
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 a
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
> > rt_mutex_
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.
>
> Sig
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
---
include
13 matches
Mail list logo
