Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1717435

Summary: Uncaught assertion error when given too small physical size in dmsetup table
Product: Red Hat Enterprise Linux 8 Reporter: Jakub Krysl <jkrysl>
Component: kmod-kvdoAssignee: sclafani
Status: CLOSED ERRATA QA Contact: vdo-qe
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: awalsh, bgurney, jkrysl
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 6.2.1.129 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-05 22:12:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jakub Krysl 2019-06-05 13:18:17 UTC 
Description of problem:
While working on a reproducer for different BZ, I hit uncaught assertion error:

# vdoformat /dev/sdc
Logical blocks defaulted to 2435905347 blocks.

# dmsetup create vdo0 --table "0 41943040 vdo V2 /dev/sdc 23592704 4096 32768 16380 off auto vdo0 hash 1 logical 3 physical 2"
device-mapper: reload ioctl on vdo0  failed: Input/output error
Command failed.

[ 1201.745015] uds: kvdo2:journalQ: assertion "Physical size 2441609216 in super block smaller than expected size 23592704" (config->physicalBlocks <= blockCount) failed at /builddir/build/BUILD/kvdo-8834a38068c5258584513541b965538fecdf6b80/obj/./vdo/base/vdo.c:605
[ 1201.768195] uds: kvdo2:journalQ: [backtrace]
[ 1201.772474] CPU: 45 PID: 13516 Comm: kvdo2:journalQ Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-94.el8.x86_64 #1
[ 1201.784285] Hardware name: Supermicro AS -2023US-TR4/H11DSU-iN, BIOS 1.1a 04/26/2018
[ 1201.792023] Call Trace:
[ 1201.794490]  dump_stack+0x5c/0x80
[ 1201.797824]  assertionFailed+0x4f/0x70 [uds]
[ 1201.802114]  ? decodeVersionNumber+0x12/0x30 [kvdo]
[ 1201.807006]  ? decodeVDOComponent+0x15d/0x200 [kvdo]
[ 1201.811980]  validateVDOConfig+0x28a/0x3d0 [kvdo]
[ 1201.816698]  loadVDOComponents+0x3e/0x3d0 [kvdo]
[ 1201.821333]  workQueueRunner+0x1b9/0x660 [kvdo]
[ 1201.825871]  ? finish_wait+0x80/0x80
[ 1201.829462]  ? vdoPoolRelease+0x30/0x30 [kvdo]
[ 1201.833910]  kthread+0x112/0x130
[ 1201.837138]  ? kthread_bind+0x30/0x30
[ 1201.840805]  ret_from_fork+0x22/0x40
[ 1201.844393] kvdo2:journalQ: aborting load: kvdo: Parameters have conflicting values (2060)
[ 1201.852711] kvdo2:dmsetup: Could not start kernel physical layer. (VDO error 2060, message Cannot load metadata from device)
[ 1201.866209] device-mapper: table: 253:0: vdo: Cannot load metadata from device
[ 1201.873438] device-mapper: ioctl: error adding target to table


Version-Release number of selected component (if applicable):
kmod-kvdo-6.2.1.48-53.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1.vdoformat /dev/sdc
2.dmsetup create vdo0 --table "0 41943040 vdo V2 /dev/sdc 23592704 4096 32768 16380 off auto vdo0 hash 1 logical 3 physical 2"

Actual results:
call trace of assertion error

Expected results:
no call trace

Additional info:
Comment 1 Bryan Gurney 2019-06-05 14:11:58 UTC 
I was able to reproduce the scenario on my test system:

$ sudo vdoformat /dev/sdb
Logical blocks defaulted to 120879344 blocks

120979344 4096-byte blocks is equivalent to 967034752 512-byte sectors; this will be needed for the "dmsetup table" entry.

To find the proper physical size, use "vdodumpconfig <device>" to read the VDO config from the superblock:

$ sudo vdodumpconfig /dev/sdb
VDOConfig:
  blockSize: 4096
  logicalBlocks: 120879344
  physicalBlocks: 122096646
...

Using these parameters, construct the device-mapper table entry:

$ sudo modprobe kvdo
$ sudo dmsetup create vdo0 --table '0 967034752 vdo V2 /dev/sdb 122096646 4096 32768 16380 off auto vdo0 hash 1 logical 3 physical 2'

This completes successfully:

Jun 05 09:36:14 localhost.localdomain kernel: kvdo0:dmsetup: starting device 'vdo0'
Jun 05 09:36:14 localhost.localdomain kernel: kvdo0:dmsetup: zones: 3 logical, 2 physical, 1 hash; base threads: 8
Jun 05 09:36:14 localhost.localdomain kernel: kvdo0:journalQ: VDO commencing normal operation


But if I "accidentally" divide the physical size by 100, I can see the error:

$ sudo dmsetup create vdo0 --table '0 967034752 vdo V2 /dev/sdb 1220966 4096 32768 16380 off auto vdo0 hash 1 logical 3 physical 2'
device-mapper: reload ioctl on vdo0  failed: Input/output error
Command failed.

