linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Thavatchai Makphaibulchoke <tmac@hp.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!
Date: Thu, 19 Feb 2015 23:53:21 -0500	[thread overview]
Message-ID: <20150219235321.0acf3c75@grimm.local.home> (raw)
In-Reply-To: <1424395866-81589-2-git-send-email-tmac@hp.com>

On Thu, 19 Feb 2015 18:31:05 -0700
Thavatchai Makphaibulchoke <tmac@hp.com> wrote:

> This patch fixes the problem that the ownership of a mutex acquired by an
> interrupt handler(IH) gets incorrectly attributed to the interrupted thread.

*blink*

> 
> This could result in an incorrect deadlock detection in function
> rt_mutex_adjust_prio_chain(), causing thread to be killed and possibly leading
> up to a system hang.

I highly doubt this is an incorrect deadlock that was detected. My
money is on a real deadlock that happened.

> 
> Here is the approach taken: when calling from an interrupt handler, instead of
> attributing ownership to the interrupted task, use a reserved task_struct value
> to indicate that the owner is a interrupt handler.  This approach avoids the
> incorrect deadlock detection.

How is this an incorrect deadlock? Please explain.

> 
> This also includes changes in several function in rtmutex.c now that the lock's
> requester may be a interrupt handler, not a real task struct.  This impacts
> the way how the lock is acquired and prioritized and decision whether to do
> the house keeping functions required for a real task struct.
> 
> The reserved task_struct values for interrupt handler are
> 
> 	current | 0x2
> 
> where current is the task_struct value of the interrupted task.
> 
> Since IH will both acquire and release the lock only during an interrupt
> handling, during which current is not changed, the reserved task_struct value
> for an IH should be distinct from another instances of IH on a different cpu.
> 

The interrupt handler is a thread just like any other task. It's not
special. If there was a deadlock detected, it most likely means that a
deadlock exists.

-- Steve


> Kernel version 3.14.25 + patch-3.14.25-rt22
> 
> Signed-off-by: T. Makphaibulchoke <tmac@hp.com>
> ---
>  include/linux/spinlock_rt.h     |   4 +
>  kernel/locking/rtmutex-debug.c  |  15 ++-
>  kernel/locking/rtmutex.c        | 212 ++++++++++++++++++++++++++++------------
>  kernel/locking/rtmutex_common.h |  21 ++++
>  kernel/timer.c                  |   4 +-
>  5 files changed, 188 insertions(+), 68 deletions(-)
> 


  reply	other threads:[~2015-02-20  4:52 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20  1:31 [PATCH 3.14.25-rt22 0/2] rtmutex Real-Time Linux: fix kernel BUG at kernel/locking/rtmutex.c:997! and some optimization Thavatchai Makphaibulchoke
2015-02-20  1:31 ` [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997! Thavatchai Makphaibulchoke
2015-02-20  4:53   ` Steven Rostedt [this message]
2015-02-20 18:54     ` Thavatchai Makphaibulchoke
2015-02-21  1:49       ` Steven Rostedt
2015-02-23 18:37   ` Steven Rostedt
2015-02-24  0:16     ` Thavatchai Makphaibulchoke
2015-02-24  0:57       ` Steven Rostedt
2015-02-26 13:56         ` Sebastian Andrzej Siewior
2015-02-26 14:06           ` Steven Rostedt
2015-03-06 12:19             ` Sebastian Andrzej Siewior
2015-03-09 16:36               ` Steven Rostedt
2015-03-09 16:49                 ` Sebastian Andrzej Siewior
2015-02-20  1:31 ` [PATCH 3.14.25-rt22 2/2] kernel/locking/rtmutex.c: some code optimization Thavatchai Makphaibulchoke
2015-04-07  1:26 ` [PATCH v2 0/2] rtmutex Real-Time Linux: fix BUG at kernel/locking/rtmutex.c:997! Thavatchai Makphaibulchoke
2015-04-07  1:26   ` [PATCH v2 1/2] rtmutex Real-Time Linux: Fixing kernel " Thavatchai Makphaibulchoke
2015-04-07  1:59     ` Steven Rostedt
2015-04-07  5:09       ` Mike Galbraith
2015-04-07 10:29         ` Peter Zijlstra
2015-04-07 10:49           ` Mike Galbraith
2015-04-07 10:56             ` Peter Zijlstra
2015-04-07 11:01               ` Mike Galbraith
2015-04-08  0:55       ` Thavatchai Makphaibulchoke
2015-04-08  8:50         ` Thomas Gleixner
2015-04-09 22:56           ` Thavatchai Makphaibulchoke
2015-04-07 11:23     ` Thomas Gleixner
2015-04-07 11:47       ` Mike Galbraith
2015-04-07 12:04         ` Peter Zijlstra
2015-04-07 12:07           ` Peter Zijlstra
2015-04-07 12:41           ` Steven Rostedt
2015-04-07 12:54             ` Peter Zijlstra
2015-04-07 13:58               ` Steven Rostedt
2015-04-07 18:12           ` Jason Low
2015-04-07 19:17             ` Thomas Gleixner
2015-04-07 19:57               ` Jason Low
2015-04-07 21:38                 ` Thomas Gleixner
2015-04-07  1:26   ` [PATCH v2 2/2] kernel/locking/rtmutex.c: some code optimization Thavatchai Makphaibulchoke

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=20150219235321.0acf3c75@grimm.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tmac@hp.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).