[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CD9239E.2080209@kernel.org>
Date: Tue, 09 Nov 2010 11:34:06 +0100
From: Tejun Heo <tj@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
CC: axboe@...nel.dk, linux-kernel@...r.kernel.org, petero2@...ia.com,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com, jack@...e.cz,
akpm@...ux-foundation.org, adilger.kernel@...ger.ca, tytso@....edu,
mfasheh@...e.com, joel.becker@...cle.com, aelder@....com,
dm-devel@...hat.com, drbd-dev@...ts.linbit.com, neilb@...e.de,
leochen@...adcom.com, sbranden@...adcom.com,
chris.mason@...cle.com, swhiteho@...hat.com,
shaggy@...ux.vnet.ibm.com, joern@...fs.org,
konishi.ryusuke@....ntt.co.jp, reiserfs-devel@...r.kernel.org,
viro@...iv.linux.org.uk
Subject: Re: [PATCH 4/5] block: make blkdev_get/put() handle exclusive access
Hello,
On 11/03/2010 05:10 PM, Christoph Hellwig wrote:
> On Mon, Nov 01, 2010 at 05:15:28PM +0100, Tejun Heo wrote:
>> * blkdev_get() is extended to include exclusive access management.
>> @holder argument is added and, if is @FMODE_EXCL specified, it will
>> gain exclusive access atomically w.r.t. other exclusive accesses.
>>
>> * blkdev_put() is similarly extended. It now takes @mode argument and
>> if @FMODE_EXCL is set, it releases an exclusive access. Also, when
>> the last exclusive claim is released, the holder/slave symlinks are
>> removed automatically.
>
> Could we get rid of FMODE_EXCL and just make a non-NULL holder field
> mean to open it exlusively (and pass a holder to the blkdev_put to
> release it)?
Yeah, I agree it's a bit awkward. I'd really like to force one way or
the other tho. ie. if non-NULL holder is gonna be required, I'll add
WARN_ON_ONCE(mode & FMODE_EXCL). There are several issues to
consider.
* As Jan suggested, @mode in blkdev_put() isn't too useful. I decided
to keep it and use FMODE_EXCL for exclusive releases as that it is
at least useful for something. If we're gonna add @holder to
blkdev_put(), it would make more sense to drop @mode. It's not like
there's a way to enforce restrictions according to open @mode during
device access if there are mixed r/w opens.
* Some users don't keep @holder easily accessible until blkdev_put()
is called, so the conversion will take a bit more effort. No big
deal in itself.
* What if @holder on blkdev_put() mismatches the current holder?
Probably WARN_ON_ONCE() is the only recourse. At that point, it's a
bit silly to have to keep @holder around till blkdev_put(). Holders
and opners counting already provide meaningful warning mechanism
against spurious or missing exclusive releases. Maybe we can have
blkdev_put() and blkdev_put_exclusive()? Or make it take boolean
@excl?
So, after the above points, I decided to keep @mode. It is a bit
awkward but the other way didn't seem too hip either. Any better
ideas?
>> * bd_link_disk_holder() remains the same but bd_unlink_disk_holder()
>> is no longer necessary and removed.
>
> That's a rather asymetric interface. What about having
> blkdev_get_stacked that require a gendisk as holder and set up the
> links underneath?
That will make the number of functions multiplied by two -
blkdev_get_by_path_stacked() and blkdev_get_by_dev_stacked(). The
symlinking for stacked drivers is an oddball feature which is and will
be only used by md and dm. So, I think it's better to keep it
separate and oddball.
>> open_bdev_exclusive() and open_by_devnum() can use further cleanup -
>> rename to blkdev_get_by_path() and blkdev_get_by_devt() and drop
>> special features. Well, let's leave them for another day.
>
> s/blkdev_get_by_devt/blkdev_get_by_dev/
>
> And yes, that rename is a good idea and should go in ASAP after this
> patch.
Alright, will do it.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists