mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shashank Mohan Jain <jain.sm@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, Damien Le Moal <dlemoal@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	Hannes Reinecke <hare@suse.de>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	"Martin K. Petersen" <mkp@kernel.org>,
	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	[thread overview]
Message-ID: <20261011154018.48913-1-jain.sm@gmail.com> (raw)

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

             reply	other threads:[~2026-10-11 15:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11 15:40 Shashank Mohan Jain [this message]
2026-10-11 15:40 ` [PATCH v2 1/2] block: only use the cached zone report if BLK_ZONE_REP_CACHED is set Shashank Mohan Jain
2026-10-11 15:40 ` [PATCH v2 2/2] block: fix the length of a smaller last zone in blkdev_get_zone_info() Shashank Mohan Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261011154018.48913-1-jain.sm@gmail.com \
    --to=jain.sm@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=dlemoal@kernel.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=kch@nvidia.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkp@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®