[dm-devel] [PATCH] kpartx.rules: Fix syntax error in skip_kpartx code

2017-06-23 Thread Martin Wilck 
Fixes: 22736419 "kpartx.rules: respect skip_kpartx flag"
Signed-off-by: Martin Wilck 
---
 kpartx/kpartx.rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kpartx/kpartx.rules b/kpartx/kpartx.rules
index a9587917..64d550de 100644
--- a/kpartx/kpartx.rules
+++ b/kpartx/kpartx.rules
@@ -37,7 +37,7 @@ ENV{ID_FS_USAGE}=="filesystem|other", 
ENV{ID_FS_LABEL_ENC}=="?*", \
 # Create dm tables for partitions
 ENV{DM_ACTION}=="PATH_FAILED|PATH_REINSTATED", GOTO="kpartx_end"
 ENV{DM_NR_VALID_PATHS}=="0", GOTO="kpartx_end"
-ENV{ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG1"
+ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG1"
 ENV{DM_SUBSYSTEM_UDEV_FLAG1}=="1", GOTO="kpartx_end"
 ENV{DM_STATE}!="SUSPENDED", ENV{DM_UUID}=="mpath-*", \
RUN+="/sbin/kpartx -un -p -part /dev/$name"
-- 
2.13.1

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH] multipath-tools: move up TEMPLATE in hwtable

2017-06-23 Thread Xose Vazquez Perez 
and the 'MD Series' comment to the right place.

Cc: Christophe Varoqui 
Cc: device-mapper development 
Signed-off-by: Xose Vazquez Perez 
---
 libmultipath/hwtable.c | 98 +-
 1 file changed, 50 insertions(+), 48 deletions(-)

diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index 390d143..a77da7e 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -26,6 +26,55 @@
  * Moreover, if a device needs a special treatment by the SCSI
  * subsystem it should be included in drivers/scsi/scsi_devinfo.c
  */
