From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 58B6AC624D4 for ; Wed, 2 Sep 2026 19:46:07 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x1qtO-0000X2-MC; Wed, 02 Sep 2026 15:45:07 -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 1x1qtK-0000VG-9d; Wed, 02 Sep 2026 15:45:02 -0400 Received: from tor.source.kernel.org ([172.105.4.254]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x1qtI-00062K-Jh; Wed, 02 Sep 2026 15:45:02 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 9E027600D1; Wed, 2 Sep 2026 19:44:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B2411F000E9; Wed, 2 Sep 2026 19:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788378299; bh=h9Qo5k3ykhgIn0JhKJQgJWLA0g5Mjf6BwJLZOuJOsus=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=gMIn3nuvwATWak+HdbI5ar41Y9/vzQwLoqw9s+zj3yT0i9NXEqqHoaSfJ4Dg95IYH qB/EVD85oU5M9jE7wA6GI2NdGWukJnmVzD3EwboK5qQvDOLrZ9aE3PWQW0inoY9eiV lgfBtsqwtwrTqvaToSWS3+d0b82nybYGuB0x512y6zALDOlL0xquUEfU1t+31ShQn2 ZDHGVphfHefrjdnCP7UTlQ7UMf3L8C8BvCQDF0owgHYLzo3GEwaUrJXc1sgcM3032Y FloDT8Hqbgnp7li4CLLz/1T/sO3tpLr7WHCZCKyz83ZtMFGf89b1kexd33W5ZzW3Md f+UYU40L22NWg== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v2 07/11] file-posix: remove the zone append write granularity check Date: Wed, 2 Sep 2026 21:44:18 +0200 Message-ID: <20260902194423.759355-8-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260902194423.759355-1-cassel@kernel.org> References: <20260902194423.759355-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=172.105.4.254; envelope-from=cassel@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org The check rejects a zone append whose individual iovec lengths are not multiples of the zone write granularity. That is stricter than the constraint it is meant to enforce, which applies to the size of the request as a whole. A request whose total is properly aligned but which is split across, say, a 512 byte and a 3584 byte iovec is refused here, even though the iovec boundaries do not survive into the scatter gather list that reaches the device. Nor is the driver the right place to enforce it. The kernel and the device validate writes to a sequential zone themselves, which is why the same function already passes the request length down without comparing it against BlockLimits.max_append_sectors. The sector granularity that holds for every backend is now checked once in bdrv_co_zone_append(), and a frontend enforces the granularity it advertises to its guest. Drop the check. BlockLimits.write_granularity is now set in one place, by this driver from the zone_write_granularity queue attribute, and read in one place, by the frontend that reports it. Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/file-posix.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index c0d6ee30e4..f267513a4e 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -3593,8 +3593,6 @@ raw_co_zone_append(BlockDriverState *bs, BdrvRequestFlags flags) { assert(flags == 0); int64_t zone_size_mask = bs->bl.zone_size - 1; - int64_t iov_len = 0; - int64_t len = 0; if (*offset & zone_size_mask) { error_report("sector offset %" PRId64 " is not aligned to zone size " @@ -3602,20 +3600,8 @@ raw_co_zone_append(BlockDriverState *bs, return -EINVAL; } - int64_t wg = bs->bl.write_granularity; - int64_t wg_mask = wg - 1; - for (int i = 0; i < qiov->niov; i++) { - iov_len = qiov->iov[i].iov_len; - if (iov_len & wg_mask) { - error_report("len of IOVector[%d] %" PRId64 " is not aligned to " - "block size %" PRId64 "", i, iov_len, wg); - return -EINVAL; - } - len += iov_len; - } - trace_zbd_zone_append(bs, *offset >> BDRV_SECTOR_BITS); - return raw_co_prw(bs, offset, len, qiov, QEMU_AIO_ZONE_APPEND, 0); + return raw_co_prw(bs, offset, qiov->size, qiov, QEMU_AIO_ZONE_APPEND, 0); } #endif -- 2.55.0