Re: [RFC 1/1] Add dm verity root hash pkcs7 sig validation.
On Mon, May 20, 2019 at 02:54:22PM -0700, Jaskaran Khurana wrote:
Adds in-kernel pkcs7 signature checking for the roothash of
the dm-verity hash tree.
The verification is to support cases where the roothash is not secured by
Trusted Boot, UEFI Secureboot or similar technologies.
One of the use cases for this is for dm-verity volumes mounted after boot,
the root hash provided during the creation of the dm-verity volume has to
be secure and thus in-kernel validation implemented here will be used
before we trust the root hash and allow the block device to be created.
The signature being provided for verification must verify the root hash and
must be trusted by the builtin keyring for verification to succeed.
Adds DM_VERITY_VERIFY_ROOTHASH_SIG: roothash verification
against the roothash signature file *if* specified, if signature file is
specified verification must succeed prior to creation of device mapper
block device.
Adds DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE: roothash signature *must* be
specified for all dm verity volumes and verification must succeed prior
to creation of device mapper block device.
Signed-off-by: Jaskaran Khurana
---
drivers/md/Kconfig| 23 ++
drivers/md/Makefile | 2 +-
drivers/md/dm-verity-target.c | 44 --
drivers/md/dm-verity-verify-sig.c | 129 ++
drivers/md/dm-verity-verify-sig.h | 32
5 files changed, 222 insertions(+), 8 deletions(-)
create mode 100644 drivers/md/dm-verity-verify-sig.c
create mode 100644 drivers/md/dm-verity-verify-sig.h
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index db269a348b20..da4115753f25 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -489,6 +489,29 @@ config DM_VERITY
If unsure, say N.
+config DM_VERITY_VERIFY_ROOTHASH_SIG
+ def_bool n
+ bool "Verity data device root hash signature verification support"
+ depends on DM_VERITY
+ select SYSTEM_DATA_VERIFICATION
+ help
+ The device mapper target created by DM-VERITY can be validated if the
+ pre-generated tree of cryptographic checksums passed has a pkcs#7
+ signature file that can validate the roothash of the tree.
+
+ If unsure, say N.
+
+config DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE
+ def_bool n
+ bool "Forces all dm verity data device root hash should be signed"
+ depends on DM_VERITY_VERIFY_ROOTHASH_SIG
+ help
+ The device mapper target created by DM-VERITY will succeed only if the
+ pre-generated tree of cryptographic checksums passed also has a pkcs#7
+ signature file that can validate the roothash of the tree.
+
+ If unsure, say N.
+
config DM_VERITY_FEC
bool "Verity forward error correction support"
depends on DM_VERITY
diff --git a/drivers/md/Makefile b/drivers/md/Makefile
index be7a6eb92abc..8a8c142bcfe1 100644
--- a/drivers/md/Makefile
+++ b/drivers/md/Makefile
@@ -61,7 +61,7 @@ obj-$(CONFIG_DM_LOG_USERSPACE)+= dm-log-userspace.o
obj-$(CONFIG_DM_ZERO) += dm-zero.o
obj-$(CONFIG_DM_RAID) += dm-raid.o
obj-$(CONFIG_DM_THIN_PROVISIONING) += dm-thin-pool.o
-obj-$(CONFIG_DM_VERITY)+= dm-verity.o
+obj-$(CONFIG_DM_VERITY)+= dm-verity.o dm-verity-verify-sig.o
Can we avoid building dm-verity-verify-sig.o when
DM_VERITY_VERIFY_ROOTHASH_SIG is not set?
obj-$(CONFIG_DM_CACHE) += dm-cache.o
obj-$(CONFIG_DM_CACHE_SMQ) += dm-cache-smq.o
obj-$(CONFIG_DM_ERA)+= dm-era.o
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index f4c31ffaa88e..53aebfa8bc38 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -16,7 +16,7 @@
#include "dm-verity.h"
#include "dm-verity-fec.h"
-
+#include "dm-verity-verify-sig.h"
#include
#include
@@ -34,7 +34,11 @@
#define DM_VERITY_OPT_IGN_ZEROES"ignore_zero_blocks"
#define DM_VERITY_OPT_AT_MOST_ONCE "check_at_most_once"
-#define DM_VERITY_OPTS_MAX (2 + DM_VERITY_OPTS_FEC)
+#define DM_VERITY_OPTS_MAX (2 + DM_VERITY_OPTS_FEC + \
+DM_VERITY_ROOT_HASH_VERIFICATION_OPTS)
It would be nice if DM_VERITY_OPTS_MAX would remain the same size as it
is now if DM_VERITY_VERIFY_ROOTHASH_SIG is not enabled.
+#define DM_VERITY_MANDATORY_ARGS10
This cleanup should be in a separate patch.
+
static unsigned dm_verity_prefetch_cluster = DM_VERITY_DEFAULT_PREFETCH_SIZE;
@@ -855,7 +859,8 @@ static int verity_alloc_zero_digest(struct dm_verity *v)
return r;
}
-static int verity_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v)
+static int verity_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,
+struct dm_verity_sig_opts *verify_args)
{
int r;
unsigned argc;
@@ -904,6 +909,15 @@ static int verity_parse_opt_args(struct dm_arg_set *as,
struct dm_v
Re: dm-region-hash: Fix a missing-check bug in __rh_alloc()
On Wed, Jun 05, 2019 at 08:21:59AM -0400, Mike Snitzer wrote:
> On Wed, Jun 05 2019 at 2:05am -0400,
> Jiri Slaby wrote:
>
> > On 24. 05. 19, 5:12, Gen Zhang wrote:
> > > In function __rh_alloc(), the pointer nreg is allocated a memory space
> > > via kmalloc(). And it is used in the following codes. However, when
> > > there is a memory allocation error, kmalloc() fails. Thus null pointer
> > > dereference may happen. And it will cause the kernel to crash. Therefore,
> > > we should check the return value and handle the error.
> > > Further, in __rh_find(), we should also check the return value and
> > > handle the error.
> > >
> > > Signed-off-by: Gen Zhang
> > >
> > > ---
> > > diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c
> > > index 1f76045..2fa1641 100644
> > > --- a/drivers/md/dm-region-hash.c
> > > +++ b/drivers/md/dm-region-hash.c
> > > @@ -290,8 +290,11 @@ static struct dm_region *__rh_alloc(struct
> > > dm_region_hash *rh, region_t region)
> > > struct dm_region *reg, *nreg;
> > >
> > > nreg = mempool_alloc(&rh->region_pool, GFP_ATOMIC);
> > > - if (unlikely(!nreg))
> > > + if (unlikely(!nreg)) {
> > > nreg = kmalloc(sizeof(*nreg), GFP_NOIO | __GFP_NOFAIL);
> > > + if (!nreg)
> > > + return NULL;
> >
> > What's the purpose of checking NO_FAIL allocations?
>
> There isn't, that was already pointed out in a different thread for this
> same patch (think patch was posted twice):
> https://www.redhat.com/archives/dm-devel/2019-May/msg00124.html
>
> Mike
Thanks for your reply. The first thread is not replied for a period, so
the second one is posted. But I don't know why Jiri replied to the first
thread.
Thanks
Gen
Re: [dm-devel] Automatic blacklisting of NVMe devices if NVMe native MP
On Tue, Jun 04 2019 at 3:29am -0400, Eyal Ben-David wrote: >Hi all, > >Is it possible to automatically blacklist all NVMe devices if the NVMe >driver has it's own multipath? > >I mean if for example if: > >cat /sys/module/nvme_core/parameters/multipath >Y > >then device mapper would automatically blacklist all NVMe devices to avoid >unexpected consequences. The native NVMe multipath device would only look to have one path from above. So multipath shouldn't even pick up these native NVMe multipath devices. And in addition, IIRC, multipath-tools has been trained to at least recognize native NVMe multipath device and displays useful info about them. Have you seen an actual problem? What versions of kernel and multipath-tools are you using? Mike -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH v2] dm log writes: make sure the log super sectors are written in order
Currently, although we submit super bios in log-write thread orderly
(the super.nr_entries is incremented by each logged entry), the
submit_bio() cannot make sure that each super sector is written to log
device in order. So the submitting bio of each super sector may be
out-of-order, and then the final nr_entries maybe small than the real
entries submitted.
This problem can be reproduced by the xfstests generic/455 with ext4,
which may complained below after running the test:
QA output created by 455
-Silence is golden
+mark 'end' does not exist
This patch serialize submitting super secotrs to make sure each super
sectors are written to log disk in order, so that we can prevent the
latest nr_entries be rewritten by some old super bios.
Signed-off-by: zhangyi (F)
Suggested-by: Josef Bacik
---
Changes since v1:
- Switch to use completion instead of wait_queue to synchronize
submitting super bios.
drivers/md/dm-log-writes.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-log-writes.c b/drivers/md/dm-log-writes.c
index 9ea2b02..4854246 100644
--- a/drivers/md/dm-log-writes.c
+++ b/drivers/md/dm-log-writes.c
@@ -60,6 +60,7 @@
#define WRITE_LOG_VERSION 1ULL
#define WRITE_LOG_MAGIC 0x6a736677736872ULL
+#define WRITE_LOG_SUPER_SECTOR 0
/*
* The disk format for this is braindead simple.
@@ -115,6 +116,7 @@ struct log_writes_c {
struct list_head logging_blocks;
wait_queue_head_t wait;
struct task_struct *log_kthread;
+ struct completion super_done;
};
struct pending_block {
@@ -180,6 +182,15 @@ static void log_end_io(struct bio *bio)
bio_put(bio);
}
+static void log_end_super(struct bio *bio)
+{
+ struct log_writes_c *lc = bio->bi_private;
+
+ /* Wake up log-write kthread that super has been written */
+ complete(&lc->super_done);
+ log_end_io(bio);
+}
+
/*
* Meant to be called if there is an error, it will free all the pages
* associated with the block.
@@ -215,7 +226,8 @@ static int write_metadata(struct log_writes_c *lc, void
*entry,
bio->bi_iter.bi_size = 0;
bio->bi_iter.bi_sector = sector;
bio_set_dev(bio, lc->logdev->bdev);
- bio->bi_end_io = log_end_io;
+ bio->bi_end_io = (sector == WRITE_LOG_SUPER_SECTOR) ?
+ log_end_super : log_end_io;
bio->bi_private = lc;
bio_set_op_attrs(bio, REQ_OP_WRITE, 0);
@@ -418,11 +430,19 @@ static int log_super(struct log_writes_c *lc)
super.nr_entries = cpu_to_le64(lc->logged_entries);
super.sectorsize = cpu_to_le32(lc->sectorsize);
- if (write_metadata(lc, &super, sizeof(super), NULL, 0, 0)) {
+ if (write_metadata(lc, &super, sizeof(super), NULL, 0,
+ WRITE_LOG_SUPER_SECTOR)) {
DMERR("Couldn't write super");
return -1;
}
+ /*
+* Super sector should be writen in-order, or else the
+* nr_entries could be rewritten by the old bio and small
+* than the real submitted entries.
+*/
+ wait_for_completion_io(&lc->super_done);
+
return 0;
}
@@ -531,6 +551,7 @@ static int log_writes_ctr(struct dm_target *ti, unsigned
int argc, char **argv)
INIT_LIST_HEAD(&lc->unflushed_blocks);
INIT_LIST_HEAD(&lc->logging_blocks);
init_waitqueue_head(&lc->wait);
+ init_completion(&lc->super_done);
atomic_set(&lc->io_blocks, 0);
atomic_set(&lc->pending_blocks, 0);
--
2.7.4
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Re: dm-region-hash: Fix a missing-check bug in __rh_alloc()
On Wed, Jun 05 2019 at 2:05am -0400,
Jiri Slaby wrote:
> On 24. 05. 19, 5:12, Gen Zhang wrote:
> > In function __rh_alloc(), the pointer nreg is allocated a memory space
> > via kmalloc(). And it is used in the following codes. However, when
> > there is a memory allocation error, kmalloc() fails. Thus null pointer
> > dereference may happen. And it will cause the kernel to crash. Therefore,
> > we should check the return value and handle the error.
> > Further, in __rh_find(), we should also check the return value and
> > handle the error.
> >
> > Signed-off-by: Gen Zhang
> >
> > ---
> > diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c
> > index 1f76045..2fa1641 100644
> > --- a/drivers/md/dm-region-hash.c
> > +++ b/drivers/md/dm-region-hash.c
> > @@ -290,8 +290,11 @@ static struct dm_region *__rh_alloc(struct
> > dm_region_hash *rh, region_t region)
> > struct dm_region *reg, *nreg;
> >
> > nreg = mempool_alloc(&rh->region_pool, GFP_ATOMIC);
> > - if (unlikely(!nreg))
> > + if (unlikely(!nreg)) {
> > nreg = kmalloc(sizeof(*nreg), GFP_NOIO | __GFP_NOFAIL);
> > + if (!nreg)
> > + return NULL;
>
> What's the purpose of checking NO_FAIL allocations?
There isn't, that was already pointed out in a different thread for this
same patch (think patch was posted twice):
https://www.redhat.com/archives/dm-devel/2019-May/msg00124.html
Mike
Re: [dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device
Dne 04. 06. 19 v 21:35 Stephen Boyd napsal(a): Quoting Helen Koike (2019-06-04 10:38:59) On 6/3/19 8:02 PM, Stephen Boyd wrote: I'm trying to boot a mainline linux kernel on a chromeos device with dm verity and a USB stick but it's not working for me even with this patch. I've had to hack around two problems: 1) rootwait isn't considered 2) verity doesn't seem to accept UUID for or For the first problem, it happens every boot for me because I'm trying to boot off of a USB stick and it's behind a hub that takes a few seconds to enumerate. If I hack up the code to call dm_init_init() after the 'rootdelay' cmdline parameter is used then I can make this work. It would be much nicer if the whole mechanism didn't use a late initcall though. If it used a hook from prepare_namespace() and then looped waiting for devices to create when rootwait was specified it would work. The patch was implemented with late initcall partially to be contained in drivers/md/*, but to support rootwait, adding a hook from prepare_namespace seems the way to go indeed. Alright, great. The second problem is that in chromeos we have the bootloader fill out the UUID of the kernel partition (%U) and then we have another parameter that indicates the offset from that kernel partition to add to the kernel partition (typically 1, i.e. PARTNROFF=1) to find the root filesystem partition. The way verity seems to work here is that we need to specify a path like /dev/sda3 or the major:minor number of the device Hi As not a direct dm developer - isn't this going a bit too far ? - This way you will need to soon move halve of the userspace functionality into kernel space. IMHO would be way more progressive to start using initramdisk and let userspace resolve all the issue. Clearly once you start to wait for some 'devices' to appear - then you will need to way for CORRECT device as well - since sda,sdb... goes in random order, so you would need to parse disk headers and so on. What you are effectively doing at this moment is you are shifting/ballooning 'ramdisk' code into kernel image - just to be named a kernel. So why it is so big deal to start to use ramdisk on ChromeOS? That would have solved most of problems you have or you will have instantly. Regards Zdenek
Re: [dm-devel] dm log writes: make sure the log super sectors are written in order
On 2019/6/4 3:02, Josef Bacik Wrote:
> On Mon, Jun 03, 2019 at 10:46:08AM -0400, Mike Snitzer wrote:
>> On Mon, Jun 03 2019 at 10:18am -0400,
>> zhangyi (F) wrote:
>>
>>> Currently, although we submit super bios in log-write thread orderly
>>> (the super.nr_entries is incremented by each logged entry), the
>>> submit_bio() cannot make sure that each super sector is written to log
>>> device in order. So the submitting bio of each super sector may be
>>> out-of-order, and then the final nr_entries maybe small than the real
>>> entries submitted.
>>>
>>> This problem can be reproduced by the xfstests generic/455 with ext4,
>>> which may complained below after running the test:
>>>
>>> QA output created by 455
>>> -Silence is golden
>>> +mark 'end' does not exist
>>>
>>> This patch serialize submitting super secotrs to make sure each super
>>> sectors are written to log disk in order.
>>>
>>> Signed-off-by: zhangyi (F)
>>
>> This doesn't feel right.
>>
>> You raised 2 things you're trying to address:
>> 1) IO is out of order
>> 2) accounting (nr_entries) isn't correct
>>
>> I'll need to reviewer closer but serializing "super" bios doesn't seem
>> like the best fix.
>>
>> Josef, any chance you can weigh in on this? AFAIK you are still "the
>> man" for dm-log-writes ;)
>>
>
> Well the #2 is caused by #1, we submit the bio for a super two times in a row
> and it's a crapshoot which one makes it to disk. So he's right, and it's kind
> of funny because this is the sort of problem that dm-log-writes was written to
> catch, and I fucked it up here ;). That being said this is a bit
> over-engineered, can we just add a completion to the log buff and do a
> wait_for_completion() when we're writing out the super? It's not like this
> thing
> needs to be super performant. Thanks,
>
Hi, Josef
Thanks for your suggestions. It's fine by me to switch to use completion
instead. Some thing like this?
...
@@ -180,6 +182,15 @@ static void log_end_io(struct bio *bio)
bio_put(bio);
}
+static void log_end_super(struct bio *bio)
+{
+ struct log_writes_c *lc = bio->bi_private;
+
+ /* Wake up log-write kthread that super has been written */
+ complete(&lc->super_comp);
+ log_end_io(bio);
+}
+
/*
* Meant to be called if there is an error, it will free all the pages
* associated with the block.
@@ -215,7 +226,8 @@ static int write_metadata(struct log_writes_c *lc, void
*entry,
bio->bi_iter.bi_size = 0;
bio->bi_iter.bi_sector = sector;
bio_set_dev(bio, lc->logdev->bdev);
- bio->bi_end_io = log_end_io;
+ bio->bi_end_io = (sector == WRITE_LOG_SUPER_SECTOR) ?
+ log_end_super : log_end_io;
bio->bi_private = lc;
bio_set_op_attrs(bio, REQ_OP_WRITE, 0);
@@ -418,11 +430,19 @@ static int log_super(struct log_writes_c *lc)
super.nr_entries = cpu_to_le64(lc->logged_entries);
super.sectorsize = cpu_to_le32(lc->sectorsize);
- if (write_metadata(lc, &super, sizeof(super), NULL, 0, 0)) {
+ if (write_metadata(lc, &super, sizeof(super), NULL, 0,
+ WRITE_LOG_SUPER_SECTOR)) {
DMERR("Couldn't write super");
return -1;
}
+ /*
+* Super sector should be writen in-order, or else the
+* nr_entries could be rewritten by the old bio and small
+* than the real submitted entries.
+*/
+ wait_for_completion_io(&lc->super_comp);
+
return 0;
}
...
But one thing need to mention is that, IIUC, If we use completion, the
log_writes_kthread have to wait on writing out every super bio, so it cannot
keep on submitting subsequent log bios. It maybe more performance impact
than my v1 (it only wait on previous super if it was not finished).
Thanks,
Yi.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH] dm log writes: make sure the log super sectors are written in order
Currently, although we submit super bios in log-write thread orderly
(the super.nr_entries is incremented by each logged entry), the
submit_bio() cannot make sure that each super sector is written to log
device in order. So the submitting bio of each super sector may be
out-of-order, and then the final nr_entries maybe small than the real
entries submitted.
This problem can be reproduced by the xfstests generic/455 with ext4,
which may complained below after running the test:
QA output created by 455
-Silence is golden
+mark 'end' does not exist
This patch serialize submitting super secotrs to make sure each super
sectors are written to log disk in order.
Signed-off-by: zhangyi (F)
---
drivers/md/dm-log-writes.c | 56 --
1 file changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-log-writes.c b/drivers/md/dm-log-writes.c
index 9ea2b02..37088c7 100644
--- a/drivers/md/dm-log-writes.c
+++ b/drivers/md/dm-log-writes.c
@@ -60,6 +60,7 @@
#define WRITE_LOG_VERSION 1ULL
#define WRITE_LOG_MAGIC 0x6a736677736872ULL
+#define WRITE_LOG_SUPER_SECTOR 0
/*
* The disk format for this is braindead simple.
@@ -115,6 +116,8 @@ struct log_writes_c {
struct list_head logging_blocks;
wait_queue_head_t wait;
struct task_struct *log_kthread;
+ bool submitting_super;
+ wait_queue_head_t wait_super;
};
struct pending_block {
@@ -180,6 +183,34 @@ static void log_end_io(struct bio *bio)
bio_put(bio);
}
+static void log_end_super(struct bio *bio)
+{
+ struct log_writes_c *lc = bio->bi_private;
+ unsigned long flags;
+
+ spin_lock_irqsave(&lc->blocks_lock, flags);
+ if (bio->bi_status) {
+ DMERR("Error writing super block, error=%d",
+ bio->bi_status);
+ lc->logging_enabled = false;
+ }
+
+ WARN_ON(!lc->submitting_super);
+ lc->submitting_super = false;
+ spin_unlock_irqrestore(&lc->blocks_lock, flags);
+
+ /*
+* Wake up log-write kthread that previous super sector has
+* been written to disk.
+*/
+ if (waitqueue_active(&lc->wait_super))
+ wake_up(&lc->wait_super);
+
+ bio_free_pages(bio);
+ put_io_block(lc);
+ bio_put(bio);
+}
+
/*
* Meant to be called if there is an error, it will free all the pages
* associated with the block.
@@ -215,7 +246,8 @@ static int write_metadata(struct log_writes_c *lc, void
*entry,
bio->bi_iter.bi_size = 0;
bio->bi_iter.bi_sector = sector;
bio_set_dev(bio, lc->logdev->bdev);
- bio->bi_end_io = log_end_io;
+ bio->bi_end_io = (sector == WRITE_LOG_SUPER_SECTOR) ?
+ log_end_super : log_end_io;
bio->bi_private = lc;
bio_set_op_attrs(bio, REQ_OP_WRITE, 0);
@@ -418,7 +450,25 @@ static int log_super(struct log_writes_c *lc)
super.nr_entries = cpu_to_le64(lc->logged_entries);
super.sectorsize = cpu_to_le32(lc->sectorsize);
- if (write_metadata(lc, &super, sizeof(super), NULL, 0, 0)) {
+ /*
+* Super sector should be writen in-order, or else the
+* nr_entries could be small than the real submitted entries.
+* So wait previous super sector submitted here.
+*/
+ if (!lc->submitting_super)
+ goto write_super;
+
+ spin_lock_irq(&lc->blocks_lock);
+ if (!lc->submitting_super) {
+ spin_unlock_irq(&lc->blocks_lock);
+ goto write_super;
+ }
+ spin_unlock_irq(&lc->blocks_lock);
+ wait_event(lc->wait_super, !lc->submitting_super);
+write_super:
+ lc->submitting_super = true;
+ if (write_metadata(lc, &super, sizeof(super), NULL, 0,
+ WRITE_LOG_SUPER_SECTOR)) {
DMERR("Couldn't write super");
return -1;
}
@@ -531,6 +581,7 @@ static int log_writes_ctr(struct dm_target *ti, unsigned
int argc, char **argv)
INIT_LIST_HEAD(&lc->unflushed_blocks);
INIT_LIST_HEAD(&lc->logging_blocks);
init_waitqueue_head(&lc->wait);
+ init_waitqueue_head(&lc->wait_super);
atomic_set(&lc->io_blocks, 0);
atomic_set(&lc->pending_blocks, 0);
@@ -570,6 +621,7 @@ static int log_writes_ctr(struct dm_target *ti, unsigned
int argc, char **argv)
lc->logging_enabled = true;
lc->end_sector = logdev_last_sector(lc);
lc->device_supports_discard = true;
+ lc->submitting_super = false;
ti->num_flush_bios = 1;
ti->flush_supported = true;
--
2.7.4
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
