From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfU2H-0001NI-62 for qemu-devel@nongnu.org; Fri, 25 Sep 2015 10:31:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZfU2B-0003gy-Jz for qemu-devel@nongnu.org; Fri, 25 Sep 2015 10:31:41 -0400 From: Alberto Garcia In-Reply-To: <560558A2.3020804@redhat.com> References: <1443188504-20296-1-git-send-email-berto@igalia.com> <560558A2.3020804@redhat.com> Date: Fri, 25 Sep 2015 16:31:31 +0200 Message-ID: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , qemu-block@nongnu.org, Stefan Hajnoczi , Max Reitz On Fri 25 Sep 2015 04:22:26 PM CEST, Eric Blake wrote: >> Disabling I/O limits from a BDS also drains all pending throttled >> requests, so it should be done at the beginning of bdrv_close() with >> the rest of the bdrv_drain() calls before the BlockDriver is closed. > > 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. Berto