From: malahal@us.ibm.com
To: dm-devel@redhat.com
Subject: Re: [PATCH] a deadlock bug in the kernel-side device mapper code
Date: Mon, 9 Nov 2009 17:50:03 -0800 [thread overview]
Message-ID: <20091110015003.GA7104@us.ibm.com> (raw)
In-Reply-To: <20091110002445.GF17055@agk-dp.fab.redhat.com>
Alasdair G Kergon [agk@redhat.com] wrote:
> On Mon, Nov 09, 2009 at 09:57:30AM -0800, malahal@us.ibm.com wrote:
> > Why do we need dm_get() and dm_put() in dm_copy_name_and_uuid()?
> > dm_copy_name_and_uuid() already has access to md and there shouldn't be
> > any need to hold a reference.
>
> As Mike points out, struct dm_uevent holds a reference without
> incrementing the ref count.
>
> dm_path_uevent() already takes a reference - can everything get
> simplified if we move this code there (and replace the new mutex with
> a spinlock of course)? Then dm_send_uevents won't need to use 'md'.
I think the last dm_put() is calling the multipath destructor which
eventually calls (through a work struct) dm_send_uevents. At that point,
dm is guaranteed to exist but you *must* not place a hold on it. As the
current code in dm_copy_name_and_uuid() places a hold on a FREEING md,
it will result in a BUG_ON while calling the dm_put in the same
function. So, removing the dm_get/dm_put from that function should also
solve the BUG_ON issue.
I agree, removing the "md" field from the dm_event struct probably
simplifies other things.
Thanks, Malahal.
next prev parent reply other threads:[~2009-11-10 1:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-05 13:21 a deadlock bug in the kernel-side device mapper code guy keren
2009-11-05 14:24 ` Alasdair G Kergon
2009-11-06 2:58 ` [PATCH] " Mikulas Patocka
[not found] ` <20091106151504.GS13375@agk-dp.fab.redhat.com>
2009-11-06 16:30 ` Mikulas Patocka
2009-11-06 17:27 ` malahal
2009-11-09 8:51 ` Mike Anderson
2009-11-09 17:57 ` malahal
2009-11-09 22:24 ` malahal
2009-11-10 0:24 ` Alasdair G Kergon
2009-11-10 1:50 ` malahal [this message]
2009-11-10 5:24 ` Mike Anderson
2009-11-10 6:13 ` Mikulas Patocka
2009-11-06 0:24 ` Kiyoshi Ueda
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=20091110015003.GA7104@us.ibm.com \
--to=malahal@us.ibm.com \
--cc=dm-devel@redhat.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