Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1569943

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

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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