From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f45.google.com (mail-dl1-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF82A3033EC for ; Sun, 11 Oct 2026 15:40:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791733227; cv=none; b=q5UCksJsa1Vcs0o3hhQmnVOqJilSqp7Ya2hPHOGtDhPBCtZGck5KVMHYgXZ+nySaQ80iUUmAqwte/5I5KIYIGLI+4Jgd7vTBbBoIqnax+xf9b11ImQL2qKd7OFpnCqvK0FjKECw8HYgtJc/kZO/k1mVlUUSyNtip9HU5lpfQwlQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791733227; c=relaxed/simple; bh=8v2ggXzUD3gHQZSpbkrI7r2xnny7T8N9JpArw/Uh008=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=UcEZPhchG7uHbVRIuOSum+Vl98oD9MgI1/393ghbYVr5YNVCxSPWqCSCTv/pNK+PzUjHOMd29Ky77o77LfwfAMOlWOHCOh2UgCkXZFc4bGGDn6EraJnPepMuw2D+2D7o3VHlW3QyR77W+s5qa8cIHla7G0D9Dy/loC7MfPHtnDE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ESuGnzQx; arc=none smtp.client-ip=74.125.82.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ESuGnzQx" Received: by mail-dl1-f45.google.com with SMTP id a92af1059eb24-1419d3416ceso1507918c88.0 for ; Sun, 11 Oct 2026 08:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791733226; x=1792338026; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=yJqSVfn48yTsL/59J4SIahE071FOQoaX2gq57TLxImY=; b=ESuGnzQxVtd1sCMqmm2mFuAkHDaRK8Y3XxiKzUZzMnOpw6KuGfokusR49XRY7pLupr +MNaBtsO4sslSGG9Wam8Hh3tsX15VMV50dHrlmTXCRX8VUZRc2neiTnC72iW055TOF45 eqhqJmhU+V5N+EelMhW+uNSHnBNZthjR3DG1Mbo0+zuZhWgrym1sN0hoW6qGixsmxUsI 4ATg4lsHa3tN5ntz7cmxlouaVGBGnzVKf/YzikvKnVZzWGvdDhBylAvPAaalt7gKGFx4 d9zJtgbxmTSXZkx0ntn/QkfNv8igl90/WJMPqm1Nx7XuRnZto/FfiZPBkgvJnMSvbB5N Jytg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791733226; x=1792338026; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yJqSVfn48yTsL/59J4SIahE071FOQoaX2gq57TLxImY=; b=D8ApwQBrz/wkExMZeLrLpBrNFCKWefEYCfhtaLehdm1w8qgKtEgMGoEkJEJ/xauo8y LUqk3XlQWLuX8EPfOBXkXkn5AYKsXF8IEjafg6+fj7R4PKReLgsyh3a5N7M9QCpIixtT ZesLlGLpn5pHj5LkKZq+aYNICocpSCxvaULu+7wp0vn9FYt/B3c1OvJPgenqcCM0Z2e0 Wv/U/AkOGNNYn66EzSMW5F69PigKk0B6mBmIgWJ5OpPlfCD66fMl8+Yyp03is+KOj87/ 5QmWAxA4gAjA9aJ9WFAhCO94L35e4bga7T83iJJS6rcaVcBdZ2K/gqzyUeT6UuTSG3CP btEQ== X-Forwarded-Encrypted: i=1; AKwUvBxohbYtfZO8arFmSWvY6t6rq8HVoe3u5yvqVNKxX8oTFCky5tJo4ttrnCLFUF0c8/f+0ieg1G/PCNOq7Dc=@vger.kernel.org X-Gm-Message-State: AFq9FYJj2Sdfy+wTZYAk5VI28CX213umh3TO1PO08o91by0zYdlDCrVH Nt1sSapOnTYVCchFR5P3TVMfPI6UH5V8Wuh+gk7XvY3OcwxnCzWn4iqr X-Gm-Gg: AYBFou31c8zY+KI7ncxy8Dwyi4S60KD8agEKrahg8rzpA/SE1yLUYKxoEBllDKtGxMO x72z2zL1qggULMGInBqRNL/NVfDbXScutgR64dC8hTSgLWnfAPMwRCThFkys3Z/MzbRcezKv+wl voNtne9Objok+pZcTSocDbmZ/AS6lo1IPLDNJGOBIqr/5nNEZxCJpSOsoVimM89OrZ1VfzUMSkI USB0zEMD5/j9mazwDs4lfimFqdopGQLovu6v1f2VtbJGjdHGwi+wKkbDkorCQI3EeG9s6Va9WfD O78Fv4DBGegw+zbYZOflx/+thPtC9ERwwPmuHMpxrlcChNS9znwcd8hyCJZT+viZZUtpHYbNc2W xyl3X9DBOaZsjATMAQrciXMLCXYBDVHZ2HnW2UWFVBgK7BvJWTTJAfoXNNZ2U8tuHgS3DcZyqeH f5GcaiqmP9Egw4YJ8wbZb/yk3HakTSwFsoGVpIpo8MHVxtdazq2nRUJXSH1pD53y074aN08g6VW 1ij7M8z3V6eeLJ15Khe025iAGeEynZ11Uti4Q3ngiuIwzectJb/06L84SymWjqbdsDPa/qsUwx/ pRLlKkDe3vsUU4qzgdnlseqIgYQUlPLo9x5ki7n+0Hb2UHMoti0B83kfoGzFAUQQS0B8sRUTigV P79m39vnYU2B1/BnKTXakunSZdiVPKmLuERhHPcjkR8MZKaX4SukjyLscuZTmLEAfqC8= X-Received: by 2002:a05:701b:2705:b0:144:fd7c:84fe with SMTP id a92af1059eb24-16a6203dc1emr10890274c88.35.1791733225641; Sun, 11 Oct 2026 08:40:25 -0700 (PDT) Received: from FT6N242TWK ([223.181.119.248]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-169a32eb7ebsm26252154c88.12.2026.10.11.08.40.21 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 11 Oct 2026 08:40:25 -0700 (PDT) From: Shashank Mohan Jain To: Jens Axboe , Damien Le Moal Cc: Christoph Hellwig , Johannes Thumshirn , Hannes Reinecke , Chaitanya Kulkarni , "Martin K. Petersen" , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/2] block: two fixes for the zone report ioctls Date: Sun, 11 Oct 2026 21:10:16 +0530 Message-ID: <20261011154018.48913-1-jain.sm@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Two problems in the zone report code added in v6.19: - BLKREPORTZONEV2 does not look at BLK_ZONE_REP_CACHED and returns the cached report also when the flag is not set (patch 1). - blkdev_get_zone_info() gives a smaller last zone the length of a full zone, so the cached report describes a zone that ends behind the end of the device (patch 2). Both were found by reading the code and then confirmed with zoned null_blk devices in qemu (x86_64). The test program opens one zone explicitly, writes to a second zone and closes it, and compares the reports of BLKREPORTZONE, BLKREPORTZONEV2 with flags 0 and BLKREPORTZONEV2 with BLK_ZONE_REP_CACHED. On mainline it finds both problems. With both patches BLKREPORTZONEV2 with flags 0 returns the same device report as BLKREPORTZONE, and the cached report describes the smaller last zone with its real length. For patch 1 there is a choice between the code and the documentation. The changelog of b30ffcdc0c15 and the comments in the uapi header both say that without BLK_ZONE_REP_CACHED the report comes from the device, and BLKREPORTZONE is marked as deprecated in favour of the new ioctl, so I changed the code. If the cached report is meant to be the only mode of BLKREPORTZONEV2, the header needs to say so instead. Changes since v1: - patch 1: rewrite the BLKREPORTZONEV2 case to the positive form suggested by Damien Le Moal: take the cached report only when BLK_ZONE_REP_CACHED is set and blkdev_has_cached_report_zones() is true, and call blkdev_report_zones() in every other case. This drops the redundant blkdev_report_zones_cached() call for the no-cache case, where it would only fall back to a device report anyway, so the observable behaviour is unchanged. - patch 1: blkdev_has_cached_report_zones() is now used from blkdev_report_zones_ioctl(), so move it, with its comment, above that function rather than add a forward declaration. - patch 1: adjust the changelog to describe the new form. - patch 2 is unchanged; it keeps Damien Le Moal's Reviewed-by from v1. - retested on zoned null_blk in qemu (see below). The series is based on mainline (a5ebb76233b7, v7.3-rc6+), where both patches apply. Patch 1 also applies to linux-next (next-20261009). Patch 2 needs its context adjusted on linux-next / for-7.4/block, because blkdev_get_zone_info() there tests the zone type instead of the zone condition; I can rebase it onto that tree if you prefer to take the series there. Shashank Mohan Jain (2): block: only use the cached zone report if BLK_ZONE_REP_CACHED is set block: fix the length of a smaller last zone in blkdev_get_zone_info() block/blk-zoned.c | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) base-commit: a5ebb76233b79db01e82e061173cb73c6d2b5c6b -- 2.43.0