The saga continues.
Turns out, this is bug in both libvirt AND kernel. Firstly, kernel uses
different CGroup for checking open() than for ioctl() [1]. However,
libvirt needs to allow all targets in the CGroup too. Not only it's
logical, kernel devel says it never worked. QEMU was able to open the
devmapper device but any subsequent read()/write() would fail because of
CGroup perms.
Anyway, it's not only RHEL which is affected by this bug. I've upgraded
my Gentoo to 4.16 and I'm hitting it even though I was not with 4.15.
It all started with upstream kernel commit of 519049afead4f7c3e6446028.
This changed call in dm_blk_ioctl() from dm_grab_bdev_for_ioctl() to
dm_get_bdev_for_ioctl(). The former merely increases refcount on some
internal kernel strcut, the latter calls blkdev_get() which calls
__blkdev_get() which actually performs CGroup check.
1:
https://bugzilla.redhat.com/show_bug.cgi?id=1557769#c54
Diff to v2:
- Changed virDevMapperGetTargets() to do recursive target fetching, and
at the same time make it return string list of devices rather than
MAJ:MIN pairs. This is because dm_task_set_name() accepts path as
string. There's also dm_task_set_major_minor() but:
a) handling multiple arrays and merging them (because of recursion) -
the code would look ugly,
b) we don't need to introduce virDomainAuditCgroupMajorMinor() just to
pass MAJ:MIN to it.
- Implemented dropping of permissions when unplugging a disk (was
missing in previous versions)
Michal Privoznik (3):
util: Introduce virDevMapperGetTargets
qemu_cgroup: Handle device mapper targets properly
news: Document device mapper fix
docs/news.xml | 10 +++
libvirt.spec.in | 2 +
src/libvirt_private.syms | 4 +
src/qemu/qemu_cgroup.c | 69 +++++++++++++---
src/util/Makefile.inc.am | 2 +
src/util/virdevmapper.c | 200 +++++++++++++++++++++++++++++++++++++++++++++++
src/util/virdevmapper.h | 31 ++++++++
7 files changed, 309 insertions(+), 9 deletions(-)
create mode 100644 src/util/virdevmapper.c
create mode 100644 src/util/virdevmapper.h
--
2.16.1