On 23/12/2020 22:48, Ignat Korchagin wrote: > Hi, > > Looks like a2b8b2d975673b1a50ab0bcce5d146b9335edfad broke the ability > to reload dm-crypt targets. Hi, yes, and it breaks completely cryptsetup reencryption and many other functions in cryptsetup. Nobody apparently tried cryptsetup tests that has a lot of dm-crypt regression tests. It easily detects this problem (at least 4 tests fail now). Mike, I think the patch above need to be reverted or fixed ASAP. (Also note that this is now part of API, see WQ_SYSFS doc!) You can easily reproduce this problem with recent cryptsetup (2.3.4 supports mentioned flags already - but it is generic problem with reload): # echo password | cryptsetup --type plain open <device> test # echo password | cryptsetup refresh --perf-no_read_workqueue test device-mapper: reload ioctl on failed: Cannot allocate memory While with WQ_SYSFS flag removed (in principle revert of the patch): # echo password | cryptsetup --type plain open <device> test # echo password | cryptsetup refresh --perf-no_read_workqueue test # cryptsetup status test /dev/mapper/test is active. type: PLAIN ... flags: no_read_workqueue ... > Seems we're missing a clean-up somewhere, so it tries to create multiple queues. I am afraid it is not so simple, during reload we have two DM table instances (active and inactive), seems both create workqueues and conflicts on sysfs kobject. No idea if there is a WQ API to solve this... Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
