Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1569943
| From | Andy Ritger <aritger@nvidia.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH RT] Align rt_mutex inlining with upstream behavior |
| Date | 2017-01-30 18:40 +0100 |
| Message-ID | <t5o5Q-6Mu-31@gated-at.bofh.it> (permalink) |
| References | <t3lON-4dZ-5@gated-at.bofh.it> <t3VID-1CL-43@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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_destroy() with mutex_destroy() by using the same no-op inline > > technique. > > > > Signed-off-by: Alex Goins <agoins@nvidia.com> > > Reviewed-by: Andy Ritger <aritger@nvidia.com> > > So what is the problem? Why are we doing this? There is still a check to > see if the lock is in use which is also done for the case where > DEBUG_MUTEX is disabled. 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. In upstream, non-DEBUG_MUTEX kernels define mutex_destroy to a noop. This gives users the option of disabling DEBUG_MUTEX if they want to use non-GPL, reservation_object_fini()-using, kernel modules. In PREEMPTRT, non-DEBUG_MUTEX kernels export rt_mutex_destroy as EXPORT_SYMBOL_GPL, so users no longer have the work around of using DEBUG_MUTEX. This patch gives PREEMPTRT users the option of disabling DEBUG_MUTEX if they want to use such kernel modules, matching upstream behavior.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH RT] Align rt_mutex inlining with upstream behavior Alex Goins <agoins@nvidia.com> - 2017-01-25 03:50 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-01-26 18:10 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Andy Ritger <aritger@nvidia.com> - 2017-01-30 18:40 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-02-03 17:00 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Andy Ritger <aritger@nvidia.com> - 2017-02-03 17:50 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Andy Ritger <aritger@nvidia.com> - 2017-02-10 19:20 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-02-10 19:30 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Alex Goins <agoins@nvidia.com> - 2017-02-10 20:20 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Ingo Molnar <mingo@kernel.org> - 2017-02-11 19:00 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Thomas Gleixner <tglx@linutronix.de> - 2017-02-11 21:20 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-02-10 19:30 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Peter Zijlstra <peterz@infradead.org> - 2017-02-13 12:30 +0100
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-02-13 14:30 +0100
csiph-web