From: Mikulas Patocka <mpatocka@redhat.com>
To: dm-devel@redhat.com
Cc: Mike Snitzer <msnitzer@redhat.com>,
"Alasdair G. Kergon" <agk@redhat.com>
Subject: device mapper and the BLKFLSBUF ioctl
Date: Fri, 21 Oct 2016 14:33:00 -0400 (EDT) [thread overview]
Message-ID: <alpine.LRH.2.02.1610211406290.9197@file01.intranet.prod.int.rdu2.redhat.com> (raw)
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.
Mikulas
next reply other threads:[~2016-10-21 18:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 18:33 Mikulas Patocka [this message]
2016-10-21 20:00 ` device mapper and the BLKFLSBUF ioctl Mike Snitzer
2016-10-21 20:18 ` Mikulas Patocka
2016-10-24 15:57 ` Mike Snitzer
2016-10-25 13:07 ` Christoph Hellwig
2016-10-25 14:37 ` [PATCH] brd: remove support for BLKFLSBUF Mike Snitzer
2016-10-25 14:46 ` Jens Axboe
2016-10-26 20:25 ` [PATCH 0/4] brd: support discard Mikulas Patocka
2016-10-26 20:26 ` [PATCH 1/4] brd: handle misaligned discard Mikulas Patocka
2016-10-26 20:38 ` [dm-devel] " Bart Van Assche
2016-10-26 20:38 ` Bart Van Assche
2016-10-26 21:46 ` Mikulas Patocka
2016-10-26 21:50 ` REQ_OP for zeroing, was " Christoph Hellwig
2016-10-28 11:43 ` Mikulas Patocka
2016-10-28 13:14 ` Christoph Hellwig
2016-10-31 16:36 ` Mikulas Patocka
2016-10-26 21:57 ` Bart Van Assche
2016-10-26 21:57 ` Bart Van Assche
2016-10-28 11:39 ` Mikulas Patocka
2016-10-28 15:55 ` Bart Van Assche
2016-10-28 15:55 ` Bart Van Assche
2016-10-31 16:31 ` Mikulas Patocka
2016-10-26 20:26 ` [PATCH 2/4] brd: extend rcu read sections Mikulas Patocka
2016-10-26 20:27 ` [PATCH 3/4] brd: implement discard Mikulas Patocka
2016-10-26 20:27 ` [PATCH 4/4] brd: remove unused brd_zero_page Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.02.1610211406290.9197@file01.intranet.prod.int.rdu2.redhat.com \
--to=mpatocka@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=msnitzer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.