qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL v2 10/16] block: introduce zone append write for zoned devices


From: Sam Li
Subject: Re: [PULL v2 10/16] block: introduce zone append write for zoned devices
Date: Sat, 3 Jun 2023 01:23:09 +0800

Peter Maydell <peter.maydell@linaro.org> 于2023年6月3日周六 00:52写道:
>
> On Mon, 15 May 2023 at 17:06, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > From: Sam Li <faithilikerun@gmail.com>
> >
> > A zone append command is a write operation that specifies the first
> > logical block of a zone as the write position. When writing to a zoned
> > block device using zone append, the byte offset of the call may point at
> > any position within the zone to which the data is being appended. Upon
> > completion the device will respond with the position where the data has
> > been written in the zone.
> >
> > Signed-off-by: Sam Li <faithilikerun@gmail.com>
> > Reviewed-by: Dmitry Fomichev <dmitry.fomichev@wdc.com>
> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Message-id: 20230508051510.177850-3-faithilikerun@gmail.com
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>
> Hi; Coverity flagged up a possible bug here (CID 1512459):
>
> > @@ -2453,8 +2454,12 @@ static int coroutine_fn raw_co_prw(BlockDriverState 
> > *bs, uint64_t offset,
> >      if (fd_open(bs) < 0)
> >          return -EIO;
> >  #if defined(CONFIG_BLKZONED)
> > -    if (type & QEMU_AIO_WRITE && bs->wps) {
> > +    if ((type & (QEMU_AIO_WRITE | QEMU_AIO_ZONE_APPEND)) && bs->wps) {
>
> Here we check for bs->wps being NULL, which implies that it might be NULL...
>
> >          qemu_co_mutex_lock(&bs->wps->colock);
> > +        if (type & QEMU_AIO_ZONE_APPEND && bs->bl.zone_size) {
> > +            int index = offset / bs->bl.zone_size;
> > +            offset = bs->wps->wp[index];
> > +        }
> >      }
> >  #endif
> >
> > @@ -2502,9 +2507,13 @@ out:
> >  {
> >      BlockZoneWps *wps = bs->wps;
> >      if (ret == 0) {
> > -        if (type & QEMU_AIO_WRITE && wps && bs->bl.zone_size) {
> > +        if ((type & (QEMU_AIO_WRITE | QEMU_AIO_ZONE_APPEND))
> > +            && wps && bs->bl.zone_size) {
> >              uint64_t *wp = &wps->wp[offset / bs->bl.zone_size];
> >              if (!BDRV_ZT_IS_CONV(*wp)) {
> > +                if (type & QEMU_AIO_ZONE_APPEND) {
> > +                    *s->offset = *wp;
> > +                }
> >                  /* Advance the wp if needed */
> >                  if (offset + bytes > *wp) {
> >                      *wp = offset + bytes;
> > @@ -2512,12 +2521,12 @@ out:
> >              }
> >          }
> >      } else {
> > -        if (type & QEMU_AIO_WRITE) {
> > +        if (type & (QEMU_AIO_WRITE | QEMU_AIO_ZONE_APPEND)) {
>
> ...but here we do not, even though update_zones_wp() can
> dereference bs->wps in some code paths.
>
> Should we be checking for NULL here before calling, or
> should update_zones_wp() handle a NULL bs->wps, or something else?

Hi Peter,

Thanks for spotting this. You are right that bs->wps is not checked in
this code path. I think the get_zones_wp() should handle a NULL
bs->wps which is the function calling wps directly.

Would you like to submit a patch for this? Or I can do it if you are
not available.

Thanks,
Sam

>
> >              update_zones_wp(bs, s->fd, 0, 1);
> >          }
> >      }
> >
> > -    if (type & QEMU_AIO_WRITE && wps) {
> > +    if ((type & (QEMU_AIO_WRITE | QEMU_AIO_ZONE_APPEND)) && wps) {
> >          qemu_co_mutex_unlock(&wps->colock);
> >      }
> >  }
>
> thanks
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]