All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Ritger <aritger@nvidia.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Alex Goins <agoins@nvidia.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	<linux-rt-users@vger.kernel.org>
Subject: Re: [PATCH RT] Align rt_mutex inlining with upstream behavior
Date: Mon, 30 Jan 2017 09:35:34 -0800	[thread overview]
Message-ID: <20170130173534.GA24966@prokofiev.nvidia.com> (raw)
In-Reply-To: <20170126170109.6zhoohgodtvxot54@linutronix.de>

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.


  reply	other threads:[~2017-01-30 17:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25  2:45 [PATCH RT] Align rt_mutex inlining with upstream behavior Alex Goins
2017-01-26 17:01 ` Sebastian Andrzej Siewior
2017-01-30 17:35   ` Andy Ritger [this message]
2017-02-03 15:54     ` Sebastian Andrzej Siewior
2017-02-03 16:49       ` Andy Ritger
2017-02-10 17:50         ` Sebastian Andrzej Siewior
2017-02-10 18:09           ` Andy Ritger
2017-02-10 18:28             ` Sebastian Andrzej Siewior
2017-02-10 19:17               ` Alex Goins
2017-02-11 17:52               ` Ingo Molnar
2017-02-11 20:15                 ` Thomas Gleixner
2017-02-13 11:20           ` Peter Zijlstra
2017-02-13 13:04             ` Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170130173534.GA24966@prokofiev.nvidia.com \
    --to=aritger@nvidia.com \
    --cc=agoins@nvidia.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.