From: Keith Owens <kaos@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [patch 2.6.9] Avoid a rare deadlock during unwind
Date: Thu, 21 Oct 2004 14:44:35 +0000 [thread overview]
Message-ID: <8388.1098369875@ocs3.ocs.com.au> (raw)
In-Reply-To: <9718.1098174005@kao2.melbourne.sgi.com>
On Thu, 21 Oct 2004 07:30:55 -0700,
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Tue, 19 Oct 2004 18:20:05 +1000, Keith Owens <kaos@sgi.com> said:
>
> Keith> There is a rare deadlock condition during unwind script
> Keith> creation. If build_script() is interrupted in the middle of
> Keith> creating the script, it holds the script write lock. If the
> Keith> interrupt handler needs to call unwind for some failure
> Keith> condition, unwind will try to read the incomplete script and
> Keith> will deadlock on the script lock.
>
> Keith> The fix is to disable interrupts while building the script,
> Keith> so interrupt handlers never see partial scripts.
>
> Keith> Promoting spin_lock_irqsave() from script_new() to
> Keith> find_save_locs() changes the indentation, so the patch looks
> Keith> bigger than it really is.
>
>I'm not sure this is safe. You're now acquiring the read/write-lock
>after the spinlock and according to the SMP conventions mentionted at
>the beginning of the file, this isn't safe:
>
> * o if both the unw.lock spinlock and a script's read-write lock must be
> * acquired, then the read-write lock must be acquired first.
>
>Did you check that this isn't a problem? If so, it would at least be
>necessary to update the comment.
Emprically it works. The patched code has been hammered several
million times, using modifying oprofile code that generates gprof
backtraces whenever the profile interrupt pops. That was the code that
found the original deadlock in unwind.
The comment does not say why the order is required. I believe that it
really meant
o if both the unw.lock spinlock and a script's read-write lock must be
acquired using a method that might sleep, then the read-write lock
must be acquired first.
adding "using a method that might sleep". The only read-write lock
code under spinlock(unw.lock) is write_trylock(), which never sleeps.
If you agree with this analysis, then I am happy to update the comment.
next prev parent reply other threads:[~2004-10-21 14:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-19 8:20 [patch 2.6.9] Avoid a rare deadlock during unwind Keith Owens
2004-10-21 14:30 ` David Mosberger
2004-10-21 14:44 ` Keith Owens [this message]
2004-10-22 9:27 ` David Mosberger
2004-10-22 10:10 ` Keith Owens
2004-10-22 10:14 ` Keith Owens
2004-10-22 10:50 ` David Mosberger
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=8388.1098369875@ocs3.ocs.com.au \
--to=kaos@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/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