[Devel] [PATCH hci-8.1] block: let container root set the block size of and flush its device

Konstantin Khorenko khorenko at virtuozzo.com
Thu Oct 29 18:44:43 MSK 2026


> Is it possible that some evil CT user can spam flush, keep mutex most
> of the time and prevent some host actions?

No. bd_holder_lock is held only across the holder pointer test. The
->sync branch goes through bdev_super_lock(), which drops it before
taking s_umount and running sync_filesystem(). The other branch unlocks
before sync_blockdev(). Nothing heavy runs under it, so mount, umount,
freeze and mark_dead on the host are not affected.

> I'm mostly talking about ploop devices passed by vzctl.

In v2 those never reach the ioctl body. libvzctl configure_disk_perm()
grants CT disks (root ploop, secondary ploop, physical hdd via
use_device) r + W, plus M for non-root. W is "write only for mount": the
BPF program in bpf/cgroup_dev.c passes WRITE only when the request also
carries MOUNT. bdev_permission(BLK_OPEN_WRITE) has no MOUNT bit, so
blkdev_admin_capable() fails and the CT gets -EACCES, same as today.

> The same question regarding hdd disks from vzctl: can't we break them?

Even with a plain write grant, no. They are mounted by the host.
BLKFLSBUF hits the fs holder and v2 returns -EBUSY there. BLKBSZSET
cannot get the exclusive claim the mount holds and returns -EBUSY by the
unchanged upstream logic.

What v1 actually allowed on the CT's own ploop was sync plus
invalidate_bdev of the device under its own filesystem, i.e. what
syncfs() on its root already gives it. v2 closes even that at the
device cgroup level.


More information about the Devel mailing list