Jun 05 10:00:02 localhost.localdomain kernel: kvdo1:dmsetup: starting device 'vdo0'
Jun 05 10:00:02 localhost.localdomain kernel: kvdo1:dmsetup: zones: 3 logical, 2 physical, 1 hash; base threads: 8
Jun 05 10:00:02 localhost.localdomain kernel: uds: kvdo1:journalQ: assertion "Physical size 122096646 in super block smaller than expected size 1220966" (config->physicalBlocks <= blockCount) failed at /builddir/build/BUILD/kvdo-8df6805f0c4eddae59c9edcebeeab885c835f93c/obj/./vdo/base/vdo.c:629
Jun 05 10:00:02 localhost.localdomain kernel: uds: kvdo1:journalQ: [backtrace]
Jun 05 10:00:02 localhost.localdomain kernel: CPU: 9 PID: 11293 Comm: kvdo1:journalQ Kdump: loaded Tainted: G           O     ---------r-  - 4.18.0-80.1.2.el8_0.x86_64 #1
Jun 05 10:00:02 localhost.localdomain kernel: Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 3.2a 07/09/2015
Jun 05 10:00:02 localhost.localdomain kernel: Call Trace:
Jun 05 10:00:02 localhost.localdomain kernel:  dump_stack+0x5c/0x80
Jun 05 10:00:02 localhost.localdomain kernel:  assertionFailed+0x4f/0x70 [uds]
Jun 05 10:00:02 localhost.localdomain kernel:  ? decodeVersionNumber+0x12/0x30 [kvdo]
Jun 05 10:00:02 localhost.localdomain kernel:  ? decodeVDOComponent+0x15d/0x200 [kvdo]
Jun 05 10:00:02 localhost.localdomain kernel:  validateVDOConfig+0x28a/0x3d0 [kvdo]
Jun 05 10:00:02 localhost.localdomain kernel:  loadVDOComponents+0x40/0x3d0 [kvdo]
Jun 05 10:00:02 localhost.localdomain kernel:  workQueueRunner+0x1b9/0x660 [kvdo]
Jun 05 10:00:02 localhost.localdomain kernel:  ? finish_wait+0x80/0x80
Jun 05 10:00:02 localhost.localdomain kernel:  ? initKernelVDOOnce+0x20/0x20 [kvdo]
Jun 05 10:00:02 localhost.localdomain kernel:  kthread+0x112/0x130
Jun 05 10:00:02 localhost.localdomain kernel:  ? kthread_bind+0x30/0x30
Jun 05 10:00:02 localhost.localdomain kernel:  ret_from_fork+0x35/0x40
Jun 05 10:00:02 localhost.localdomain kernel: kvdo1:journalQ: aborting load: kvdo: Parameters have conflicting values (2060)
Jun 05 10:00:02 localhost.localdomain kernel: kvdo1:dmsetup: Could not start kernel physical layer. (VDO error 2060, message Cannot load metadata from device)
Jun 05 10:00:02 localhost.localdomain kernel: kvdo1:dmsetup: mapToSystemError: mapping internal status code 2060 (kvdo: VDO_PARAMETER_MISMATCH: kvdo: Parameters have conflicting values) to EIO
Jun 05 10:00:02 localhost.localdomain kernel: device-mapper: table: 253:3: vdo: Cannot load metadata from device
Jun 05 10:00:02 localhost.localdomain kernel: device-mapper: ioctl: error adding target to table
Comment 2 sclafani 2019-07-24 00:00:55 UTC 
Eliminated the backtrace and improved the wording of the log message.
Comment 4 Jakub Krysl 2019-08-21 07:34:03 UTC 
kmod-kvdo-6.2.1.134-56.el8

Aug 21 09:32:15 storageqe-90 kernel: kvdo792:dmsetup: underlying device, REQ_FLUSH: supported, REQ_FUA: supported
Aug 21 09:32:15 storageqe-90 kernel: kvdo792:dmsetup: Using write policy async automatically.
Aug 21 09:32:15 storageqe-90 kernel: kvdo792:dmsetup: loading device 'vdo0'
Aug 21 09:32:15 storageqe-90 kernel: kvdo792:dmsetup: zones: 3 logical, 2 physical, 1 hash; base threads: 8
Aug 21 09:32:15 storageqe-90 kernel: kvdo792:journal: A physical size of 23592704 blocks was specified, but that is smaller than the 2441609216 blocks configured in the VDO super block
Aug 21 09:32:15 storageqe-90 kernel: kvdo792:journal: aborting load: kvdo: Parameters have conflicting values (2060)
Aug 21 09:32:15 storageqe-90 kernel: kvdo792:dmsetup: Could not start kernel physical layer. (VDO error 2060, message Cannot load metadata from device)
Aug 21 09:32:15 storageqe-90 kernel: kvdo792:dmsetup: mapToSystemError: mapping internal status code 2060 (kvdo: VDO_PARAMETER_MISMATCH: kvdo: Parameters have conflicting values) to EIO
Aug 21 09:32:15 storageqe-90 kernel: device-mapper: table: 253:0: vdo: Cannot load metadata from device
Aug 21 09:32:15 storageqe-90 kernel: device-mapper: ioctl: error adding target to table
Comment 7 errata-xmlrpc 2019-11-05 22:12:41 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3548