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

Re: [PULL 22/27] hw/xen: Add emulated implementation of XenStore operations



On Tue, 7 Mar 2023 at 18:27, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
>
> Now that we have an internal implementation of XenStore, we can populate
> the xenstore_backend_ops to allow PV backends to talk to it.
>
> Watches can't be processed with immediate callbacks because that would
> call back into XenBus code recursively. Defer them to a QEMUBH to be run
> as appropriate from the main loop. We use a QEMUBH per XS handle, and it
> walks all the watches (there shouldn't be many per handle) to fire any
> which have pending events. We *could* have done it differently but this
> allows us to use the same struct watch_event as we have for the guest
> side, and keeps things relatively simple.


> +static struct qemu_xs_handle *xs_be_open(void)
> +{
> +    XenXenstoreState *s = xen_xenstore_singleton;
> +    struct qemu_xs_handle *h;
> +
> +    if (!s && !s->impl) {

Coverity points out that this will dereference a NULL pointer
if you hand it one, and will happily let through a XenXenstoreState
where s->impl is NULL.
Should be "!s || !s->impl" I guess ?
CID 1508131.

> +        errno = -ENOSYS;
> +        return NULL;
> +    }
> +
> +    h = g_new0(struct qemu_xs_handle, 1);
> +    h->impl = s->impl;
> +
> +    h->watch_bh = aio_bh_new(qemu_get_aio_context(), be_watch_bh, h);
> +
> +    return h;
> +}

thanks
-- PMM



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.