From: Sergei Shtepa <hidden> Date: 2021-03-12 15:46:10
Hi all.
I'm joyful to suggest the block device interposer (bdev_interposer) v7.
bdev_interposer allows to redirect bio requests to other block devices.
In this series of patches I suggest a different implementation of the bio
interception mechanism. Now the interposer is a different block device.
Instead of an additional hook, the function fops->submit_bio() of
the interposer device is used.
This implementation greatly simplifies the application of this
bdev_interposer in device-mapper. But there is one limitation - the size
of the interposer device must be greater than or equal to the size of
the original device.
The first patch adds the function blk_mq_is_queue_frozen(). It allows to
check a queue state.
The second patch is dedicated to bdev_interposer itself, which provides
the ability to redirect bio to the interposer device.
The third one adds the DM_INTERPOSED_FLAG flag. When this flag is
applied with the ioctl DM_TABLE_LOAD_CMD, the underlying devices are
opened without the FMODE_EXCL flag and connected via bdev_interposer.
Changes in this patchset v7:
* the request interception mechanism. Now the interposer is
a block device that receives requests instead of the original device;
* code design fixes.
History:
v6 - https://patchwork.kernel.org/project/linux-block/cover/1614774618-22410-1-git-send-email-sergei.shtepa@veeam.com/
* designed for 5.12;
* thanks to the new design of the bio structure in v5.12, it is
possible to perform interception not for the entire disk, but
for each block device;
* instead of the new ioctl DM_DEV_REMAP_CMD and the 'noexcl' option,
the DM_INTERPOSED_FLAG flag for the ioctl DM_TABLE_LOAD_CMD is
applied.
v5 - https://patchwork.kernel.org/project/linux-block/cover/1612881028-7878-1-git-send-email-sergei.shtepa@veeam.com/
* rebase for v5.11-rc7;
* patch set organization;
* fix defects in documentation;
* add some comments;
* change mutex names for better code readability;
* remove calling bd_unlink_disk_holder() for targets with non-exclusive
flag;
* change type for struct dm_remap_param from uint8_t to __u8.
v4 - https://patchwork.kernel.org/project/linux-block/cover/1612367638-3794-1-git-send-email-sergei.shtepa@veeam.com/
Mostly changes were made, due to Damien's comments:
* on the design of the code;
* by the patch set organization;
* bug with passing a wrong parameter to dm_get_device();
* description of the 'noexcl' parameter in the linear.rst.
Also added remap_and_filter.rst.
v3 - https://patchwork.kernel.org/project/linux-block/cover/1611853955-32167-1-git-send-email-sergei.shtepa@veeam.com/
In this version, I already suggested blk_interposer to apply to dm-linear.
Problems were solved:
* Interception of bio requests from a specific device on the disk, not
from the entire disk. To do this, we added the dm_interposed_dev
structure and an interval tree to store these structures.
* Implemented ioctl DM_DEV_REMAP_CMD. A patch with changes in the lvm2
project was sent to the team lvm-devel@redhat.com.
* Added the 'noexcl' option for dm-linear, which allows you to open
the underlying block-device without FMODE_EXCL mode.
v2 - https://patchwork.kernel.org/project/linux-block/cover/1607518911-30692-1-git-send-email-sergei.shtepa@veeam.com/
I tried to suggest blk_interposer without using it in device mapper,
but with the addition of a sample of its use. It was then that I learned
about the maintainers' attitudes towards the samples directory :).
v1 - https://lwn.net/ml/linux-block/20201119164924.74401-1-hare@suse.de/
This Hannes's patch can be considered as a starting point, since this is
where the interception mechanism and the term blk_interposer itself
appeared. It became clear that blk_interposer can be useful for
device mapper.
before v1 - https://patchwork.kernel.org/project/linux-block/cover/1603271049-20681-1-git-send-email-sergei.shtepa@veeam.com/
I tried to offer a rather cumbersome blk-filter and a monster-like
blk-snap module for creating snapshots.
Thank you to everyone who was able to take the time to review
the previous versions.
I hope that this time I achieved the required quality.
Thanks,
Sergei.
Sergei Shtepa (3):
block: add blk_mq_is_queue_frozen()
block: add bdev_interposer
dm: add DM_INTERPOSED_FLAG
block/bio.c | 2 ++
block/blk-core.c | 57 ++++++++++++++++++++++++++++++++
block/blk-mq.c | 13 ++++++++
block/genhd.c | 54 +++++++++++++++++++++++++++++++
drivers/md/dm-core.h | 3 ++
drivers/md/dm-ioctl.c | 13 ++++++++
drivers/md/dm-table.c | 61 +++++++++++++++++++++++++++++------
drivers/md/dm.c | 38 +++++++++++++++-------
include/linux/blk-mq.h | 1 +
include/linux/blk_types.h | 3 ++
include/linux/blkdev.h | 9 ++++++
include/linux/device-mapper.h | 1 +
include/uapi/linux/dm-ioctl.h | 6 ++++
13 files changed, 240 insertions(+), 21 deletions(-)
--
2.20.1
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
@@ -46,6 +47,7 @@ struct block_device {spinlock_tbd_size_lock;/* for bd_inode->i_size updates */structgendisk*bd_disk;structbacking_dev_info*bd_bdi;+structblock_device*bd_interposer;/* The counter of freeze processes */intbd_fsfreeze_count;
@@ -304,6 +306,7 @@ enum {BIO_CGROUP_ACCT,/* has been accounted to a cgroup */BIO_TRACKED,/* set if bio goes through the rq_qos path */BIO_REMAPPED,+BIO_INTERPOSED,/* bio was reassigned to another block device */BIO_FLAG_LAST};
@@ -1293,6 +1298,10 @@ static int populate_table(struct dm_table *table,DMWARN("populate_table: no targets specified");return-EINVAL;}+if(table->md->is_interposed&&(param->target_count!=1)){+DMWARN("%s: with interposer should be specified only one target",__func__);+return-EINVAL;+}for(i=0;i<param->target_count;i++){
@@ -398,15 +411,38 @@ int dm_get_device(struct dm_target *ti, const char *path, fmode_t mode,refcount_set(&dd->count,1);list_add(&dd->list,&t->devices);-gotoout;-}elseif(dd->dm_dev->mode!=(mode|dd->dm_dev->mode)){r=upgrade_mode(dd,mode,t->md);if(r)returnr;+refcount_inc(&dd->count);}-refcount_inc(&dd->count);-out:++if(t->md->is_interposed){+structblock_device*original=dd->dm_dev->bdev;+structblock_device*interposer=t->md->disk->part0;++if((ti->begin!=0)||(ti->len<bdev_nr_sectors(original))){+dm_put_device(ti,dd->dm_dev);+DMERR("The interposer device should not be less than the original.");+return-EINVAL;+}++/*+*Attachmappedinterposerdevicetooriginal.+*Itisquiteconvenientthatdevicemappercreates+*onediskforoneblockdevice.+*/+dm_disk_freeze(original->bd_disk);+r=bdev_interposer_attach(original,interposer);+dm_disk_unfreeze(original->bd_disk);+if(r){+dm_put_device(ti,dd->dm_dev);+DMERR("Failed to attach dm interposer.");+returnr;+}+}+*result=dd->dm_dev;return0;}
This flag is a mix of uses. First it is used to store that
DM_INTERPOSED_FLAG was provided as input param during load.
And the same 'is_interposed' name is used in 'struct dm_dev'.
To me this state should be elevated to block core -- awkward for every
driver that might want to use blk-interposer to be sprinkling state
around its core structures.
So I'd prefer you:
1) rename 'struct mapped_device' to 'interpose' _and_ add it just after
"bool init_tio_pdu:1;" with "bool interpose:1;" -- this reflects
interpose was requested during load.
2) bdev_interposer_attach() should be made to set some block core state
that is able to be tested to check if a device is_interposed.
3) Don't add an 'is_interposed' flag to 'struct dm_dev'
@@ -1293,6 +1298,10 @@ static int populate_table(struct dm_table *table, DMWARN("populate_table: no targets specified"); return -EINVAL; }+ if (table->md->is_interposed && (param->target_count != 1)) {+ DMWARN("%s: with interposer should be specified only one target", __func__);
This error/warning reads very awkwardly. Maybe?:
"%s: interposer requires only a single target be specified"
quoted hunk
+ return -EINVAL;
+ }
for (i = 0; i < param->target_count; i++) {
@@ -1338,6 +1347,8 @@ static int table_load(struct file *filp, struct dm_ioctl *param, size_t param_si if (!md) return -ENXIO;+ md->is_interposed = get_interposer_flag(param);+ r = dm_table_create(&t, get_mode(param), param->target_count, md); if (r) goto err;
@@ -2098,6 +2109,8 @@ int __init dm_early_create(struct dm_ioctl *dmi, if (r) goto err_hash_remove;+ md->is_interposed = get_interposer_flag(dmi);+ /* add targets */ for (i = 0; i < dmi->target_count; i++) { r = dm_table_add_target(t, spec_array[i]->target_type,
Think in make more sense to internalize the need to consider
md->interpose here.
So:
static struct dm_dev_internal *find_device(struct dm_table *t, dev_t dev)
{
struct list_head *l = &t->devices;
bool is_interposed = t->md->interpose;
...
These interfaces don't account for bio-based at all (pretty sure we've
been over this and you pointed out that they'll just return early), but
they also don't take steps to properly flush outstanding DM io.
Shouldn't you require DM devices do an internal suspend/resume? And if
original device isn't DM then fallback to blk_mq calls?
quoted hunk
/*
* Add a device to the list, or just increment the usage count if
* it's already present.
This _should_ hopefully get cleaned up by pushing such state into block
core's interposer interfaces.
But again, not seeing what utility/safety this extra flag is providing
to begin with. Is this state _actually_ needed at all?
@@ -161,6 +161,19 @@ int blk_mq_freeze_queue_wait_timeout(struct request_queue *q,}EXPORT_SYMBOL_GPL(blk_mq_freeze_queue_wait_timeout);+boolblk_mq_is_queue_frozen(structrequest_queue*q)+{+boolfrozen;++mutex_lock(&q->mq_freeze_lock);+frozen=percpu_ref_is_dying(&q->q_usage_counter)&&+percpu_ref_is_zero(&q->q_usage_counter);+mutex_unlock(&q->mq_freeze_lock);++returnfrozen;+}+EXPORT_SYMBOL_GPL(blk_mq_is_queue_frozen);+
This is returning a frozen state that is immediately stale. I don't
think any code calling this is providing the guarantees you think it
does due to the racey nature of this state once the mutex is dropped.
quoted hunk
/*
* Guarantee no request is in use, so we can change any data structure of
* the queue afterward.
From: Christoph Hellwig <hch@infradead.org> Date: 2021-03-14 09:16:42
On Fri, Mar 12, 2021 at 02:06:41PM -0500, Mike Snitzer wrote:
This is returning a frozen state that is immediately stale. I don't
think any code calling this is providing the guarantees you think it
does due to the racey nature of this state once the mutex is dropped.
The code only uses it for asserts in the form of WARN_ONs.
I don't think this case can ever happen:
- current->bio_list != NULL means a ->submit_bio or blk_mq_submit_bio
is active. But if this device is being interposed this means the
interposer recurses into itself, which should never happen. So
I think we'll want a WARN_ON_ONCE here as a debug check instead.
+
+ orig_disk = bio->bi_bdev->bd_disk;
+ if (unlikely(bio_queue_enter(bio)))
+ return BLK_QC_T_NONE;
+
+ current->bio_list = bio_list;
+
+ do {
+ struct block_device *interposer = bio->bi_bdev->bd_interposer;
+
+ if (unlikely(!interposer)) {
+ /* interposer was removed */
+ bio_list_add(¤t->bio_list[0], bio);
+ break;
+ }
+ /* assign bio to interposer device */
+ bio_set_dev(bio, interposer);
+ bio_set_flag(bio, BIO_INTERPOSED);
Reassigning the bi_bdev here means the original source is lost by the
time we reach the interposer. This initially seemed a little limiting,
but I guess the interposer driver can just record that information
locally, so we should be fine. The big upside of this is that no
extra argument to submit_bio_checks, which means less changes to the
normal fast path, so if this works for everyone that is a nice
improvement over my draft.
+
+ if (!submit_bio_checks(bio))
+ break;
+ /*
+ * Because the current->bio_list is initialized,
+ * the submit_bio callback will always return BLK_QC_T_NONE.
+ */
+ interposer->bd_disk->fops->submit_bio(bio);
+ } while (false);
I find the do { ... } while (false) idiom here a little strange. Normal
kernel style would be a goto done instead of the breaks.
A kerneldoc comment for bdev_interposer_attach (and
bdev_interposer_detach) would be nice to explain the API a little more.
+{
+ int ret = 0;
+
+ if (WARN_ON(((!original) || (!interposer))))
+ return -EINVAL;
No need for the inner two levels of braces.
+ * interposer should be simple, no a multi-queue device
+ */
+ if (!interposer->bd_disk->fops->submit_bio)
Please use queue_is_mq() instead.
+ if (bdev_has_interposer(original))
+ ret = -EBUSY;
+ else {
+ original->bd_interposer = bdgrab(interposer);
Just thinking out a loud: what happens if the interposed device
goes away? Shouldn't we at very least also make sure this
gabs another refererence on bdev as well?
From: Christoph Hellwig <hch@infradead.org> Date: 2021-03-14 09:31:51
On Fri, Mar 12, 2021 at 06:44:55PM +0300, Sergei Shtepa wrote:
DM_INTERPOSED_FLAG allow to create DM targets on "the fly".
Underlying block device opens without a flag FMODE_EXCL.
DM target receives bio from the original device via
bdev_interposer.
This is more of a philopical comment, but the idea of just letting the
interposed reopen the device by itself seems like a bad idea. I think
that is probably better hidden in the block layer interposer attachment
function, which could do the extra blkdev_get_by_dev for the caller.
From: Sergei Shtepa <hidden> Date: 2021-03-15 12:06:56
The 03/14/2021 12:14, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 02:06:41PM -0500, Mike Snitzer wrote:
quoted
This is returning a frozen state that is immediately stale. I don't
think any code calling this is providing the guarantees you think it
does due to the racey nature of this state once the mutex is dropped.
The code only uses it for asserts in the form of WARN_ONs.
But perhaps it is possible to come up with a more elegant solution?
I'll think about it.
--
Sergei Shtepa
Veeam Software developer.
This flag is a mix of uses. First it is used to store that
DM_INTERPOSED_FLAG was provided as input param during load.
And the same 'is_interposed' name is used in 'struct dm_dev'.
To me this state should be elevated to block core -- awkward for every
driver that might want to use blk-interposer to be sprinkling state
around its core structures.
So I'd prefer you:
1) rename 'struct mapped_device' to 'interpose' _and_ add it just after
"bool init_tio_pdu:1;" with "bool interpose:1;" -- this reflects
interpose was requested during load.
2) bdev_interposer_attach() should be made to set some block core state
that is able to be tested to check if a device is_interposed.
3) Don't add an 'is_interposed' flag to 'struct dm_dev'
Ok, but little fix in "rename 'struct mapped_device' to 'interpose'".
Maybe "rename 'bool is_interposed' to 'bool interpose:1'"?
I think I understand your idea, I'll try to implement it.
@@ -1293,6 +1298,10 @@ static int populate_table(struct dm_table *table, DMWARN("populate_table: no targets specified"); return -EINVAL; }+ if (table->md->is_interposed && (param->target_count != 1)) {+ DMWARN("%s: with interposer should be specified only one target", __func__);
This error/warning reads very awkwardly. Maybe?:
"%s: interposer requires only a single target be specified"
Ok.
quoted
+ return -EINVAL;
+ }
for (i = 0; i < param->target_count; i++) {
@@ -1338,6 +1347,8 @@ static int table_load(struct file *filp, struct dm_ioctl *param, size_t param_si if (!md) return -ENXIO;+ md->is_interposed = get_interposer_flag(param);+ r = dm_table_create(&t, get_mode(param), param->target_count, md); if (r) goto err;
@@ -2098,6 +2109,8 @@ int __init dm_early_create(struct dm_ioctl *dmi, if (r) goto err_hash_remove;+ md->is_interposed = get_interposer_flag(dmi);+ /* add targets */ for (i = 0; i < dmi->target_count; i++) { r = dm_table_add_target(t, spec_array[i]->target_type,
Think in make more sense to internalize the need to consider
md->interpose here.
So:
static struct dm_dev_internal *find_device(struct dm_table *t, dev_t dev)
{
struct list_head *l = &t->devices;
bool is_interposed = t->md->interpose;
...
These interfaces don't account for bio-based at all (pretty sure we've
been over this and you pointed out that they'll just return early), but
they also don't take steps to properly flush outstanding DM io.
Shouldn't you require DM devices do an internal suspend/resume? And if
original device isn't DM then fallback to blk_mq calls?
I thought that was enough.
The function dm_disk_freeze() guarantees that no bio will be processed,
which means that we can safely attach or detach the interposer.
All bios will continue their processing after dm_disk_unfreeze().
Sorry, but I don't understand why it is required for DM devices to do
internal suspend/resume.
If this is not too difficult, can you explain what problem can cause
a simple queue freeze?
quoted
/*
* Add a device to the list, or just increment the usage count if
* it's already present.
This _should_ hopefully get cleaned up by pushing such state into block
core's interposer interfaces.
But again, not seeing what utility/safety this extra flag is providing
to begin with. Is this state _actually_ needed at all?
I don't think this case can ever happen:
- current->bio_list != NULL means a ->submit_bio or blk_mq_submit_bio
is active. But if this device is being interposed this means the
interposer recurses into itself, which should never happen. So
I think we'll want a WARN_ON_ONCE here as a debug check instead.
Yes, it is.
Completely remove this check or add "BUG_ON(current->bio_list);" for
an emergency?
quoted
+
+ orig_disk = bio->bi_bdev->bd_disk;
+ if (unlikely(bio_queue_enter(bio)))
+ return BLK_QC_T_NONE;
+
+ current->bio_list = bio_list;
+
+ do {
+ struct block_device *interposer = bio->bi_bdev->bd_interposer;
+
+ if (unlikely(!interposer)) {
+ /* interposer was removed */
+ bio_list_add(¤t->bio_list[0], bio);
+ break;
+ }
+ /* assign bio to interposer device */
+ bio_set_dev(bio, interposer);
+ bio_set_flag(bio, BIO_INTERPOSED);
Reassigning the bi_bdev here means the original source is lost by the
time we reach the interposer. This initially seemed a little limiting,
but I guess the interposer driver can just record that information
locally, so we should be fine. The big upside of this is that no
extra argument to submit_bio_checks, which means less changes to the
normal fast path, so if this works for everyone that is a nice
improvement over my draft.
quoted
+
+ if (!submit_bio_checks(bio))
+ break;
+ /*
+ * Because the current->bio_list is initialized,
+ * the submit_bio callback will always return BLK_QC_T_NONE.
+ */
+ interposer->bd_disk->fops->submit_bio(bio);
+ } while (false);
I find the do { ... } while (false) idiom here a little strange. Normal
kernel style would be a goto done instead of the breaks.
A kerneldoc comment for bdev_interposer_attach (and
bdev_interposer_detach) would be nice to explain the API a little more.
Yes, I should add kerneldoc comments.
quoted
+{
+ int ret = 0;
+
+ if (WARN_ON(((!original) || (!interposer))))
+ return -EINVAL;
No need for the inner two levels of braces.
Ok.
quoted
+ * interposer should be simple, no a multi-queue device
+ */
+ if (!interposer->bd_disk->fops->submit_bio)
Please use queue_is_mq() instead.
Ok.
quoted
+ if (bdev_has_interposer(original))
+ ret = -EBUSY;
+ else {
+ original->bd_interposer = bdgrab(interposer);
Just thinking out a loud: what happens if the interposed device
goes away? Shouldn't we at very least also make sure this
gabs another refererence on bdev as well?
If the original device is removed from the system, the interposer device
will be permanently occupied. I need to add an interposer release when
deleting a block device.
From: Sergei Shtepa <hidden> Date: 2021-03-15 13:26:15
The 03/14/2021 12:30, Christoph Hellwig wrote:
On Fri, Mar 12, 2021 at 06:44:55PM +0300, Sergei Shtepa wrote:
quoted
DM_INTERPOSED_FLAG allow to create DM targets on "the fly".
Underlying block device opens without a flag FMODE_EXCL.
DM target receives bio from the original device via
bdev_interposer.
This is more of a philopical comment, but the idea of just letting the
interposed reopen the device by itself seems like a bad idea. I think
that is probably better hidden in the block layer interposer attachment
function, which could do the extra blkdev_get_by_dev for the caller.
I suppose this cannot be implemented, since we need to change the behavior
for block devices that already have been opened.
--
Sergei Shtepa
Veeam Software developer.
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
quoted hunk
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
From: Christoph Hellwig <hch@infradead.org> Date: 2021-03-16 15:24:33
On Mon, Mar 15, 2021 at 04:25:09PM +0300, Sergei Shtepa wrote:
The 03/14/2021 12:30, Christoph Hellwig wrote:
quoted
On Fri, Mar 12, 2021 at 06:44:55PM +0300, Sergei Shtepa wrote:
quoted
DM_INTERPOSED_FLAG allow to create DM targets on "the fly".
Underlying block device opens without a flag FMODE_EXCL.
DM target receives bio from the original device via
bdev_interposer.
This is more of a philopical comment, but the idea of just letting the
interposed reopen the device by itself seems like a bad idea. I think
that is probably better hidden in the block layer interposer attachment
function, which could do the extra blkdev_get_by_dev for the caller.
I suppose this cannot be implemented, since we need to change the behavior
for block devices that already have been opened.
That's not what I mean. Take a look at the patch relative to your
series to let me know what you think. The new blkdev_interposer_attach
now takes a dev_t + mode for the original device and opens it on
behalf of the interposer. It also moves the queue freezing into the
API, which should address the concerns about the helper and adds a few
more sanity checks.
From: Christoph Hellwig <hch@infradead.org> Date: 2021-03-16 15:26:10
On Tue, Mar 16, 2021 at 03:23:14PM +0000, Christoph Hellwig wrote:
On Mon, Mar 15, 2021 at 04:25:09PM +0300, Sergei Shtepa wrote:
quoted
The 03/14/2021 12:30, Christoph Hellwig wrote:
quoted
On Fri, Mar 12, 2021 at 06:44:55PM +0300, Sergei Shtepa wrote:
quoted
DM_INTERPOSED_FLAG allow to create DM targets on "the fly".
Underlying block device opens without a flag FMODE_EXCL.
DM target receives bio from the original device via
bdev_interposer.
This is more of a philopical comment, but the idea of just letting the
interposed reopen the device by itself seems like a bad idea. I think
that is probably better hidden in the block layer interposer attachment
function, which could do the extra blkdev_get_by_dev for the caller.
I suppose this cannot be implemented, since we need to change the behavior
for block devices that already have been opened.
That's not what I mean. Take a look at the patch relative to your
series to let me know what you think. The new blkdev_interposer_attach
now takes a dev_t + mode for the original device and opens it on
behalf of the interposer. It also moves the queue freezing into the
API, which should address the concerns about the helper and adds a few
more sanity checks.
@@ -418,29 +406,11 @@ int dm_get_device(struct dm_target *ti, const char *path, fmode_t mode,refcount_inc(&dd->count);}-if(t->md->is_interposed){-structblock_device*original=dd->dm_dev->bdev;-structblock_device*interposer=t->md->disk->part0;--if((ti->begin!=0)||(ti->len<bdev_nr_sectors(original))){-dm_put_device(ti,dd->dm_dev);-DMERR("The interposer device should not be less than the original.");-return-EINVAL;-}--/*-*Attachmappedinterposerdevicetooriginal.-*Itisquiteconvenientthatdevicemappercreates-*onediskforoneblockdevice.-*/-dm_disk_freeze(original->bd_disk);-r=bdev_interposer_attach(original,interposer);-dm_disk_unfreeze(original->bd_disk);-if(r){-dm_put_device(ti,dd->dm_dev);-DMERR("Failed to attach dm interposer.");-returnr;-}+if(t->md->is_interposed&&+(ti->begin!=0||ti->len<bdev_nr_sectors(dd->dm_dev->bdev))){+dm_put_device(ti,dd->dm_dev);+DMERR("The interposer device should not be less than the original.");+return-EINVAL;}*result=dd->dm_dev;
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
I think that since the bio_queue_enter() function was called,
q->q_usage_counter will not allow the critical code in the attach/detach
functions to be executed, which is located between the blk_freeze_queue
and blk_unfreeze_queue calls.
Please correct me if I'm wrong.
quoted
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
I think that since the bio_queue_enter() function was called,
q->q_usage_counter will not allow the critical code in the attach/detach
functions to be executed, which is located between the blk_freeze_queue
and blk_unfreeze_queue calls.
Please correct me if I'm wrong.
quoted
quoted
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
Yes.
I will remove the blk_mq_is_queue_frozen() function and use a different
approach.
Looks what attach and detach needs is that queue is kept as frozen state
instead of being froze simply at the beginning of the two functions, so
you can simply call freeze/unfreeze inside the two functions.
But what if 'original' isn't a MQ queue? queue usage counter is just
grabed when calling ->submit_bio(), and queue freeze doesn't guarantee there
isn't any io activity, is that a problem for bdev_interposer use case?
--
Ming
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
I think that since the bio_queue_enter() function was called,
q->q_usage_counter will not allow the critical code in the attach/detach
functions to be executed, which is located between the blk_freeze_queue
and blk_unfreeze_queue calls.
Please correct me if I'm wrong.
quoted
quoted
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
Yes.
I will remove the blk_mq_is_queue_frozen() function and use a different
approach.
Looks what attach and detach needs is that queue is kept as frozen state
instead of being froze simply at the beginning of the two functions, so
you can simply call freeze/unfreeze inside the two functions.
But what if 'original' isn't a MQ queue? queue usage counter is just
grabed when calling ->submit_bio(), and queue freeze doesn't guarantee there
isn't any io activity, is that a problem for bdev_interposer use case?
--
Ming
It makes sense to add freeze_bdev/thaw_bdev. This will be useful.
For the main file systems, the freeze functions are defined
sb->s_op->freeze_super() or sb - >s_op->freeze_fs()
(btrfs, ext2, ext4, f2fs, jfs, nilfs2, reiserfs, xfs).
If the file system is frozen, then no new requests should be received.
But if the file system does not support freeze or the disk is used without
a file system, as for some databases, freeze_bdev seems useless to me.
In this case, we will need to stop working with the disk from user-space,
for example, to freeze the database itself.
I can add dm_suspend() before bdev_interposer_detach(). This will ensure that
all intercepted requests have been processed. Applying dm_suspend() before
bdev_interposer_attach() is pointless. The attachment is made when the target
is created, and at this time the target is not ready to work yet.
There shouldn't be any bio requests, I suppose. In addition,
sb->s_op->freeze_fs() for the interposer will not be called, because the file
system is not mounted for the interposer device. It should not be able to
be mounted. To do this, I will add an exclusive opening of the interposer
device.
I'll add freeze_bdev() for the original device and dm_suspend() for the
interposer to the DM code. For normal operation of bdev_interposer,
it is enough to transfer blk_mq_freeze_queue and blk_mq_quiesce_queue to
bdev_interposer_attach/bdev_interposer_detach.
The lock on the counter q->q_usage_counter is enough to not catch NULL in
bd_interposer.
Do you think this is enough?
I think there are no other ways to stop the block device queue.
--
Sergei Shtepa
Veeam Software developer.
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
I think that since the bio_queue_enter() function was called,
q->q_usage_counter will not allow the critical code in the attach/detach
functions to be executed, which is located between the blk_freeze_queue
and blk_unfreeze_queue calls.
Please correct me if I'm wrong.
quoted
quoted
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
Yes.
I will remove the blk_mq_is_queue_frozen() function and use a different
approach.
Looks what attach and detach needs is that queue is kept as frozen state
instead of being froze simply at the beginning of the two functions, so
you can simply call freeze/unfreeze inside the two functions.
But what if 'original' isn't a MQ queue? queue usage counter is just
grabed when calling ->submit_bio(), and queue freeze doesn't guarantee there
isn't any io activity, is that a problem for bdev_interposer use case?
--
Ming
It makes sense to add freeze_bdev/thaw_bdev. This will be useful.
For the main file systems, the freeze functions are defined
sb->s_op->freeze_super() or sb - >s_op->freeze_fs()
(btrfs, ext2, ext4, f2fs, jfs, nilfs2, reiserfs, xfs).
If the file system is frozen, then no new requests should be received.
But if the file system does not support freeze or the disk is used without
a file system, as for some databases, freeze_bdev seems useless to me.
In this case, we will need to stop working with the disk from user-space,
for example, to freeze the database itself.
I can add dm_suspend() before bdev_interposer_detach(). This will ensure that
all intercepted requests have been processed. Applying dm_suspend() before
bdev_interposer_attach() is pointless. The attachment is made when the target
is created, and at this time the target is not ready to work yet.
There shouldn't be any bio requests, I suppose. In addition,
sb->s_op->freeze_fs() for the interposer will not be called, because the file
system is not mounted for the interposer device. It should not be able to
be mounted. To do this, I will add an exclusive opening of the interposer
device.
I'll add freeze_bdev() for the original device and dm_suspend() for the
interposer to the DM code. For normal operation of bdev_interposer,
it is enough to transfer blk_mq_freeze_queue and blk_mq_quiesce_queue to
bdev_interposer_attach/bdev_interposer_detach.
The lock on the counter q->q_usage_counter is enough to not catch NULL in
bd_interposer.
Do you think this is enough?
I think there are no other ways to stop the block device queue.
Either you're pretty confused, or I am... regardless.. I think we need
to cover the basics of how interposer is expected to be paired with
an "original" device.
Those "original" device are already active and potentially in use
right? They may be either request-based blk-mq _or_ bio-based.
So what confuses me is that you're making assertions about how actively
used bio-based DM devices aren't in use until the interposed device
create happens... this is all getting very muddled.
And your lack of understanding of these various IO flushing methods
(freeze/thaw, suspend/resume, etc) is showing. Please slow down and
approach this more systematically.
Thanks,
Mike
From: Mike Snitzer <hidden> Date: 2021-03-17 16:17:52
On Tue, Mar 16 2021 at 11:03pm -0400,
Ming Lei [off-list ref] wrote:
On Tue, Mar 16, 2021 at 07:35:44PM +0300, Sergei Shtepa wrote:
quoted
The 03/16/2021 11:09, Ming Lei wrote:
quoted
On Fri, Mar 12, 2021 at 06:44:54PM +0300, Sergei Shtepa wrote:
quoted
bdev_interposer allows to redirect bio requests to another devices.
Signed-off-by: Sergei Shtepa <redacted>
...
quoted
quoted
quoted
+
+int bdev_interposer_attach(struct block_device *original,
+ struct block_device *interposer)
+{
+ int ret = 0;
+
+ if (WARN_ON(((!original) || (!interposer))))
+ return -EINVAL;
+ /*
+ * interposer should be simple, no a multi-queue device
+ */
+ if (!interposer->bd_disk->fops->submit_bio)
+ return -EINVAL;
+
+ if (WARN_ON(!blk_mq_is_queue_frozen(original->bd_disk->queue)))
+ return -EPERM;
The original request queue may become live now...
Yes.
I will remove the blk_mq_is_queue_frozen() function and use a different
approach.
Looks what attach and detach needs is that queue is kept as frozen state
instead of being froze simply at the beginning of the two functions, so
you can simply call freeze/unfreeze inside the two functions.
But what if 'original' isn't a MQ queue? queue usage counter is just
grabed when calling ->submit_bio(), and queue freeze doesn't guarantee there
isn't any io activity, is that a problem for bdev_interposer use case?
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
I think that since the bio_queue_enter() function was called,
q->q_usage_counter will not allow the critical code in the attach/detach
functions to be executed, which is located between the blk_freeze_queue
and blk_unfreeze_queue calls.
Please correct me if I'm wrong.
quoted
quoted
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
Yes.
I will remove the blk_mq_is_queue_frozen() function and use a different
approach.
Looks what attach and detach needs is that queue is kept as frozen state
instead of being froze simply at the beginning of the two functions, so
you can simply call freeze/unfreeze inside the two functions.
But what if 'original' isn't a MQ queue? queue usage counter is just
grabed when calling ->submit_bio(), and queue freeze doesn't guarantee there
isn't any io activity, is that a problem for bdev_interposer use case?
--
Ming
It makes sense to add freeze_bdev/thaw_bdev. This will be useful.
For the main file systems, the freeze functions are defined
sb->s_op->freeze_super() or sb - >s_op->freeze_fs()
(btrfs, ext2, ext4, f2fs, jfs, nilfs2, reiserfs, xfs).
If the file system is frozen, then no new requests should be received.
But if the file system does not support freeze or the disk is used without
a file system, as for some databases, freeze_bdev seems useless to me.
In this case, we will need to stop working with the disk from user-space,
for example, to freeze the database itself.
I can add dm_suspend() before bdev_interposer_detach(). This will ensure that
all intercepted requests have been processed. Applying dm_suspend() before
bdev_interposer_attach() is pointless. The attachment is made when the target
is created, and at this time the target is not ready to work yet.
There shouldn't be any bio requests, I suppose. In addition,
sb->s_op->freeze_fs() for the interposer will not be called, because the file
system is not mounted for the interposer device. It should not be able to
be mounted. To do this, I will add an exclusive opening of the interposer
device.
I'll add freeze_bdev() for the original device and dm_suspend() for the
interposer to the DM code. For normal operation of bdev_interposer,
it is enough to transfer blk_mq_freeze_queue and blk_mq_quiesce_queue to
bdev_interposer_attach/bdev_interposer_detach.
The lock on the counter q->q_usage_counter is enough to not catch NULL in
bd_interposer.
Do you think this is enough?
I think there are no other ways to stop the block device queue.
Either you're pretty confused, or I am... regardless.. I think we need
to cover the basics of how interposer is expected to be paired with
an "original" device.
Thank you Mike for your patience. I really appreciate it.
I really may not understand something. Let me get this straight.
Those "original" device are already active and potentially in use
right? They may be either request-based blk-mq _or_ bio-based.
Yes. Exactly.
So what confuses me is that you're making assertions about how actively
used bio-based DM devices aren't in use until the interposed device
create happens... this is all getting very muddled.
The original device is indeed already actively used and already mounted.
This is most likely not a DM device.
If it is a request-based blk-mq, then it is enough to stop its queue by
blk_mq_freeze_queue().
If it is a bio-based device, then we can try to stop it by freeze_bdev.
But in both cases, if the blk_mq_freeze_bdev() function was called, bio cannot
get into the critical section between bio_queue_enter() and blk_queue_exit().
This allows to safely change the value of original->bd_interposer.
To intercept requests to the original device, we create a new md with
the DM_INTERPOSE_FLAG flag. It is this interposer device that has not
yet been initialized by this time. It just runs DM_TABLE_LOAD_CMD.
That is why I think that the queue of this device should not be stopped,
since this device has not yet been initialized.
And your lack of understanding of these various IO flushing methods
(freeze/thaw, suspend/resume, etc) is showing. Please slow down and
approach this more systematically.
For any block device, we can call the freeze_bdev() function. It will
allow to wait until the processing of previously sent requests is
completed and block the sending of new ones. blk_mq_freeze_queue()
allows to change the bd_interposer variable. This allow to attach/detach
the interposer to original device.
dm_suspend() is used to stop mapped device. This is what I plan to use
before detaching the interposer. It will allow to wait for the
completion of all the bios that were sent for the interposer.
Thanks,
Mike
Please correct me if my reasoning is wrong.
--
Sergei Shtepa
Veeam Software developer.
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
I think that since the bio_queue_enter() function was called,
q->q_usage_counter will not allow the critical code in the attach/detach
functions to be executed, which is located between the blk_freeze_queue
and blk_unfreeze_queue calls.
Please correct me if I'm wrong.
quoted
quoted
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
Yes.
I will remove the blk_mq_is_queue_frozen() function and use a different
approach.
Looks what attach and detach needs is that queue is kept as frozen state
instead of being froze simply at the beginning of the two functions, so
you can simply call freeze/unfreeze inside the two functions.
But what if 'original' isn't a MQ queue? queue usage counter is just
grabed when calling ->submit_bio(), and queue freeze doesn't guarantee there
isn't any io activity, is that a problem for bdev_interposer use case?
--
Ming
It makes sense to add freeze_bdev/thaw_bdev. This will be useful.
For the main file systems, the freeze functions are defined
sb->s_op->freeze_super() or sb - >s_op->freeze_fs()
(btrfs, ext2, ext4, f2fs, jfs, nilfs2, reiserfs, xfs).
If the file system is frozen, then no new requests should be received.
But if the file system does not support freeze or the disk is used without
a file system, as for some databases, freeze_bdev seems useless to me.
In this case, we will need to stop working with the disk from user-space,
for example, to freeze the database itself.
I can add dm_suspend() before bdev_interposer_detach(). This will ensure that
all intercepted requests have been processed. Applying dm_suspend() before
bdev_interposer_attach() is pointless. The attachment is made when the target
is created, and at this time the target is not ready to work yet.
There shouldn't be any bio requests, I suppose. In addition,
sb->s_op->freeze_fs() for the interposer will not be called, because the file
system is not mounted for the interposer device. It should not be able to
be mounted. To do this, I will add an exclusive opening of the interposer
device.
I'll add freeze_bdev() for the original device and dm_suspend() for the
interposer to the DM code. For normal operation of bdev_interposer,
it is enough to transfer blk_mq_freeze_queue and blk_mq_quiesce_queue to
bdev_interposer_attach/bdev_interposer_detach.
The lock on the counter q->q_usage_counter is enough to not catch NULL in
bd_interposer.
Do you think this is enough?
I think there are no other ways to stop the block device queue.
Either you're pretty confused, or I am... regardless.. I think we need
to cover the basics of how interposer is expected to be paired with
an "original" device.
Thank you Mike for your patience. I really appreciate it.
I really may not understand something. Let me get this straight.
quoted
Those "original" device are already active and potentially in use
right? They may be either request-based blk-mq _or_ bio-based.
Yes. Exactly.
quoted
So what confuses me is that you're making assertions about how actively
used bio-based DM devices aren't in use until the interposed device
create happens... this is all getting very muddled.
The original device is indeed already actively used and already mounted.
This is most likely not a DM device.
If it is a request-based blk-mq, then it is enough to stop its queue by
blk_mq_freeze_queue().
If it is a bio-based device, then we can try to stop it by freeze_bdev.
But in both cases, if the blk_mq_freeze_bdev() function was called, bio cannot
get into the critical section between bio_queue_enter() and blk_queue_exit().
This allows to safely change the value of original->bd_interposer.
Even though bios cannot get into underlying blk-mq they are already
inflight on behalf of the upper-layer bio-based device. I'll look closer
at the code but it seems like there is potential for the original
device's bios to still be queued to original, past the ->submit_bio
entry, and waiting for blk-mq to unfreeze. Meaning upon return from
what I _think_ you're saying will be sufficient: DM bio-based device
will carry on submitting IO to the blk-mq device that has since been
interposed.. that IO will _not_ complete in terms of the interposed
device.. so you'll have a split-brain dual completion of IO from the
original bio-based DM device _and_ the interposed device (for any new io
that hits ->submit_bio after the interposed device is in place).
I think you need to have original bio-based DM suspend, interpose
device, and then resume the original. Anything entering original's
->submit_bio from that point will all get sent to interposed
device. Right?
To intercept requests to the original device, we create a new md with
the DM_INTERPOSE_FLAG flag. It is this interposer device that has not
yet been initialized by this time. It just runs DM_TABLE_LOAD_CMD.
That is why I think that the queue of this device should not be stopped,
since this device has not yet been initialized.
quoted
And your lack of understanding of these various IO flushing methods
(freeze/thaw, suspend/resume, etc) is showing. Please slow down and
approach this more systematically.
For any block device, we can call the freeze_bdev() function. It will
allow to wait until the processing of previously sent requests is
completed and block the sending of new ones. blk_mq_freeze_queue()
allows to change the bd_interposer variable. This allow to attach/detach
the interposer to original device.
freeze_bdev/thaw_bdev are only relevant if a filesystem is layered
ontop. A bio-based DM device can be used directly (by a database or
whatever).
dm_suspend() is used to stop mapped device. This is what I plan to use
before detaching the interposer. It will allow to wait for the
completion of all the bios that were sent for the interposer.
Yes, but you need to suspend before attaching the interposer too, to
flush any in-flight bios that might be in-flight within the various DM
target code.
DM should be able to internalize all this when handling the
DM_INTERPOSE_FLAG during the new table load. It'd call into
dm_internal_suspend_fast and then dm_internal_resume_fast for the
original md device.
Mike
@@ -1018,6 +1018,55 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio)returnret;}+staticnoinlineblk_qc_tsubmit_bio_interposed(structbio*bio)+{+blk_qc_tret=BLK_QC_T_NONE;+structbio_listbio_list[2]={};+structgendisk*orig_disk;++if(current->bio_list){+bio_list_add(¤t->bio_list[0],bio);+returnBLK_QC_T_NONE;+}++orig_disk=bio->bi_bdev->bd_disk;+if(unlikely(bio_queue_enter(bio)))+returnBLK_QC_T_NONE;++current->bio_list=bio_list;++do{+structblock_device*interposer=bio->bi_bdev->bd_interposer;++if(unlikely(!interposer)){+/* interposer was removed */+bio_list_add(¤t->bio_list[0],bio);+break;+}+/* assign bio to interposer device */+bio_set_dev(bio,interposer);+bio_set_flag(bio,BIO_INTERPOSED);++if(!submit_bio_checks(bio))+break;+/*+*Becausethecurrent->bio_listisinitialized,+*thesubmit_biocallbackwillalwaysreturnBLK_QC_T_NONE.+*/+interposer->bd_disk->fops->submit_bio(bio);
Given original request queue may become live when calling attach() and
detach(), see below comment. bdev_interposer_detach() may be run
when running ->submit_bio(), meantime the interposer device is
gone during the period, then kernel oops.
I think that since the bio_queue_enter() function was called,
q->q_usage_counter will not allow the critical code in the attach/detach
functions to be executed, which is located between the blk_freeze_queue
and blk_unfreeze_queue calls.
Please correct me if I'm wrong.
quoted
quoted
+ } while (false);
+
+ current->bio_list = NULL;
+
+ blk_queue_exit(orig_disk->queue);
+
+ /* Resubmit remaining bios */
+ while ((bio = bio_list_pop(&bio_list[0])))
+ ret = submit_bio_noacct(bio);
+
+ return ret;
+}
+
/**
* submit_bio_noacct - re-submit a bio to the block device layer for I/O
* @bio: The bio describing the location in memory and on the device.
@@ -1029,6 +1078,14 @@ static blk_qc_t __submit_bio_noacct_mq(struct bio *bio) */ blk_qc_t submit_bio_noacct(struct bio *bio) {+ /*+ * Checking the BIO_INTERPOSED flag is necessary so that the bio+ * created by the bdev_interposer do not get to it for processing.+ */+ if (bdev_has_interposer(bio->bi_bdev) &&+ !bio_flagged(bio, BIO_INTERPOSED))+ return submit_bio_interposed(bio);+ if (!submit_bio_checks(bio)) return BLK_QC_T_NONE;
@@ -30,6 +30,11 @@staticstructkobject*block_depr;DECLARE_RWSEM(bdev_lookup_sem);+/*+*Preventsdifferentblock-layerinterposersfromattachingordetaching+*totheblockdeviceatthesametime.+*/+staticDEFINE_MUTEX(bdev_interposer_attach_lock);/* for extended dynamic devt allocation, currently only one major is used */#define NR_EXT_DEVT (1 << MINORBITS)
Yes.
I will remove the blk_mq_is_queue_frozen() function and use a different
approach.
Looks what attach and detach needs is that queue is kept as frozen state
instead of being froze simply at the beginning of the two functions, so
you can simply call freeze/unfreeze inside the two functions.
But what if 'original' isn't a MQ queue? queue usage counter is just
grabed when calling ->submit_bio(), and queue freeze doesn't guarantee there
isn't any io activity, is that a problem for bdev_interposer use case?
--
Ming
It makes sense to add freeze_bdev/thaw_bdev. This will be useful.
For the main file systems, the freeze functions are defined
sb->s_op->freeze_super() or sb - >s_op->freeze_fs()
(btrfs, ext2, ext4, f2fs, jfs, nilfs2, reiserfs, xfs).
If the file system is frozen, then no new requests should be received.
But if the file system does not support freeze or the disk is used without
a file system, as for some databases, freeze_bdev seems useless to me.
In this case, we will need to stop working with the disk from user-space,
for example, to freeze the database itself.
I can add dm_suspend() before bdev_interposer_detach(). This will ensure that
all intercepted requests have been processed. Applying dm_suspend() before
bdev_interposer_attach() is pointless. The attachment is made when the target
is created, and at this time the target is not ready to work yet.
There shouldn't be any bio requests, I suppose. In addition,
sb->s_op->freeze_fs() for the interposer will not be called, because the file
system is not mounted for the interposer device. It should not be able to
be mounted. To do this, I will add an exclusive opening of the interposer
device.
I'll add freeze_bdev() for the original device and dm_suspend() for the
interposer to the DM code. For normal operation of bdev_interposer,
it is enough to transfer blk_mq_freeze_queue and blk_mq_quiesce_queue to
bdev_interposer_attach/bdev_interposer_detach.
The lock on the counter q->q_usage_counter is enough to not catch NULL in
bd_interposer.
Do you think this is enough?
I think there are no other ways to stop the block device queue.
Either you're pretty confused, or I am... regardless.. I think we need
to cover the basics of how interposer is expected to be paired with
an "original" device.
Thank you Mike for your patience. I really appreciate it.
I really may not understand something. Let me get this straight.
quoted
Those "original" device are already active and potentially in use
right? They may be either request-based blk-mq _or_ bio-based.
Yes. Exactly.
quoted
So what confuses me is that you're making assertions about how actively
used bio-based DM devices aren't in use until the interposed device
create happens... this is all getting very muddled.
The original device is indeed already actively used and already mounted.
This is most likely not a DM device.
If it is a request-based blk-mq, then it is enough to stop its queue by
blk_mq_freeze_queue().
If it is a bio-based device, then we can try to stop it by freeze_bdev.
But in both cases, if the blk_mq_freeze_bdev() function was called, bio cannot
get into the critical section between bio_queue_enter() and blk_queue_exit().
This allows to safely change the value of original->bd_interposer.
Even though bios cannot get into underlying blk-mq they are already
inflight on behalf of the upper-layer bio-based device. I'll look closer
at the code but it seems like there is potential for the original
device's bios to still be queued to original, past the ->submit_bio
entry, and waiting for blk-mq to unfreeze. Meaning upon return from
what I _think_ you're saying will be sufficient: DM bio-based device
will carry on submitting IO to the blk-mq device that has since been
interposed.. that IO will _not_ complete in terms of the interposed
device.. so you'll have a split-brain dual completion of IO from the
original bio-based DM device _and_ the interposed device (for any new io
that hits ->submit_bio after the interposed device is in place).
Yes, You right. I looked closer at function submit_bio_noacct().
Indeed, the bio can wait to enter to the queue after checking that
the device has a interposer.
This means that some bio requests can go to the original device after
attaching the interposer. Conversely, bio requests can fall into
the function submit_bio_interposer() at a time when the interposer
has already been detached. In submit_bio_interposer() for this case,
there is a re-check that the interposer is there.
I don't see what kind of problems this can cause when attaching
the interposer, but detaching it bothers me.
I need to take a timeout and think it through.
I think you need to have original bio-based DM suspend, interpose
device, and then resume the original. Anything entering original's
->submit_bio from that point will all get sent to interposed
device. Right?
A small remark. The original device is not a DM device. The DM device
plays the role of the interposer. And it really needs to be suspended.
quoted
To intercept requests to the original device, we create a new md with
the DM_INTERPOSE_FLAG flag. It is this interposer device that has not
yet been initialized by this time. It just runs DM_TABLE_LOAD_CMD.
That is why I think that the queue of this device should not be stopped,
since this device has not yet been initialized.
quoted
And your lack of understanding of these various IO flushing methods
(freeze/thaw, suspend/resume, etc) is showing. Please slow down and
approach this more systematically.
For any block device, we can call the freeze_bdev() function. It will
allow to wait until the processing of previously sent requests is
completed and block the sending of new ones. blk_mq_freeze_queue()
allows to change the bd_interposer variable. This allow to attach/detach
the interposer to original device.
freeze_bdev/thaw_bdev are only relevant if a filesystem is layered
ontop. A bio-based DM device can be used directly (by a database or
whatever).
quoted
dm_suspend() is used to stop mapped device. This is what I plan to use
before detaching the interposer. It will allow to wait for the
completion of all the bios that were sent for the interposer.
Yes, but you need to suspend before attaching the interposer too, to
flush any in-flight bios that might be in-flight within the various DM
target code.
DM should be able to internalize all this when handling the
DM_INTERPOSE_FLAG during the new table load. It'd call into
dm_internal_suspend_fast and then dm_internal_resume_fast for the
original md device.
The dm_internal_suspend_fast() function looks very useful. I'll try it.