From nobody Mon Feb 9 17:24:02 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1564500952; cv=none; d=zoho.com; s=zohoarc; b=BOT3TwLoGwRxeDenREwlCSYrWZga+suQyC2jjliQwHm5v6FJ/i9fUOozx12e2xeoUj6XwbgnC9oKK4S6dI2KYODiRBWxJK2Q9G5pAA6mHXtdM5YoRqE7/X9VhbRa21+U6869ftj1nEm8BMSDDxbbu5U6QBN2fLCILnjnjWsceBc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1564500952; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=gECrUoc5zSye+3KEQ84d6B+9vU7LJDQk9QqWslNMB8c=; b=FaohNhzVsYKgs1UVe9YspG/fNGnQ46PxFYoWgPBZPC4sNFF/9D5xqw7jmIP4f56IQxm10+R83wFZWAY0c4AfHxpbQQvQN8YjViDqBa1m8qT/muu8PCpe0oE/0vFrCTrz0+eTlLXsm+2tJhFDt59hT6QWOC0rXnMZJjakQDxwlUY= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1564500952312316.36775333183687; Tue, 30 Jul 2019 08:35:52 -0700 (PDT) Received: from localhost ([::1]:34006 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsUAJ-0001Bo-BO for importer@patchew.org; Tue, 30 Jul 2019 11:35:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45173) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsU8L-0007j3-4M for qemu-devel@nongnu.org; Tue, 30 Jul 2019 11:33:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hsU8J-0004ZP-T2 for qemu-devel@nongnu.org; Tue, 30 Jul 2019 11:33:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57234) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hsU8H-0004X3-PD; Tue, 30 Jul 2019 11:33:45 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0AC86308AA11; Tue, 30 Jul 2019 15:33:45 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-117-75.ams2.redhat.com [10.36.117.75]) by smtp.corp.redhat.com (Postfix) with ESMTP id F0791608C1; Tue, 30 Jul 2019 15:33:43 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Tue, 30 Jul 2019 17:33:30 +0200 Message-Id: <20190730153331.24515-2-kwolf@redhat.com> In-Reply-To: <20190730153331.24515-1-kwolf@redhat.com> References: <20190730153331.24515-1-kwolf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 30 Jul 2019 15:33:45 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/2] fdc: Fix inserting read-only media in empty drive X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, peter.maydell@linaro.org, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" In order to insert a read-only medium (i.e. a read-only block node) to the BlockBackend of a floppy drive, we must not have taken write permissions on that BlockBackend, or the operation will fail with the error message "Block node is read-only". The device already takes care to remove all permissions when the medium is ejected, but the state isn't correct if the drive is initially empty: It uses blk_is_read_only() to check whether write permissions should be taken, but this function returns false for empty BlockBackends in the common case. Fix floppy_drive_realize() to avoid taking write permissions if the drive is empty. Signed-off-by: Kevin Wolf Reviewed-by: Max Reitz Reviewed-by: John Snow --- hw/block/fdc.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/hw/block/fdc.c b/hw/block/fdc.c index 77af9979de..9b24cb9b85 100644 --- a/hw/block/fdc.c +++ b/hw/block/fdc.c @@ -514,6 +514,7 @@ static void floppy_drive_realize(DeviceState *qdev, Err= or **errp) FloppyDrive *dev =3D FLOPPY_DRIVE(qdev); FloppyBus *bus =3D FLOPPY_BUS(qdev->parent_bus); FDrive *drive; + bool read_only; int ret; =20 if (dev->unit =3D=3D -1) { @@ -542,6 +543,12 @@ static void floppy_drive_realize(DeviceState *qdev, Er= ror **errp) dev->conf.blk =3D blk_new(qemu_get_aio_context(), 0, BLK_PERM_ALL); ret =3D blk_attach_dev(dev->conf.blk, qdev); assert(ret =3D=3D 0); + + /* Don't take write permissions on an empty drive to allow attachi= ng a + * read-only node later */ + read_only =3D true; + } else { + read_only =3D !blk_bs(dev->conf.blk) || blk_is_read_only(dev->conf= .blk); } =20 blkconf_blocksizes(&dev->conf); @@ -559,9 +566,7 @@ static void floppy_drive_realize(DeviceState *qdev, Err= or **errp) dev->conf.rerror =3D BLOCKDEV_ON_ERROR_AUTO; dev->conf.werror =3D BLOCKDEV_ON_ERROR_AUTO; =20 - if (!blkconf_apply_backend_options(&dev->conf, - blk_is_read_only(dev->conf.blk), - false, errp)) { + if (!blkconf_apply_backend_options(&dev->conf, read_only, false, errp)= ) { return; } =20 --=20 2.20.1