All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-ppc@nongnu.org, Greg Kurz <groug@kaod.org>, qemu-devel@nongnu.org
Subject: Re: [PATCH for-5.2] spapr: Simplify error handling in spapr_phb_realize()
Date: Mon, 20 Jul 2020 21:25:51 +1000	[thread overview]
Message-ID: <20200720112551.GF215446@umbus.fritz.box> (raw)
In-Reply-To: <87lfjefsbh.fsf@dusky.pond.sub.org>

[-- Attachment #1: Type: text/plain, Size: 5154 bytes --]

On Mon, Jul 20, 2020 at 11:29:06AM +0200, Markus Armbruster wrote:
> Greg Kurz <groug@kaod.org> writes:
> 
> > The spapr_phb_realize() function has a local_err variable which
> > is used to:
> >
> > 1) check failures of spapr_irq_findone() and spapr_irq_claim()
> >
> > 2) prepend extra information to the error message
> >
> > Recent work from Markus Armbruster highlighted we get better
> > code when testing the return value of a function, rather than
> > setting up all the local_err boiler plate. For similar reasons,
> > it is now preferred to use ERRP_GUARD() and error_prepend()
> > rather than error_propagate_prepend().
> >
> > Since spapr_irq_findone() and spapr_irq_claim() return negative
> > values in case of failure, do both changes.
> >
> > This is just cleanup, no functional impact.
> >
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >
> > Since we add ERRP_GUARD(), we could theoretically check *errp
> > rather than the return value, and thus avoid the uint32_t to
> > int32_t change but I personally find it clearer the other way.
> > ---
> >  hw/ppc/spapr_pci.c |   16 +++++++---------
> >  1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> > index 21681215d405..b1ce51327db4 100644
> > --- a/hw/ppc/spapr_pci.c
> > +++ b/hw/ppc/spapr_pci.c
> > @@ -1796,6 +1796,7 @@ static void spapr_phb_destroy_msi(gpointer opaque)
> >  
> >  static void spapr_phb_realize(DeviceState *dev, Error **errp)
> >  {
> > +    ERRP_GUARD();
> >      /* We don't use SPAPR_MACHINE() in order to exit gracefully if the user
> >       * tries to add a sPAPR PHB to a non-pseries machine.
> >       */
> > @@ -1813,7 +1814,6 @@ static void spapr_phb_realize(DeviceState *dev, Error **errp)
> >      uint64_t msi_window_size = 4096;
> >      SpaprTceTable *tcet;
> >      const unsigned windows_supported = spapr_phb_windows_supported(sphb);
> > -    Error *local_err = NULL;
> >  
> >      if (!spapr) {
> >          error_setg(errp, TYPE_SPAPR_PCI_HOST_BRIDGE " needs a pseries machine");
> > @@ -1964,13 +1964,12 @@ static void spapr_phb_realize(DeviceState *dev, Error **errp)
> >  
> >      /* Initialize the LSI table */
> >      for (i = 0; i < PCI_NUM_PINS; i++) {
> > -        uint32_t irq = SPAPR_IRQ_PCI_LSI + sphb->index * PCI_NUM_PINS + i;
> > +        int32_t irq = SPAPR_IRQ_PCI_LSI + sphb->index * PCI_NUM_PINS + i;
> 
> (1)
> 
> >  
> >          if (smc->legacy_irq_allocation) {
> > -            irq = spapr_irq_findone(spapr, &local_err);
> > -            if (local_err) {
> > -                error_propagate_prepend(errp, local_err,
> > -                                        "can't allocate LSIs: ");
> > +            irq = spapr_irq_findone(spapr, errp);
> 
> (2)
> 
> > +            if (irq < 0) {
> > +                error_prepend(errp, "can't allocate LSIs: ");
> >                  /*
> >                   * Older machines will never support PHB hotplug, ie, this is an
> >                   * init only path and QEMU will terminate. No need to rollback.
> > @@ -1979,9 +1978,8 @@ static void spapr_phb_realize(DeviceState *dev, Error **errp)
> >              }
> >          }
> >  
> > -        spapr_irq_claim(spapr, irq, true, &local_err);
> > -        if (local_err) {
> > -            error_propagate_prepend(errp, local_err, "can't allocate LSIs: ");
> > +        if (spapr_irq_claim(spapr, irq, true, errp) < 0) {
> 
> (3)
> 
> > +            error_prepend(errp, "can't allocate LSIs: ");
> >              goto unrealize;
> >          }
> 
>            sphb->lsi_table[i].irq = irq;
> 
> (4)
> 
>        }
> 
> The error propagation elimination looks good to me, but I wonder whether
> int32_t is the best choice for @irq.
> 
> Before the patch:
> 
> (1) The initialization converts unsigned (I think) to uint32_t.
> 
> (2) Converts from int (value of spapr_irq_findone()) to uint32_t.
> 
> (3) spapr_irq_claim() takes int, we convert back to int.
> 
> (4) The assignment does not convert.
> 
> After the patch:
> 
> (1) The initialization converts unsigned (I think) to int32_t.
> 
> (2) Converts from int (value of spapr_irq_findone()) to int32_t.
> 
> (3) spapr_irq_claim() takes int, we convert back to int.
> 
> (4) Converts from int32_t to uint32_t
> 
> I assume the conversions are all safe before and after the patch
> (spapr_irq_claim() asserts @irq is between 0x1000 and 0x1000 + small
> change).  Still, too many conversions for my taste.  What about making
> irq plain int?  Then:
> 
> (1) The initialization converts unsigned (I think) to int.
> 
> (2) Does not convert.
> 
> (3) Does not convert.
> 
> (4) Converts from int to uint32_t.
> 
> Feels neater to me.

Sounds like a good idea.  Greg, care to post a followup patch?
> 
> Regardless:
> Reviewed-by: Markus Armbruster <armbru@redhat.com>
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2020-07-20 11:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 17:40 [PATCH for-5.2] spapr: Simplify error handling in spapr_phb_realize() Greg Kurz
2020-07-20  9:29 ` Markus Armbruster
2020-07-20 11:25   ` David Gibson [this message]

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=20200720112551.GF215446@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=armbru@redhat.com \
    --cc=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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.