All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Huey (hui) <billh@gnuppy.monkey.org>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	david singleton <dsingleton@mvista.com>,
	linux-kernel@vger.kernel.org,
	"Bill Huey (hui)" <billh@gnuppy.monkey.org>
Subject: Re: RT Mutex patch and tester [PREEMPT_RT]
Date: Sat, 14 Jan 2006 20:24:49 -0800	[thread overview]
Message-ID: <20060115042449.GA9871@gnuppy.monkey.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0601111816360.16743-201000@lifa03.phys.au.dk>

On Wed, Jan 11, 2006 at 06:25:36PM +0100, Esben Nielsen wrote:
> So how many locks do we have to worry about? Two.
> One for locking the lock. One for locking various PI related data on the
> task structure, as the pi_waiters list, blocked_on, pending_owner - and
> also prio.
> Therefore only lock->wait_lock and sometask->pi_lock will be locked at the
> same time. And in that order. There is therefore no spinlock deadlocks.
> And the code is simpler.

Ok, got a question. How do deal with the false reporting and handling of
a lock circularity window involving the handoff of task A's BKL to another
task B ? Task A is blocked trying to get a mutex owned by task B, task A
is block B since it owns BKL which task B is contending on. It's not a
deadlock since it's a hand off situation.

I didn't see any handling of this case in the code and I was wondering
if the traversal logic you wrote avoids this case as an inherent property
and I missed that stuff ?

bill


  parent reply	other threads:[~2006-01-15  4:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-11 17:25 RT Mutex patch and tester [PREEMPT_RT] Esben Nielsen
2006-01-11 17:51 ` Steven Rostedt
2006-01-11 21:45   ` Esben Nielsen
2006-01-12 11:33 ` Bill Huey
2006-01-12 12:54   ` Esben Nielsen
2006-01-13  8:07     ` Bill Huey
2006-01-13  8:47       ` Esben Nielsen
2006-01-13 10:19         ` Bill Huey
2006-01-15  4:24 ` Bill Huey [this message]
2006-01-16  8:35   ` Esben Nielsen
2006-01-16 10:22     ` Bill Huey
2006-01-16 10:53       ` Bill Huey
2006-01-16 11:30         ` Esben Nielsen
     [not found] ` <Pine.LNX.4.44L0.0601181120100.1993-201000@lifa02.phys.au.dk>
2006-01-18 10:38   ` Ingo Molnar
2006-01-18 12:49   ` Steven Rostedt
2006-01-18 14:18     ` Esben Nielsen
     [not found]   ` <Pine.LNX.4.44L0.0601230047290.31387-201000@lifa01.phys.au.dk>
2006-01-23  0:38     ` david singleton
2006-01-23  2:04     ` Bill Huey
2006-01-23  9:33       ` Esben Nielsen
2006-01-23 14:23         ` Steven Rostedt
2006-01-23 15:14           ` Esben Nielsen
2006-01-27 15:18             ` Esben Nielsen

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=20060115042449.GA9871@gnuppy.monkey.org \
    --to=billh@gnuppy.monkey.org \
    --cc=dsingleton@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=simlo@phys.au.dk \
    /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.