Re: device mapper and the BLKFLSBUF ioctl

[Mike Snitzer <snitzer@redhat.com>]

On Fri, Oct 21 2016 at  2:33pm -0400,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> Hi
> 
> I found a bug in dm regarding the BLKFLSBUF ioctl.
> 
> The BLKFLSBUF ioctl can be called on a block device and it flushes the 
> buffer cache. There is one exception - when it is called on ramdisk, it 
> actually destroys all ramdisk data (it works like a discard on the full 
> device).
> 
> The device mapper passes this ioctl down to the underlying device, so when 
> the ioctl is called on a logical volume, it can be used to destroy the 
> underlying volume group if the volume group is on ramdisk.
> 
> For example:
> # modprobe brd rd_size=1048576
> # pvcreate /dev/ram0
> # vgcreate ram_vg /dev/ram0
> # lvcreate -L 16M -n ram_lv ram_vg
> # blockdev --flushbufs /dev/ram_vg/ram_lv
> 	--- and now the whole volume group is gone, all data on the 
> 		ramdisk were replaced with zeroes
> 
> The BLKFLSBUF ioctl is only allowed with CAP_SYS_ADMIN, so there shouldn't 
> be security implications with this.
> 
> Whan to do with it? The best thing would be to drop this special ramdisk 
> behavior and make the BLKFLSBUF ioctl flush the buffer cache on ramdisk 
> like on all other block devices. But there may be many users having 
> scripts that depend on this special behavior.
> 
> Another possibility is to stop the device mapper from passing the 
> BLKFLSBUF ioctl down.

If anything DM is being consistent with what the underlying device is
meant to do.

brd_ioctl() destroys the data in response to BLKFLSBUF.. I'm missing why
this is a DM-specific problem.