From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42199)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berto@igalia.com>) id 1ZgUNG-0004Cq-AI
	for qemu-devel@nongnu.org; Mon, 28 Sep 2015 05:05:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <berto@igalia.com>) id 1ZgUNB-0007eh-4O
	for qemu-devel@nongnu.org; Mon, 28 Sep 2015 05:05:30 -0400
From: Alberto Garcia <berto@igalia.com>
In-Reply-To: <20150928001833.GB10367@localhost.nay.redhat.com>
References: <1443188504-20296-1-git-send-email-berto@igalia.com>
	<560558A2.3020804@redhat.com>
	<w51wpvein98.fsf@maestria.local.igalia.com>
	<20150928001833.GB10367@localhost.nay.redhat.com>
Date: Mon, 28 Sep 2015 11:04:44 +0200
Message-ID: <w514miex6c3.fsf@maestria.local.igalia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Qemu-devel] [PATCH] block: disable I/O limits at the beginning
	of bdrv_close()
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Fam Zheng <famz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org, qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>

On Mon 28 Sep 2015 02:18:33 AM CEST, Fam Zheng <famz@redhat.com> wrote:

>> > Can this be abused? If I have a guest running in a cloud where the
>> > cloud provider has put severe throttling limits on me, but lets me
>> > hotplug to my heart's content, couldn't I just repeatedly
>> > plug/unplug the disk to get around the throttling (every time I
>> > unplug, all writes flush at full speed, then I immediately replug
>> > to start batching up a new set of writes).  In other words,
>> > shouldn't the draining still be throttled, to prevent my abuse?
>> 
>> I didn't think about this case, and I don't know how practical this
>> is, but note that bdrv_drain() (which is already at the beginning of
>> bdrv_close()) flushes the I/O queue explicitly bypassing the limits,
>> so other cases where a user can trigger a bdrv_drain() would also be
>> vulnerable to this.
>
> Yes, the issue is pre-existing. This patch only reordered things
> inside bdrv_close() so it's no worse.
>
> But indeed there is this vulnerability, maybe we should throttle the
> queue in all cases?

I would like to see a test case with numbers that show how much you can
actually bypass the I/O limits.

Berto