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 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.