Peter Maydell <peter.mayd...@linaro.org> 于2023年6月3日周六 01:30写道：
>
> On Fri, 2 Jun 2023 at 18:23, Sam Li <faithilike...@gmail.com> wrote:
> >
> > Peter Maydell <peter.mayd...@linaro.org> 于2023年6月3日周六 00:52写道：
> > >
> > > On Mon, 15 May 2023 at 17:06, Stefan Hajnoczi <stefa...@redhat.com> wrote:
> > > >
> > > > From: Sam Li <faithilike...@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 <faithilike...@gmail.com>
> > > > Reviewed-by: Dmitry Fomichev <dmitry.fomic...@wdc.com>
> > > > Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
> > > > Message-id: 20230508051510.177850-3-faithilike...@gmail.com
> > > > Signed-off-by: Stefan Hajnoczi <stefa...@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.
>
> I don't know anything about this code, so I'm not really in
> a position to write a patch. I'm just passing on the information
> from the Coverity scanner -- it scales a lot better that way
> than trying to write fixes for everything myself :-)
I see. I'll fix it. Wish I had known more about this tool when I was
testing this code.
Thanks,
Sam
