From nobody Sat Oct 24 00:32:23 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1790947372; cv=none; d=zohomail.com; s=zohoarc; b=LXX6QAGgL5COClU5lr2YoeSAhjE1RnB0AGw0fe4Jm/t5lVspnd3jfsmS+Lx203EcNu4OBdG0XETwazfX0VPSEUSjR6KOZpUh6C48cdqlPU6u8+ff+rp4YvU3AmYSD68skhTn6AOX85XKBVfUaqdGk0Ig3OGC7Dx1ZykeK2k0YuY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1790947372; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=vZMw/awo/vOePnU/uVu9Zq230e0ljELKCbEMexNyNYQ=; b=hwwsueLb8fUn7pCBsZXcLpVRTT+FcCenXjDlAUjc6MqQSlGc6Im26BwhM3JbT5RkzrxlWIZMgPM1W7grl4TL2ml3lrsYQuqNItWEPBrzEORX3XE0T4+FeO0Nl6edfsAyXDfhwv/zfE/VvTUMcq6hMFb0DwU1pJfAVafRh+391z4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1790947372403653.0830313041018; Fri, 2 Oct 2026 06:22:52 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1xCdDg-0002Cq-8W; Fri, 02 Oct 2026 09:22:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xCdD1-00027S-Fc for qemu-devel@nongnu.org; Fri, 02 Oct 2026 09:21:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xCdCx-0001eW-RY for qemu-devel@nongnu.org; Fri, 02 Oct 2026 09:21:54 -0400 Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-640-8pk1L8xuNHiPXNgNdDVx5Q-1; Fri, 02 Oct 2026 09:21:47 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 38A201800D8C; Fri, 2 Oct 2026 13:21:46 +0000 (UTC) Received: from merkur.fritz.box (unknown [10.44.48.157]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 6F14C30000E4; Fri, 2 Oct 2026 13:21:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1790947309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vZMw/awo/vOePnU/uVu9Zq230e0ljELKCbEMexNyNYQ=; b=AotUyCPx8r5NksLTxCe/r0iWdgZ2ua00r0ucIxegZDkrTHRhOn6YBGv/v6rK3q7ylgohNZ n3IRqjGZMYcaYaKICfXs6QfF3K6/UsKq9J3GpNho8DoHd74B/2hOgyQBBsPb3FhXsKIhRA A6Wt3yOFn4mx/OEmC91luECwftSdiZg= X-MC-Unique: 8pk1L8xuNHiPXNgNdDVx5Q-1 X-Mimecast-MFC-AGG-ID: 8pk1L8xuNHiPXNgNdDVx5Q_1790947306 From: Kevin Wolf To: qemu-block@nongnu.org Cc: kwolf@redhat.com, hreitz@redhat.com, qemu-devel@nongnu.org, qemu-stable@nongnu.org Subject: [PATCH 1/2] block: Fix corruption from broken RMW atomicity Date: Fri, 2 Oct 2026 15:21:34 +0200 Message-ID: <20261002132135.93345-2-kwolf@redhat.com> In-Reply-To: <20261002132135.93345-1-kwolf@redhat.com> References: <20261002132135.93345-1-kwolf@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Received-SPF: pass (zohomail.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=lists1p.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=kwolf@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.336, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1790947372801158500 Content-Type: text/plain; charset="utf-8" When emulating 512 byte sector devices on top of 4k native host storage, QEMU performs a read-modify-write cycle for misaligned write requests. These requests are marked as serialising so that any other writes to the same 4k block will have to wait and can't overwrite the block in the middle, which would make the RMW write back stale data. In principle, this mechanism works fine, but there is a race condition in the implementation: bdrv_find_conflicting_request() assumes that req->waiting_for =3D=3D NULL means that the request is the active owner of the data blocks it touches and everyone else has to wait for this request. However, there is a window between tracked_request_begin() and bdrv_wait_serialising_requests_locked() where any new request has req->waiting_for =3D=3D NULL even if it conflicts with an already running serialising request. So at this point, we have seemingly two active owners at the same time until the new request checks for conflicts. For a third request coming in, this isn't a problem, it just might wait for a little longer than necessary. However, if the original RMW request calls bdrv_wait_serialising_requests_locked() again (which it does in bdrv_aligned_pwritev() -> bdrv_co_write_req_prepare() before writing back the RMW buffer), it will now wait on the other request that snuck in, which is fatal and makes the RMW buffer stale. This scenario causes data corruption. Fix this by checking for conflicts already in tracked_request_begin() while holding the bs->reqs_lock mutex, so that the race window is closed and req->waiting_for =3D=3D NULL really has the intended meaning. For good measure, add an active_owner boolean that is set when a request is marked serialising and has completed waiting for other requests, and assert that it is not set when waiting for another request, so that in the case of another bug, we'd crash instead of causing data corruption. Cc: qemu-stable@nongnu.org Buglink: https://redhat.atlassian.net/browse/RHEL-272836 Signed-off-by: Kevin Wolf --- include/block/block_int-common.h | 1 + block/io.c | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/include/block/block_int-common.h b/include/block/block_int-com= mon.h index 147c08155f7..46428b034de 100644 --- a/include/block/block_int-common.h +++ b/include/block/block_int-common.h @@ -80,6 +80,7 @@ typedef struct BdrvTrackedRequest { enum BdrvTrackedRequestType type; =20 bool serialising; + bool active_owner; int64_t overlap_offset; int64_t overlap_bytes; =20 diff --git a/block/io.c b/block/io.c index a916b236c3c..bd562d472fd 100644 --- a/block/io.c +++ b/block/io.c @@ -50,6 +50,9 @@ static int coroutine_fn bdrv_co_do_pwrite_zeroes(BlockDriverState *bs, int64_t offset, int64_t bytes, BdrvRequestFlags flags); =20 +static void coroutine_fn +bdrv_wait_serialising_requests_locked(BdrvTrackedRequest *self); + static void GRAPH_RDLOCK bdrv_parent_drained_begin(BlockDriverState *bs, BdrvChild *ignore) { @@ -616,6 +619,7 @@ static void coroutine_fn tracked_request_begin(BdrvTrac= kedRequest *req, .type =3D type, .co =3D qemu_coroutine_self(), .serialising =3D false, + .active_owner =3D false, .overlap_offset =3D offset, .overlap_bytes =3D bytes, }; @@ -624,6 +628,15 @@ static void coroutine_fn tracked_request_begin(BdrvTra= ckedRequest *req, =20 qemu_mutex_lock(&bs->reqs_lock); QLIST_INSERT_HEAD(&bs->tracked_requests, req, list); + + /* + * Set .waiting_for while we're holding the lock, otherwise we'd open = a race + * window where another request in the middle of its RMW cycle starts + * waiting for us, leading to potential data corruption if this request + * overwrites a block the RMW request has already read. + */ + bdrv_wait_serialising_requests_locked(req); + qemu_mutex_unlock(&bs->reqs_lock); } =20 @@ -684,6 +697,15 @@ bdrv_wait_serialising_requests_locked(BdrvTrackedReque= st *self) BdrvTrackedRequest *req; =20 while ((req =3D bdrv_find_conflicting_request(self))) { + /* + * If this request is the active owner of the data blocks it acces= ses, + * no other conflicting request may exist; other requests have to = wait + * for this one, not the other way around. If this condition is + * violated, RMW operations may be interrupted in the middle, oper= ate on + * stale data and introduce data corruption. + */ + assert(!self->active_owner); + self->waiting_for =3D req; qemu_co_queue_wait(&req->wait_queue, &self->bs->reqs_lock); self->waiting_for =3D NULL; @@ -803,6 +825,7 @@ void coroutine_fn bdrv_make_request_serialising(BdrvTra= ckedRequest *req, =20 tracked_request_set_serialising(req, align); bdrv_wait_serialising_requests_locked(req); + req->active_owner =3D true; =20 qemu_mutex_unlock(&req->bs->reqs_lock); } --=20 2.55.0 From nobody Sat Oct 24 00:32:23 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1790947372; cv=none; d=zohomail.com; s=zohoarc; b=A6q3XxwlXIDNQrjZa9io47wptfOrlYKk8QnJETLlxa+4fhjZNwv30EwnWh2VOU/o2NMfTwL3dVmPzlNk/e+mJhqMj0O04O1Vyhyim71ZZkQIa1o1IxLrEn58Py9q9y7IHWgRTMTqiq6kSBm1uVR2j6nA7d831//WLuSQggZqCwg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1790947372; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=fsaqrLfIpI/5y25hzh0QXelKvpxkNsJrSdHoyKbVvDM=; b=Zlc5QJJz+k9oSxj/uL/+Xo0f46erYlbupOxKIt9zuqrzcBkCeaMWBzC52Z5h1ClMMmQfOaib/4zSWpvuPFhbeV4S8k26pTWV13ZUc/+7ajg4ReOL5B6mn1gzxGMda4GQy78rjJhrfka/wD/zPiMaTDg3HAnDOMQlBZNDxRjkGvY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1790947372403862.1439953996235; Fri, 2 Oct 2026 06:22:52 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1xCdDb-0002C3-D9; Fri, 02 Oct 2026 09:22:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xCdD2-00027V-2f for qemu-devel@nongnu.org; Fri, 02 Oct 2026 09:21:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xCdCx-0001el-Rv for qemu-devel@nongnu.org; Fri, 02 Oct 2026 09:21:54 -0400 Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-221-rPgSELmmMgeLQRFTd_COSg-1; Fri, 02 Oct 2026 09:21:49 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2F33A195D00C; Fri, 2 Oct 2026 13:21:48 +0000 (UTC) Received: from merkur.fritz.box (unknown [10.44.48.157]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9E38D3000229; Fri, 2 Oct 2026 13:21:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1790947310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fsaqrLfIpI/5y25hzh0QXelKvpxkNsJrSdHoyKbVvDM=; b=XapEZUVTzFI3vT4DN6fty6lUHaxCgXDXx4pCOVylo+AgUNlSDKB554Xpr0qswwPnnLst6e PRU4feN97/OvcsMkLEGsahNjKtLFzeVtvtyf47uFmFPAMjegU73ls2wMHAgr8d1IjJ33i7 mp9GA1EVh1cFwoQAud+wv9MuucYH6Og= X-MC-Unique: rPgSELmmMgeLQRFTd_COSg-1 X-Mimecast-MFC-AGG-ID: rPgSELmmMgeLQRFTd_COSg_1790947308 From: Kevin Wolf To: qemu-block@nongnu.org Cc: kwolf@redhat.com, hreitz@redhat.com, qemu-devel@nongnu.org, qemu-stable@nongnu.org Subject: [PATCH 2/2] block: Remove now redundant bdrv_wait_serialising_requests() calls Date: Fri, 2 Oct 2026 15:21:35 +0200 Message-ID: <20261002132135.93345-3-kwolf@redhat.com> In-Reply-To: <20261002132135.93345-1-kwolf@redhat.com> References: <20261002132135.93345-1-kwolf@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Received-SPF: pass (zohomail.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=lists1p.gnu.org; Received-SPF: pass client-ip=170.10.129.124; envelope-from=kwolf@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: 9 X-Spam_score: 0.9 X-Spam_bar: / X-Spam_report: (0.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.336, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1790947372735158500 Content-Type: text/plain; charset="utf-8" All callers of bdrv_wait_serialising_requests() (as opposed to bdrv_wait_serialising_requests_locked()) are just duplicating the check that tracked_request_begin() already performs now. After removing them, bdrv_wait_serialising_requests() has no callers left and can go as well. Signed-off-by: Kevin Wolf --- block/io.c | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/block/io.c b/block/io.c index bd562d472fd..1c05dd106d6 100644 --- a/block/io.c +++ b/block/io.c @@ -802,20 +802,6 @@ void bdrv_dec_in_flight(BlockDriverState *bs) bdrv_wakeup(bs); } =20 -static void coroutine_fn -bdrv_wait_serialising_requests(BdrvTrackedRequest *self) -{ - BlockDriverState *bs =3D self->bs; - - if (!qatomic_read(&bs->serialising_in_flight)) { - return; - } - - qemu_mutex_lock(&bs->reqs_lock); - bdrv_wait_serialising_requests_locked(self); - qemu_mutex_unlock(&bs->reqs_lock); -} - void coroutine_fn bdrv_make_request_serialising(BdrvTrackedRequest *req, uint64_t align) { @@ -1383,8 +1369,6 @@ bdrv_aligned_preadv(BdrvChild *child, BdrvTrackedRequ= est *req, * it ensures that the CoR read and write operations are atomic and * guest writes cannot interleave between them. */ bdrv_make_request_serialising(req, bdrv_get_cluster_size(bs)); - } else { - bdrv_wait_serialising_requests(req); } =20 if (flags & BDRV_REQ_COPY_ON_READ) { @@ -2021,8 +2005,6 @@ bdrv_co_write_req_prepare(BdrvChild *child, int64_t o= ffset, int64_t bytes, } =20 bdrv_wait_serialising_requests_locked(req); - } else { - bdrv_wait_serialising_requests(req); } =20 assert(req->overlap_offset <=3D offset); @@ -3530,7 +3512,6 @@ static int coroutine_fn GRAPH_RDLOCK bdrv_co_copy_ran= ge_internal( =20 /* BDRV_REQ_SERIALISING is only for write operation */ assert(!(read_flags & BDRV_REQ_SERIALISING)); - bdrv_wait_serialising_requests(&req); =20 ret =3D src->bs->drv->bdrv_co_copy_range_from(src->bs, src, src_offset, --=20 2.55.0