[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 06/15] hw/xen: automatically assign device index to block devi
|
From: |
David Woodhouse |
|
Subject: |
Re: [PULL 06/15] hw/xen: automatically assign device index to block devices |
|
Date: |
Thu, 09 Nov 2023 14:55:42 +0000 |
|
User-agent: |
Evolution 3.44.4-0ubuntu2 |
On Thu, 2023-11-09 at 14:33 +0000, Peter Maydell wrote:
> On Tue, 7 Nov 2023 at 09:24, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > There's no need to force the user to assign a vdev. We can automatically
> > assign one, starting at xvda and searching until we find the first disk
> > name that's unused.
> >
> > This means we can now allow '-drive if=xen,file=xxx' to work without an
> > explicit separate -driver argument, just like if=virtio.
> >
> > Rip out the legacy handling from the xenpv machine, which was scribbling
> > over any disks configured by the toolstack, and didn't work with anything
> > but raw images.
>
> Hi; Coverity points out an issue in this code (CID 1523906):
Thanks! I think this one is a false positive, although I'm happy to
explore possible cleanups which make it clearer both to the human
reader and to Coverity.
> > +/*
> > + * Find a free device name in the xvda → xvdfan range and set it in
> > + * blockdev->props.vdev. Our definition of "free" is that there must
> > + * be no other disk or partition with the same disk number.
> > + *
> > + * You are technically permitted to have all of hda, hda1, sda, sda1,
> > + * xvda and xvda1 as *separate* PV block devices with separate backing
> > + * stores. That doesn't make it a good idea. This code will skip xvda
> > + * if *any* of those "conflicting" devices already exists.
> > + *
> > + * The limit of xvdfan (disk 4095) is fairly arbitrary just to avoid a
> > + * stupidly sized bitmap, but Linux as of v6.6 doesn't support anything
> > + * higher than that anyway.
> > + */
> > +static bool xen_block_find_free_vdev(XenBlockDevice *blockdev, Error
> > **errp)
> > +{
> > + XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(blockdev)));
> > + unsigned long used_devs[BITS_TO_LONGS(MAX_AUTO_VDEV)];
> > + XenBlockVdev *vdev = &blockdev->props.vdev;
> > + char fe_path[XENSTORE_ABS_PATH_MAX + 1];
> > + char **existing_frontends;
> > + unsigned int nr_existing = 0;
> > + unsigned int vdev_nr;
> > + int i, disk = 0;
> > +
> > + snprintf(fe_path, sizeof(fe_path), "/local/domain/%u/device/vbd",
> > + blockdev->xendev.frontend_id);
> > +
> > + existing_frontends = qemu_xen_xs_directory(xenbus->xsh, XBT_NULL,
> > fe_path,
> > + &nr_existing);
> > + if (!existing_frontends && errno != ENOENT) {
>
> Here we check whether existing_frontends is NULL, implying it
> might be NULL (and the && in the condition means we might not
> take this error-exit path even if it is NULL)...
True, but nr_existing will be zero in that case, and we'll never go
into the loop where existing_frontends[] is dereferenced.
I suppose we could add something like this. Would it help Coverity to
realise that it's a false positive?
/*
* If the directory didn't exist (the ENOENT case) then nr_existing
* will still be zero, and the loop below won't dereference the
* existing_frontends pointer which is NULL.
*/
assert(existing_frontends || !nr_existing);
> > + error_setg_errno(errp, errno, "cannot read %s", fe_path);
> > + return false;
> > + }
> > +
> > + memset(used_devs, 0, sizeof(used_devs));
> > + for (i = 0; i < nr_existing; i++) {
> > + if (qemu_strtoui(existing_frontends[i], NULL, 10, &vdev_nr)) {
>
> ...but here we deref existing_frontends, implying it can't be NULL.
>
If you got to this line of code, it can't.
> > + free(existing_frontends[i]);
> > + continue;
> > + }
> > +
> > + free(existing_frontends[i]);
> > +
> > + disk = vdev_to_diskno(vdev_nr);
> > + if (disk < 0 || disk >= MAX_AUTO_VDEV) {
> > + continue;
> > + }
> > +
> > + set_bit(disk, used_devs);
> > + }
> > + free(existing_frontends);
*Here* it can be NULL. But free(NULL) is fine.
smime.p7s
Description: S/MIME cryptographic signature
- [PULL 02/15] hw/xen: Clean up event channel 'type_val' handling to use union, (continued)
- [PULL 02/15] hw/xen: Clean up event channel 'type_val' handling to use union, David Woodhouse, 2023/11/07
- [PULL 15/15] docs: update Xen-on-KVM documentation, David Woodhouse, 2023/11/07
- [PULL 01/15] i386/xen: Ignore VCPU_SSHOTTMR_future flag in set_singleshot_timer(), David Woodhouse, 2023/11/07
- [PULL 10/15] hw/xen: add support for Xen primary console in emulated mode, David Woodhouse, 2023/11/07
- [PULL 03/15] include: update Xen public headers to Xen 4.17.2 release, David Woodhouse, 2023/11/07
- [PULL 12/15] hw/xen: update Xen PV NIC to XenDevice model, David Woodhouse, 2023/11/07
- [PULL 14/15] xen-platform: unplug AHCI disks, David Woodhouse, 2023/11/07
- [PULL 07/15] hw/xen: add get_frontend_path() method to XenDeviceClass, David Woodhouse, 2023/11/07
- [PULL 06/15] hw/xen: automatically assign device index to block devices, David Woodhouse, 2023/11/07
- [PULL 08/15] hw/xen: do not repeatedly try to create a failing backend device, David Woodhouse, 2023/11/07
- Re: [PULL 00/15] xenfv.for-upstream queue, Stefan Hajnoczi, 2023/11/07