From: Darren Hart <dvhltc@us.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH 3/6] futex: add double_unlock_hb()
Date: Thu, 12 Mar 2009 08:13:21 -0700 [thread overview]
Message-ID: <49B92691.3010100@us.ibm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0903121153300.29264@localhost.localdomain>
Thomas Gleixner wrote:
> On Thu, 12 Mar 2009, Ingo Molnar wrote:
>> * Peter Zijlstra <peterz@infradead.org> wrote:
>>
>>> On Thu, 2009-03-12 at 00:55 -0700, Darren Hart wrote:
>>>> The futex code uses double_lock_hb() which locks the hb->lock's in pointer
>>>> value order. There is no parallel unlock routine, and the code unlocks them
>>>> in name order, ignoring pointer value. This opens up a window for an ABBA
>>>> deadlock. This patch adds double_unlock_hb() to remove the window as well
>>>> as refactor the duplicated code segments.
>>> While I don't mind the patch per-se, I'm hard pressed to see
>>> any deadlock potential in the unordered unlock.
>>>
>>> All sites (at least those in the patch) always release both
>>> locks without taking another in between, therefore one would
>>> think there's no deadlock possible.
>> yeah.
>
> I can't see a deadlock either.
>
Right, sorry, it's the double_lock that requires the test. Duh. I need
to find a way to do some of this work during more regular hours I guess
;-) Thanks for the catch everyone.
Ingo shall I resubmit? Or did you already clean it up?
Thanks,
Darren
>> The patch is still nice (as you mention), it factors out the
>> unlock sequence. I'll change the commit message accordingy.
>
> We do not need the comparison magic. Can we just put the code into
> double_unlock_hb() which gets replaced ?
>
> i.e:
>
> spin_unlock(&hb1->lock);
> if (hb1 != hb2)
> spin_unlock(&hb2->lock);
>
> This code is confusing enough.
>
> Thanks,
>
> tglx
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2009-03-12 15:13 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 7:55 [PATCH 0/6] Futex fixes and cleanups Darren Hart
2009-03-12 7:55 ` [PATCH 1/6] Update futex commentary Darren Hart
2009-03-12 10:24 ` [tip:core/futexes] futex: update " Darren Hart
2009-03-12 7:55 ` [PATCH 2/6] Additional (get|put)_futex_key() fixes Darren Hart
2009-03-12 10:16 ` Ingo Molnar
2009-03-12 13:42 ` Thomas Gleixner
2009-03-12 23:22 ` Darren Hart
2009-03-12 10:24 ` [tip:core/futexes] futex: additional " Darren Hart
2009-03-13 0:20 ` Ingo Molnar
2009-03-13 5:46 ` Darren Hart
2009-03-13 0:24 ` [tip:core/urgent] " Darren Hart
2009-03-12 7:55 ` [PATCH 3/6] futex: add double_unlock_hb() Darren Hart
2009-03-12 10:07 ` Peter Zijlstra
2009-03-12 10:10 ` Ingo Molnar
2009-03-12 10:58 ` Thomas Gleixner
2009-03-12 15:13 ` Darren Hart [this message]
2009-03-12 10:24 ` [tip:core/futexes] " Darren Hart
2009-03-12 7:55 ` [PATCH 4/6] futex: Use current->time_slack_ns for rt tasks too Darren Hart
2009-03-12 10:11 ` Peter Zijlstra
2009-03-12 10:24 ` [tip:core/futexes] futex: use " Darren Hart
2009-03-12 13:53 ` Arjan van de Ven
2009-03-12 14:02 ` Peter Zijlstra
2009-03-12 14:25 ` Thomas Gleixner
2009-03-12 14:48 ` Peter Zijlstra
2009-03-12 15:01 ` Arjan van de Ven
2009-03-12 21:33 ` Darren Hart
2009-03-12 21:43 ` Thomas Gleixner
2009-03-12 21:29 ` Darren Hart
2009-03-12 7:56 ` [PATCH 5/6] futex: unlock before returning -EFAULT Darren Hart
2009-03-12 10:13 ` Peter Zijlstra
2009-03-12 10:47 ` Thomas Gleixner
2009-03-12 11:06 ` Peter Zijlstra
2009-03-12 15:15 ` Darren Hart
2009-03-12 22:17 ` Darren Hart
2009-03-12 10:24 ` [tip:core/futexes] " Darren Hart
2009-03-13 0:24 ` [tip:core/urgent] " Darren Hart
2009-03-12 7:56 ` [PATCH 6/6] futex: cleanup fault logic Darren Hart
2009-03-12 10:15 ` Peter Zijlstra
2009-03-12 15:09 ` Darren Hart
2009-03-12 10:25 ` [tip:core/futexes] futex: clean up " Darren Hart
2009-03-12 12:22 ` [PATCH 0/6] Futex fixes and cleanups Ingo Molnar
2009-03-12 15:21 ` Darren Hart
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=49B92691.3010100@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox