All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] nvme: Make nvme_init error handling code more readable
Date: Fri, 25 May 2018 09:27:34 +0200	[thread overview]
Message-ID: <87sh6gurdl.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20180525062503.GE28589@lemon.usersys.redhat.com> (Fam Zheng's message of "Fri, 25 May 2018 14:25:03 +0800")

Fam Zheng <famz@redhat.com> writes:

> On Fri, 05/25 07:47, Markus Armbruster wrote:
>> Fam Zheng <famz@redhat.com> writes:
>> 
>> > On Thu, 05/24 19:16, Paolo Bonzini wrote:
>> >> On 21/05/2018 08:35, Fam Zheng wrote:
>> >> > Coverity doesn't like the tests under fail label (report CID 1385847).
>> >> > Reset the fields so the clean up order is more apparent.
>> >> > 
>> >> > Signed-off-by: Fam Zheng <famz@redhat.com>
>> >> > ---
>> >> >  block/nvme.c | 7 +++++++
>> >> >  1 file changed, 7 insertions(+)
>> >> > 
>> >> > diff --git a/block/nvme.c b/block/nvme.c
>> >> > index 6f71122bf5..8239b920c8 100644
>> >> > --- a/block/nvme.c
>> >> > +++ b/block/nvme.c
>> >> > @@ -560,6 +560,13 @@ static int nvme_init(BlockDriverState *bs, const char *device, int namespace,
>> >> >      qemu_co_queue_init(&s->dma_flush_queue);
>> >> >      s->nsid = namespace;
>> >> >      s->aio_context = bdrv_get_aio_context(bs);
>> >> > +
>> >> > +    /* Fields we've not touched should be zero-initialized by block layer
>> >> > +     * already, but reset them anyway to make the error handling code easier to
>> >> > +     * reason. */
>> >> > +    s->regs = NULL;
>> >> > +    s->vfio = NULL;
>> >> > +
>> >> >      ret = event_notifier_init(&s->irq_notifier, 0);
>> >> >      if (ret) {
>> >> >          error_setg(errp, "Failed to init event notifier");
>> >> > 
>> >> 
>> >> I think we should just mark it as a false positive or do something like
>> >> 
>> >> fail_regs:
>> >>     qemu_vfio_pci_unmap_bar(s->vfio, 0, (void *)s->regs, 0, NVME_BAR_SIZE);
>> >> fail_vfio:
>> >>     qemu_vfio_close(s->vfio);
>> >> fail:
>> >>     g_free(s->queues);
>> >>     event_notifier_cleanup(&s->irq_notifier);
>> >>     return ret;
>> >> 
>> >> even though it's a larger patch.
>> >
>> > And that makes five labels in total, I'm not sure I like it:
>> >
>> > fail_handler:
>> >     aio_set_event_notifier(bdrv_get_aio_context(bs), &s->irq_notifier,
>> >                            false, NULL, NULL);
>> > fail_queue:
>> >     nvme_free_queue_pair(bs, s->queues[0]);
>> > fail_regs:
>> >     qemu_vfio_pci_unmap_bar(s->vfio, 0, (void *)s->regs, 0, NVME_BAR_SIZE);
>> > fail_vfio:
>> >     qemu_vfio_close(s->vfio);
>> > fail:
>> >     g_free(s->queues);
>> >     event_notifier_cleanup(&s->irq_notifier);
>> >     return ret;
>> 
>> Doesn't look materially worse to me :)
>
> The labels themselves are not ugly or bad, but the goto statements above will be
> harder to manage.

Slightly.  The difference between three and five feels smaller than say
the one between one and three.  Admittedly subjective.

>> With nice cleanup functions that detect "hasn't been set up" and do
>> nothing then, like free(NULL), you can use just one label.  Sadly,
>> cleanup functions are often not nice that way.
>
> nvme_free_queue_pair and qemu_vfio_close are cleanup functions and we can
> improve them, but to make qemu_vfio_pci_unmap_bar behave similarly is just odd:
> it's not a clean up function, at least not for s->vfio.

The technique isn't "all or nothing".  Reducing the number of labels is
nice even when you can't reduce them to one.

  reply	other threads:[~2018-05-25  7:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21  6:35 [Qemu-devel] [PATCH] nvme: Make nvme_init error handling code more readable Fam Zheng
2018-05-21  8:35 ` Peter Maydell
2018-05-21  8:56   ` Fam Zheng
2018-05-24 17:16 ` Paolo Bonzini
2018-05-25  2:16   ` Fam Zheng
2018-05-25  5:47     ` Markus Armbruster
2018-05-25  6:25       ` Fam Zheng
2018-05-25  7:27         ` Markus Armbruster [this message]
2018-05-25 13:07         ` Eric Blake

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=87sh6gurdl.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.