+
+#if 0
+   /*
+* Copy this TEMPLATE to add new hardware.
+*
+* Keep only mandatory(.vendor and .product) and modified attributes.
+* Attributes with default values must be removed.
+* .vendor, .product, .revision and .bl_product are POSIX Extended 
regex.
+*
+* COMPANY_NAME
+*
+* Maintainer : XXX
+* Mail : XXX
+*/
+   {
+   /* If product-ID is different from marketing name add a comment 
*/
+   .vendor= "VENDOR",
+   .product   = "PRODUCT",
+   .revision  = "REVISION",
+   .bl_product= "BL_PRODUCT",
+   .pgpolicy  = FAILOVER,
+   .uid_attribute = "ID_SERIAL",
+   .selector  = "service-time 0",
+   .checker_name  = TUR,
+   .alias_prefix  = "mpath",
+   .features  = "0",
+   .hwhandler = "0",
+   .prio_name = PRIO_CONST,
+   .prio_args = "",
+   .pgfailback= -FAILBACK_MANUAL,
+   .rr_weight = RR_WEIGHT_NONE,
+   .no_path_retry = NO_PATH_RETRY_UNDEF,
+   .minio = 1000,
+   .minio_rq  = 1,
+   .flush_on_last_del = FLUSH_DISABLED,
+   .user_friendly_names = USER_FRIENDLY_NAMES_OFF,
+   .fast_io_fail  = 5,
+   .dev_loss  = 600,
+   .retain_hwhandler = RETAIN_HWHANDLER_ON,
+   .detect_prio   = DETECT_PRIO_ON,
+   .detect_checker = DETECT_CHECKER_ON,
+   .deferred_remove = DEFERRED_REMOVE_OFF,
+   .delay_watch_checks = DELAY_CHECKS_OFF,
+   .delay_wait_checks = DELAY_CHECKS_OFF,
+   .skip_kpartx   = SKIP_KPARTX_OFF,
+   .max_sectors_kb = MAX_SECTORS_KB_UNDEF,
+   },
+#endif
+
 static struct hwentry default_hw[] = {
/*
 * Apple
@@ -224,8 +273,8 @@ static struct hwentry default_hw[] = {
.pgpolicy  = MULTIBUS,
.no_path_retry = NO_PATH_RETRY_QUEUE,
},
-   /* MD Series */
{
+   /* MD Series */
.vendor= "DELL",
.product   = "^MD3",
.bl_product= "Universal Xport",
@@ -1059,53 +1108,6 @@ static struct hwentry default_hw[] = {
.checker_name  = DIRECTIO,
.retain_hwhandler = RETAIN_HWHANDLER_OFF,
},
-#if 0
-   /*
-* Copy this TEMPLATE to add new hardware.
-*
-* Keep only mandatory(.vendor and .product) and modified attributes.
-* Attributes with default values must be removed.
-* .vendor, .product, .revision and .bl_product are POSIX Extended 
regex.
-*
-* COMPANY_NAME
-*
-* Maintainer : XXX
-* Mail : XXX
-*/
-   {
-   /* If product-ID is different from marketing name add a comment 
*/
-   .vendor= "VENDOR",
-   .product   = "PRODUCT",
-   .revision  = "REVISION",
-   .bl_product= "BL_PRODUCT",
-   .pgpolicy  = FAILOVER,
-   .uid_attribute = "ID_SERIAL",
-   .selector  = "service-time 0",
-   .checker_name  = TUR,
-   .alias_prefix  = "mpath",
-   .features  = "0",
-   .hwhandler = "0",
-   .prio_name = PRIO_CONST,
-   .prio_args = "",
-   .pgfailback= -FAILBACK_MANUAL,
-   .rr_weight = RR_WEIGHT_NONE,
-   .no_path_retry = NO_PATH_RETRY_UNDEF,
-   .minio = 1000,
-   .minio_rq  = 1,
-   .flush_on_last_del = FLUSH_DISABLED,
-   .user_friendly_names = USER_FRIENDLY_NAMES_OFF,
-   .fast_io_fail  = 5,
-   .dev_loss  = 600,
-   .retain_hwhandler = RETAIN_HWHANDLER_ON,
-   .detect_prio   = DETECT_PRIO_ON,
-   .detect_checker = DETECT_CHECKER_ON,
-   .deferred_remove = DEFERRED_REMOVE_OFF,
-   .delay_watch_checks = DELAY_CHECKS_OFF,
-   .delay_wait_checks =

Re: [dm-devel] [PATCH v4 09/11] libmultipath: retain_attached_hw_handler obsolete with 4.3+

2017-06-23 Thread Xose Vazquez Perez 
On 06/22/2017 04:59 PM, Martin Wilck wrote:

> Kernels 4.3 and newer (commit 1bab0de0 "dm-mpath, scsi_dh: don't
> let dm detach device handlers") imply "retain_attached_hw_handler yes".
> 
> Clarify this in the propsel code, log messages, and documentation.
> 
> Signed-off-by: Martin Wilck 
> Reviewed-by: Hannes Reinecke 
> ---
>  libmultipath/configure.c   |  3 ++-
>  libmultipath/dmparser.c|  3 ++-
>  libmultipath/propsel.c |  7 ++-
>  libmultipath/util.c| 36 
>  libmultipath/util.h|  2 ++
>  multipath/multipath.conf.5 | 15 +++
>  6 files changed, 59 insertions(+), 7 deletions(-)
[...]
> --- a/libmultipath/propsel.c
> +++ b/libmultipath/propsel.c
> @@ -628,7 +628,12 @@ int select_retain_hwhandler(struct config *conf, struct 
> multipath *mp)
>  
>   if (!VERSION_GE(conf->version, minv_dm_retain)) {
>   mp->retain_hwhandler = RETAIN_HWHANDLER_OFF;
> - origin = "(setting: WARNING, requires kernel version >= 1.5.0)";
> + origin = "(setting: WARNING, requires kernel dm-mpath version 
> >= 1.5.0)";
It would be more informative replace the dm-mpath version with the
kernel version. No one cares about subsystems versions.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH] multipath-tools: beautify path_latency.c code

2017-06-23 Thread Xose Vazquez Perez 
On 06/22/2017 06:59 PM, Bart Van Assche wrote:

> Why do you think this kind of changes is useful? Are you aware that
> whitespace-only changes are very annoying to anyone else who is preparing
> changes on the same file because such changes result in a huge number of
> annoying rebase conflicts?

Be consistent with the rest of the multipath-tools code. Have do you seen
the original and the patched file?
Cleanings like this were done before without troubles.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH] dm raid: fix oops on upgrading to extended superblock format

2017-06-23 Thread heinzm 
From: Heinz Mauelshagen 

When a RAID set was created on dm-raid version < 1.9.0
(old RAID superblock format), none of the new members of the
superblock have been set including the device sectors member
needed to support shrinking.

Don't access such member unconditionally.

Add respective comments.

Resolves: rhbz1464274

diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 7d89322..2e15623 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -1927,7 +1927,7 @@ struct dm_raid_superblock {
/
 * BELOW FOLLOW V1.9.0 EXTENSIONS TO THE PRISTINE SUPERBLOCK FORMAT!!!
 *
-* FEATURE_FLAG_SUPPORTS_V190 in the features member indicates that 
those exist
+* FEATURE_FLAG_SUPPORTS_V190 in the compat_features member indicates 
that those exist
 */
 
__le32 flags; /* Flags defining array states for reshaping */
@@ -2092,6 +2092,11 @@ static void super_sync(struct mddev *mddev, struct 
md_rdev *rdev)
sb->layout = cpu_to_le32(mddev->layout);
sb->stripe_sectors = cpu_to_le32(mddev->chunk_sectors);
 
+   /
+* BELOW FOLLOW V1.9.0 EXTENSIONS TO THE PRISTINE SUPERBLOCK FORMAT!!!
+*
+* FEATURE_FLAG_SUPPORTS_V190 in the compat_features member indicates 
that those exist
+*/
sb->new_level = cpu_to_le32(mddev->new_level);
sb->new_layout = cpu_to_le32(mddev->new_layout);
sb->new_stripe_sectors = cpu_to_le32(mddev->new_chunk_sectors);
@@ -2438,8 +2443,17 @@ static int super_validate(struct raid_set *rs, struct 
md_rdev *rdev)
mddev->bitmap_info.default_offset = mddev->bitmap_info.offset;
 
if (!test_and_clear_bit(FirstUse, >flags)) {
-   /* Retrieve device size stored in superblock to be prepared for 
shrink */
-   rdev->sectors = le64_to_cpu(sb->sectors);
+   /*
+* Retrieve rdev size stored in superblock to be prepared for 
shrink.
+*
+* Check extended superblock members present to
+* access the size member or it will not be set!
+*
+* https://bugzilla.redhat.com/1464274
+*/
+   if (le32_to_cpu(sb->compat_features) & 
FEATURE_FLAG_SUPPORTS_V190)
+   rdev->sectors = le64_to_cpu(sb->sectors);
+
rdev->recovery_offset = le64_to_cpu(sb->disk_recovery_offset);
if (rdev->recovery_offset == MaxSector)
set_bit(In_sync, >flags);
-- 
2.9.4

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] dm-crypt IV generation (summary)

2017-06-23 Thread Herbert Xu 
On Thu, May 18, 2017 at 01:40:38PM +0200, Ondrej Mosnacek wrote:
>
> > Actually I think this one can probably easily handled in the crypto
> > layer.  All we need is to add a multikey template that sits on top
> > of an underlying IV generator.  The multikey instance can then accept
> > a key length that is a multiple of the underlying key length.
> 
> I thought of that, too, but unfortunately with TCW the key structure is:
> 
> | KEY 1 | KEY 2 | ... | KEY n | IV SEED (size = IV size) | WHITENING
> (size = 16 bytes) |
> 
> So part of the key needs to be processed before it is split into multiple 
> keys.
> 
> Also with the LMK mode, there is a similar optional key appendix,
> which is of the same size as the other subkeys.

The format of the key isn't an issue.  Because we're writing this
from scratch.  We can change the format in any way we want, e.g.,
we could include the value n if we wanted in the key stream.

Yes dm-crypt would need to massage the key before passing it over
to the crypto layer, but that should be pretty easy.

> My point is that it doesn't make much sense to have a crypto API alg
> that calls get_random_bytes() as part of its implementation. IMHO,
> that might tempt HW drivers to replace it with some crappy
> alternatives, which wouldn't be good... Also, how would we test such
> alg with testmgr?

You are right.  There is no way we can judge the quality of a
hardware IV generator, just as there is no way to judge the quality
of hardware RNG without looking at its internal structure.

But that doesn't mean that we shouldn't support them if they exist.

In any case, this scenario already exists today with IPsec where
we have multiple hardware implementations that generate the IV.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH v6 0/2] IV Generation algorithms for dm-crypt

2017-06-23 Thread Herbert Xu 
Binoy Jayan  wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
> 
> Currently, the iv generation algorithms are implemented in dm-crypt.c. The 
> goal
> is to move these algorithms from the dm layer to the kernel crypto layer by
> implementing them as template ciphers so they can be used in relation with
> algorithms like aes, and with multiple modes like cbc, ecb etc. As part of 
> this
> patchset, the iv-generation code is moved from the dm layer to the crypto 
> layer
> and adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
> at a time. Each bio contains the in memory representation of physically
> contiguous disk blocks. Since the bio itself may not be contiguous in main
> memory, the dm layer sets up a chained scatterlist of these blocks split into
> physically contiguous segments in memory so that DMA can be performed.

There is currently a patch-set for fscrypt to add essiv support.  It
would be interesting to know whether your implementation of essiv
can also be used in that patchset.  That would confirm that we're on
the right track.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel