Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1511587 - Creating VDO on top of VDO spams "kvdo347:dedupeQ: kvdoMapBio called from within a VDO thread!"
Summary: Creating VDO on top of VDO spams "kvdo347:dedupeQ: kvdoMapBio called from wit...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kmod-kvdo
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Ken Raeburn
QA Contact: Jakub Krysl
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-09 15:54 UTC by Jakub Krysl
Modified: 2018-04-10 16:26 UTC (History)
5 users (show)

Fixed In Version: 6.1.0.121
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 16:25:27 UTC


Attachments (Terms of Use)
Console logs (deleted)
2017-11-09 15:54 UTC, Jakub Krysl
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0900 None None None 2018-04-10 16:26:06 UTC

Description Jakub Krysl 2017-11-09 15:54:19 UTC
Created attachment 1349997 [details]
Console logs

Description of problem:
When creating VDO directly on top of existing VDO, console is spammed with message "kvdo347:dedupeQ: kvdoMapBio called from within a VDO thread!". The VDO is actually succesfully created:

# vdo create --device /dev/mapper/vdo --name vdo2 --verbose
Creating VDO vdo2
    modprobe kvdo
    vdoformat --uds-checkpoint-frequency=0 --uds-memory-size=0.25 /dev/mapper/vdo
    vdodumpconfig /dev/mapper/vdo
Starting VDO vdo2
    dmsetup status vdo2
    modprobe kvdo
    dmsetup create vdo2 --table '0 11721045168 dedupe /dev/mapper/vdo 4096 disabled 0 32768 16380 on sync vdo2 ack=1,bio=4,bioRotationInterval=64,cpu=2,hash=1,logical=1,physical=1'
    dmsetup status vdo2
Starting compression on VDO vdo2
    dmsetup message vdo2 0 compression on
    dmsetup status vdo2
VDO instance 348 volume is ready at /dev/mapper/vdo2

Attaching console log as it is too long.

Using kmod-kvdo component as it is produced by kvdo.

Version-Release number of selected component (if applicable):
vdo 6.1.0.34-8

How reproducible:
100%

Steps to Reproduce:
1.vdo create --device DEVICE --name VDO
2.vdo create --device /dev/mapper/VDO --name VDO2

Actual results:
VDO created, spam in console

Expected results:
Not allowed / no spam

Additional info:

Comment 3 Ken Raeburn 2017-12-12 21:07:56 UTC
Eliminating the messages entirely isn't a good idea, as they're trying to warn about a potential deadlock situation, but the current test isn't strict enough, and as noted will complain about one VDO device atop another.

There are some relatively easy improvements we could put in: Throttling the messages to once per second would be fairly easy. Having the "vdo" script check the storage device and its slaves recursively (to catch a VDO-LVM-VDO stacking) wouldn't be hard either but updated test cases will take a little time to put together.

Actually making the in-kernel test stricter would be preferable, but will take a while to implement, and there may be a small performance impact for VDO-on-VDO stacking.

Comment 4 Ken Raeburn 2018-01-16 20:44:59 UTC
Turns out not to have taken as much work as I thought, I just had to add a tiny abstraction break... There shouldn't be a performance impact with the approach I settled on.

Comment 6 Jakub Krysl 2018-01-22 13:13:05 UTC
Tested with vdo-6.1.0.124 and could not hit the message with VDO on top of VDO. 

Before I set this to verified, I would like to try to hit the deadlock situation to see if the message can be triggered. Ken, do you know of any reproducer of such situation?
Thanks

Comment 7 Ken Raeburn 2018-01-23 10:28:40 UTC
The Permabit perl test suite does have a test that triggers it, called DeadlockAvoidance01 in our suite. It uses a couple custom device-mapper targets to get the behavior we want to test. It might be possible to trigger with only one hand-crafted DM target; I haven't tried rewriting it that way.

Unfortunately I don't have a reproducer without specialized kernel modules.

Comment 8 Jakub Krysl 2018-01-23 10:42:08 UTC
So the message is gone in the situation mentioned in this BZ and still appears in the test designed to trigger it, so the basic functionality is not gone.
Thanks Ken,
setting to verified.

Comment 11 errata-xmlrpc 2018-04-10 16:25:27 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/RHEA-2018:0900


Note You need to log in before you can comment on or make changes to this bug.