All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
From: no-reply@sashiko.virtuozzo.com
To: andrey.drobyshev@virtuozzo.com, "Denis V. Lunev" <den@openvz.org>
Cc: svt-core@virtuozzo.com, den@openvz.org
Subject: Re: [PATCH hci-dev 3/6] scsi-disk: refresh the cached capacity from the resize callback #VSTOR-130961
Date: Wed, 4 Nov 2026 13:50:52 +0000	[thread overview]
Message-ID: <010701a1a6d3ade1-17ae2bc0-05a2-4dd4-8572-79c2c51cd2e9-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261104134539.1519657-4-den@openvz.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] scsi-disk: scsi_disk_refresh_max_lba() leaves max_lba 0 for a zero-size backend
--

commit 0d24fb2b136b4040fa253df9cd5bb8b0c4064335
Author: Denis V. Lunev <den@openvz.org>

scsi-disk: refresh the cached capacity from the resize callback

This commit moves the max_lba computation out of scsi_disk_reset() into a
new helper, scsi_disk_refresh_max_lba(). It then calls the helper from
scsi_disk_resize_cb() so the cached capacity follows a backend resize.

Message-ID: <20260812121500.1034178-3-den@openvz.org>

> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c

[ ... ]

> +static void scsi_disk_refresh_max_lba(SCSIDiskState *s)
>  {
>      uint64_t nb_sectors;
>  
>      blk_get_geometry(s->qdev.conf.blk, &nb_sectors);
>  
>      nb_sectors /= s->qdev.blocksize / BDRV_SECTOR_SIZE;
>      if (nb_sectors) {
>          nb_sectors--;
>      }
>      s->qdev.max_lba = nb_sectors;
> +}

[Severity: Low]
Can max_lba end up describing a one-block device when the backend has zero
sectors?

blk_get_geometry() maps a negative blk_nb_sectors() to 0. The helper only
decrements when nb_sectors is non-zero, so max_lba stays 0 in that case.

check_lba_range() then evaluates a request for LBA 0 with length 1 as:

    sector_num + nb_sectors <= s->qdev.max_lba + 1

which is 0 + 1 <= 0 + 1, so the request is accepted. It is not refused
with LOGICAL BLOCK ADDRESS OUT OF RANGE.

The guard in scsi_disk_dma_command() does not cover this:

    if (!blk_is_available(s->qdev.conf.blk)) {
        scsi_check_condition(r, SENSE_CODE(NO_MEDIUM));
        return 0;
    }

It only tests for a missing medium, not a present medium that was resized
to 0 sectors.

The READ CAPACITY handling in scsi_disk_emulate_command_complete() takes a
different approach for a zero-size backend:

    blk_get_geometry(s->qdev.conf.blk, &nb_sectors);
    if (!nb_sectors) {
        scsi_check_condition(r, SENSE_CODE(LUN_NOT_READY));
        return 0;
    }

That path returns LUN_NOT_READY and does not touch max_lba. The new helper
has no equivalent check.

The zero-size handling was already in scsi_disk_reset(). This patch newly
applies it at runtime from scsi_disk_resize_cb(), for example after a
resize to 0 sectors or a failed size query during a replace.

I did not check how the block layer treats the request after it passes
check_lba_range(). The result is at least a wrong sense code, and possibly
an error from the backend.

Should the helper handle the zero-sector case separately, so that
check_lba_range() refuses every request in that state?

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261104134539.1519657-1-den@openvz.org?part=3

  reply	other threads:[~2026-11-04 13:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 13:45 [PATCH hci-dev 0/6] block, scsi-disk: honour a size change on child replacement #VSTOR-130961 Denis V. Lunev
2026-11-04 13:45 ` [PATCH hci-dev 1/6] block: make bdrv_co_parent_cb_resize() a proper IO API function #VSTOR-130961 Denis V. Lunev
2026-11-04 13:47   ` no-reply
2026-11-04 13:45 ` [PATCH hci-dev 2/6] block: notify the parent when a replaced child has a different size #VSTOR-130961 Denis V. Lunev
2026-11-04 13:51   ` no-reply
2026-11-04 13:45 ` [PATCH hci-dev 3/6] scsi-disk: refresh the cached capacity from the resize callback #VSTOR-130961 Denis V. Lunev
2026-11-04 13:50   ` no-reply [this message]
2026-11-04 13:45 ` [PATCH hci-dev 4/6] tests/qtest/virtio-scsi: cover a replacement that changes the size #VSTOR-130961 Denis V. Lunev
2026-11-04 13:54   ` no-reply
2026-11-04 13:45 ` [PATCH hci-dev 5/6] tests/qemu-iotests/qom-set-drive: replace with a differently sized node #VSTOR-130961 Denis V. Lunev
2026-11-04 13:51   ` no-reply
2026-11-04 13:45 ` [PATCH hci-dev 6/6] tests/qtest/virtio-scsi: cover vz-x-blockdev-replace changing the size #VSTOR-130961 Denis V. Lunev
2026-11-04 13:53   ` no-reply
2026-11-04 14:00 ` [PATCH hci-dev 0/6] block, scsi-disk: honour a size change on child replacement #VSTOR-130961 Andrey Drobyshev

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=010701a1a6d3ade1-17ae2bc0-05a2-4dd4-8572-79c2c51cd2e9-000000@eu-central-1.amazonses.com \
    --to=no-reply@sashiko.virtuozzo.com \
    --cc=andrey.drobyshev@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=svt-core@virtuozzo.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.