From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9FPM-0001FE-UQ for qemu-devel@nongnu.org; Wed, 05 Sep 2012 09:12:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9FPL-0006OM-TV for qemu-devel@nongnu.org; Wed, 05 Sep 2012 09:12:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9FPL-0006OC-Ks for qemu-devel@nongnu.org; Wed, 05 Sep 2012 09:12:39 -0400 Message-ID: <50474FBF.8040607@redhat.com> Date: Wed, 05 Sep 2012 15:12:31 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <431ff7f85fb9c83b5300360273322e6a0c76aee2.1346352124.git.jcody@redhat.com> <504749EE.20903@redhat.com> <50474EDC.1090204@redhat.com> In-Reply-To: <50474EDC.1090204@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/7] block: correctly set the keep_read_only flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jcody@redhat.com Cc: supriyak@linux.vnet.ibm.com, pbonzini@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.com Am 05.09.2012 15:08, schrieb Jeff Cody: > On 09/05/2012 08:47 AM, Kevin Wolf wrote: >> Am 30.08.2012 20:47, schrieb Jeff Cody: >>> I believe the bs->keep_read_only flag is supposed to reflect >>> the initial open state of the device. If the device is initially >>> opened R/O, then commit operations, or reopen operations changing >>> to R/W, are prohibited. >>> >>> Currently, the keep_read_only flag is only accurate for the active >>> layer, and its backing file. Subsequent images end up always having >>> the keep_read_only flag set. >>> >>> For instance, what happens now: >>> >>> [ base ] kro = 1, ro = 1 >>> | >>> v >>> [ snap-1 ] kro = 1, ro = 1 >>> | >>> v >>> [ snap-2 ] kro = 0, ro = 1 >>> | >>> v >>> [ active ] kro = 0, ro = 0 >>> >>> What we want: >>> >>> [ base ] kro = 0, ro = 1 >>> | >>> v >>> [ snap-1 ] kro = 0, ro = 1 >>> | >>> v >>> [ snap-2 ] kro = 0, ro = 1 >>> | >>> v >>> [ active ] kro = 0, ro = 0 >>> >>> Signed-off-by: Jeff Cody >>> --- >>> block.c | 16 +++++++--------- >>> block.h | 1 + >>> 2 files changed, 8 insertions(+), 9 deletions(-) >>> >>> diff --git a/block.c b/block.c >>> index 470bdcc..e31b76f 100644 >>> --- a/block.c >>> +++ b/block.c >>> @@ -655,7 +655,7 @@ static int bdrv_open_common(BlockDriverState *bs, const char *filename, >>> * Clear flags that are internal to the block layer before opening the >>> * image. >>> */ >>> - open_flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING); >>> + open_flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING | BDRV_O_ALLOW_RDWR); >>> >>> /* >>> * Snapshots should be writable. >>> @@ -664,8 +664,6 @@ static int bdrv_open_common(BlockDriverState *bs, const char *filename, >>> open_flags |= BDRV_O_RDWR; >>> } >>> >>> - bs->keep_read_only = bs->read_only = !(open_flags & BDRV_O_RDWR); >>> - >>> /* Open the image, either directly or using a protocol */ >>> if (drv->bdrv_file_open) { >>> ret = drv->bdrv_file_open(bs, filename, open_flags); >>> @@ -804,6 +802,12 @@ int bdrv_open(BlockDriverState *bs, const char *filename, int flags, >>> goto unlink_and_fail; >>> } >>> >>> + if (flags & BDRV_O_RDWR) { >>> + flags |= BDRV_O_ALLOW_RDWR; >>> + } >>> + >>> + bs->keep_read_only = !(flags & BDRV_O_ALLOW_RDWR); >> >> Do we still need bs->keep_read_only or is it duplicated in >> bs->open_flags now? We can convert all users in a follow-up patch. >> > > I think we can ditch keep_read_only, and just use BDRV_O_ALLOW_RDWR. The > only other user of keep_read_only is the original bdrv_commit(), in > block.c. And, the natural way to convert that function would be to have > it use bdrv_reopen(), to change from r/o->r/w. Ah, yes, makes sense. So just using it in patch 2 and then converting bdrv_commit() should be enough. Kevin