From: Tejun Heo <tj@kernel.org>
To: Neil Brown <neilb@suse.de>
Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
Doug Ledford <dledford@redhat.com>, Greg KH <greg@kroah.com>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH 1/2] md: make devices disappear when they are no longer needed.
Date: Mon, 24 Nov 2008 14:34:30 +0900 [thread overview]
Message-ID: <492A3CE6.4010206@kernel.org> (raw)
In-Reply-To: <18730.14324.830648.449469@notabene.brown>
(cc'ing Jens)
Neil Brown wrote:
> On Monday November 24, tj@kernel.org wrote:
>> (cc'ing Greg)
>>
>> NeilBrown wrote:
>>> Currently md devices, once created, never disappear until the module
>>> is unloaded. This is essentially because the gendisk holds a
>>> reference to the mddev, and the mddev holds a reference to the
>>> gendisk, this a circular reference.
>>>
>>> If we drop the reference from mddev to gendisk, then we need to ensure
>>> that the mddev is destroyed when the gendisk is destroyed. However it
>>> is not possible to hook into the gendisk destruction process to enable
>>> this.
>>>
>>> So we drop the reference from the gendisk to the mddev and destroy the
>>> gendisk when the mddev gets destroyed. However this has a
>>> complication.
>>> Between the call
>>> __blkdev_get->get_gendisk->kobj_lookup->md_probe
>>> and the call
>>> __blkdev_get->md_open
>>>
>>> there is no obvious way to hold a reference on the mddev any more, so
>>> unless something is done, it will disappear and gendisk will be
>>> destroyed prematurely.
>>>
>>> Also, once we decide to destroy the mddev, there will be an unlockable
>>> moment before the gendisk is unlinked (blk_unregister_region) during
>>> which a new reference to the gendisk can be created. We need to
>>> ensure that this reference can not be used. i.e. the ->open must
>>> fail.
>> Ah... I'm not really sure I'm following all of this correctly but would
>> it be possible to just add ->release to genhd and do regular reference
>> counting rather than this complex dancing? ->release was recently added
>> to cdev so it'll be nicely parallel.
>
> Maybe...
>
> If genhd.c:disk_release called e.g.
> disk->fops->final_put(disk)
>
> then I could possibly link in to that to destroy the md state when the
> gendisk finally disappears.
>
> When I want to kill the gendisk I would call blk_unregister_region
> directly (not through del_gendisk) to allow it to disappear.
> If md_probe then gets called before the final_put, I'd need to
> call blk_register_region again to re-install it.
>
> I think that would work.
>
> Would 'block_device_operations' be the right place for this
> 'final_put' or 'final_release' ??
I suppose so. Maybe just void (*release)(struct gendisk *) but Jens is
the maintainer. Jens, what do you think?
Thanks.
--
tejun
next prev parent reply other threads:[~2008-11-24 5:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-24 3:55 [PATCH 0/2] RFC: allow md devices to disappear when not in use NeilBrown
2008-11-24 3:55 ` [PATCH 1/2] md: make devices disappear when they are no longer needed NeilBrown
2008-11-24 4:18 ` Tejun Heo
2008-11-24 5:13 ` Neil Brown
2008-11-24 5:34 ` Tejun Heo [this message]
2008-11-24 6:10 ` NeilBrown
2008-11-24 6:10 ` NeilBrown
2008-11-24 6:12 ` Tejun Heo
2008-11-24 6:24 ` Al Viro
2008-11-24 6:56 ` Tejun Heo
2008-11-24 13:31 ` Al Viro
2008-11-24 14:04 ` Tejun Heo
2008-11-24 14:26 ` Tejun Heo
2008-11-24 14:48 ` Al Viro
2008-11-24 16:08 ` Tejun Heo
2008-11-24 16:42 ` Al Viro
2008-11-24 17:18 ` Tejun Heo
2008-11-28 0:23 ` Neil Brown
2008-11-24 4:24 ` Al Viro
2008-11-24 4:47 ` Neil Brown
2008-11-24 6:38 ` Al Viro
2008-11-24 3:55 ` [PATCH 2/2] Allow md devices to be created by name NeilBrown
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=492A3CE6.4010206@kernel.org \
--to=tj@kernel.org \
--cc=dledford@redhat.com \
--cc=greg@kroah.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=viro@zeniv.linux.org.uk \
/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.