From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: "fam@euphon.net" <fam@euphon.net>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"mst@redhat.com" <mst@redhat.com>,
"codyprime@gmail.com" <codyprime@gmail.com>,
"mark.cave-ayland@ilande.co.uk" <mark.cave-ayland@ilande.co.uk>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"armbru@redhat.com" <armbru@redhat.com>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"mreitz@redhat.com" <mreitz@redhat.com>,
Eric Blake <eblake@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
"quintela@redhat.com" <quintela@redhat.com>,
"david@redhat.com" <david@redhat.com>,
"mdroth@linux.vnet.ibm.com" <mdroth@linux.vnet.ibm.com>,
"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"marcandre.lureau@redhat.com" <marcandre.lureau@redhat.com>,
"rth@twiddle.net" <rth@twiddle.net>,
"farman@linux.ibm.com" <farman@linux.ibm.com>,
"groug@kaod.org" <groug@kaod.org>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"jsnow@redhat.com" <jsnow@redhat.com>,
"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
"berrange@redhat.com" <berrange@redhat.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"qemu-s390x@nongnu.org" <qemu-s390x@nongnu.org>,
"sundeep.lkml@gmail.com" <sundeep.lkml@gmail.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [Qemu-arm] [RFC] error: auto propagated local_err
Date: Thu, 19 Sep 2019 15:03:17 +0200 [thread overview]
Message-ID: <20190919130317.GG10163@localhost.localdomain> (raw)
In-Reply-To: <1ee95d94-d3f9-2f56-a0bb-61d31e3ceeb7@virtuozzo.com>
Am 19.09.2019 um 14:00 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 19.09.2019 12:17, Kevin Wolf wrote:
> > Am 18.09.2019 um 19:10 hat Eric Blake geschrieben:
> >> On 9/18/19 8:02 AM, Vladimir Sementsov-Ogievskiy wrote:
> >>> + */
> >>> +#define MAKE_ERRP_SAFE(errp) \
> >>> +g_auto(ErrorPropagationStruct) (__auto_errp_prop) = {.errp = (errp)}; \
> >>> +if ((errp) == NULL || *(errp) == error_abort || *(errp) == error_fatal) { \
> >>> + (errp) = &__auto_errp_prop.local_err; \
> >>> +}
> >>
> >> Not written to take a trailing semicolon in the caller.
> >>
> >> You could even set __auto_errp_prop unconditionally rather than trying
> >> to reuse incoming errp (the difference being that error_propagate() gets
> >> called more frequently).
> >
> > I think this difference is actually a problem.
> >
> > When debugging things, I hate error_propagate(). It means that the Error
> > (specifically its fields src/func/line) points to the outermost
> > error_propagate() rather than the place where the error really happened.
> > It also makes error_abort completely useless because at the point where
> > the process gets aborted, the interesting information is already lost.
> >
> > So I'd really like to restrict the use of error_propagate() to places
> > where it's absolutely necessary. Unless, of course, you can fix these
> > practical problems that error_propagate() causes for debugging.
> >
> > In fact, in the context of Greg's series, I think we really only need to
> > support hints for error_fatal, which are cases that users are supposed
> > to see. We should exclude error_abort in MAKE_ERRP_SAFE() because these
> > are things that are never supposed to happen. A good stack trace is more
> > important there than adding a hint to the message.
> >
>
> Interesting, that to handle error_append_hint problem, we don't need to
> create local_err in case of errp==NULL either..
>
> So, possibly, we need the following steps:
>
> 1. implement MAKE_ERRP_SAFE_FOR_HINT (which only leave "*(errp) == error_fatal" in the if condition
> 2. rebase Greg's series on it, to fix hints for fatal errors
> 3. implement MAKE_ERRP_SAFE_FOR_DEREFERENCE (which only leave "(errp) == NULL" in the if condition
> 4. convert all (almost all) local_err usage to use MAKE_ERRP_SAFE_FOR_DEREFERENCE, which will
> fix problem with error_abort (and also drop a lot of calls of error_propagate)
> 5. merely convert "void func(.., errp)" to "int func(.., errp)" and drop MAKE_ERRP_SAFE_FOR_DEREFERENCE()
> magic, together with dereferencing.
Long macro names, but as the parameter will always only be "errp", it
fits easily on a line, so this is fine.
I think I like this plan.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: "fam@euphon.net" <fam@euphon.net>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"mst@redhat.com" <mst@redhat.com>,
"codyprime@gmail.com" <codyprime@gmail.com>,
"mark.cave-ayland@ilande.co.uk" <mark.cave-ayland@ilande.co.uk>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"armbru@redhat.com" <armbru@redhat.com>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"mreitz@redhat.com" <mreitz@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
"quintela@redhat.com" <quintela@redhat.com>,
"david@redhat.com" <david@redhat.com>,
"mdroth@linux.vnet.ibm.com" <mdroth@linux.vnet.ibm.com>,
"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"marcandre.lureau@redhat.com" <marcandre.lureau@redhat.com>,
"rth@twiddle.net" <rth@twiddle.net>,
"farman@linux.ibm.com" <farman@linux.ibm.com>,
"groug@kaod.org" <groug@kaod.org>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"jsnow@redhat.com" <jsnow@redhat.com>,
"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
"berrange@redhat.com" <berrange@redhat.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"qemu-s390x@nongnu.org" <qemu-s390x@nongnu.org>,
"sundeep.lkml@gmail.com" <sundeep.lkml@gmail.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC] error: auto propagated local_err
Date: Thu, 19 Sep 2019 15:03:17 +0200 [thread overview]
Message-ID: <20190919130317.GG10163@localhost.localdomain> (raw)
In-Reply-To: <1ee95d94-d3f9-2f56-a0bb-61d31e3ceeb7@virtuozzo.com>
Am 19.09.2019 um 14:00 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 19.09.2019 12:17, Kevin Wolf wrote:
> > Am 18.09.2019 um 19:10 hat Eric Blake geschrieben:
> >> On 9/18/19 8:02 AM, Vladimir Sementsov-Ogievskiy wrote:
> >>> + */
> >>> +#define MAKE_ERRP_SAFE(errp) \
> >>> +g_auto(ErrorPropagationStruct) (__auto_errp_prop) = {.errp = (errp)}; \
> >>> +if ((errp) == NULL || *(errp) == error_abort || *(errp) == error_fatal) { \
> >>> + (errp) = &__auto_errp_prop.local_err; \
> >>> +}
> >>
> >> Not written to take a trailing semicolon in the caller.
> >>
> >> You could even set __auto_errp_prop unconditionally rather than trying
> >> to reuse incoming errp (the difference being that error_propagate() gets
> >> called more frequently).
> >
> > I think this difference is actually a problem.
> >
> > When debugging things, I hate error_propagate(). It means that the Error
> > (specifically its fields src/func/line) points to the outermost
> > error_propagate() rather than the place where the error really happened.
> > It also makes error_abort completely useless because at the point where
> > the process gets aborted, the interesting information is already lost.
> >
> > So I'd really like to restrict the use of error_propagate() to places
> > where it's absolutely necessary. Unless, of course, you can fix these
> > practical problems that error_propagate() causes for debugging.
> >
> > In fact, in the context of Greg's series, I think we really only need to
> > support hints for error_fatal, which are cases that users are supposed
> > to see. We should exclude error_abort in MAKE_ERRP_SAFE() because these
> > are things that are never supposed to happen. A good stack trace is more
> > important there than adding a hint to the message.
> >
>
> Interesting, that to handle error_append_hint problem, we don't need to
> create local_err in case of errp==NULL either..
>
> So, possibly, we need the following steps:
>
> 1. implement MAKE_ERRP_SAFE_FOR_HINT (which only leave "*(errp) == error_fatal" in the if condition
> 2. rebase Greg's series on it, to fix hints for fatal errors
> 3. implement MAKE_ERRP_SAFE_FOR_DEREFERENCE (which only leave "(errp) == NULL" in the if condition
> 4. convert all (almost all) local_err usage to use MAKE_ERRP_SAFE_FOR_DEREFERENCE, which will
> fix problem with error_abort (and also drop a lot of calls of error_propagate)
> 5. merely convert "void func(.., errp)" to "int func(.., errp)" and drop MAKE_ERRP_SAFE_FOR_DEREFERENCE()
> magic, together with dereferencing.
Long macro names, but as the parameter will always only be "errp", it
fits easily on a line, so this is fine.
I think I like this plan.
Kevin
next prev parent reply other threads:[~2019-09-19 13:41 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 13:02 [Qemu-arm] [RFC] error: auto propagated local_err Vladimir Sementsov-Ogievskiy
2019-09-18 13:02 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-18 17:10 ` Eric Blake
2019-09-18 17:46 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-18 17:46 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-18 18:05 ` Eric Blake
2019-09-18 18:32 ` [Qemu-arm] " Eric Blake
2019-09-18 18:32 ` [Qemu-devel] " Eric Blake
2019-09-19 6:47 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 6:47 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 13:29 ` [Qemu-arm] " Eric Blake
2019-09-19 13:29 ` [Qemu-devel] " Eric Blake
2019-09-19 9:17 ` [Qemu-arm] " Kevin Wolf
2019-09-19 9:17 ` [Qemu-devel] " Kevin Wolf
2019-09-19 9:47 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 9:47 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 10:09 ` Daniel P. Berrangé
2019-09-19 10:21 ` Vladimir Sementsov-Ogievskiy
2019-09-19 11:55 ` [Qemu-arm] " Daniel P. Berrangé
2019-09-19 11:55 ` Daniel P. Berrangé
2019-09-19 12:00 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 12:00 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 13:03 ` Kevin Wolf [this message]
2019-09-19 13:03 ` Kevin Wolf
2019-09-19 13:17 ` Vladimir Sementsov-Ogievskiy
2019-09-19 13:44 ` Eric Blake
2019-09-19 13:40 ` [Qemu-arm] " Eric Blake
2019-09-19 13:40 ` [Qemu-devel] " Eric Blake
2019-09-19 14:13 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 14:13 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 14:26 ` [Qemu-arm] " Eric Blake
2019-09-19 14:26 ` Eric Blake
2019-09-19 14:30 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 14:30 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:44 ` [Qemu-arm] " Eric Blake
2019-09-19 14:44 ` Eric Blake
2019-09-19 14:49 ` [Qemu-arm] " Daniel P. Berrangé
2019-09-19 14:49 ` Daniel P. Berrangé
2019-09-19 15:24 ` Eric Blake
2019-09-19 15:37 ` Vladimir Sementsov-Ogievskiy
2019-09-19 15:50 ` Daniel P. Berrangé
2019-09-19 16:16 ` Vladimir Sementsov-Ogievskiy
2019-09-19 16:51 ` Daniel P. Berrangé
2019-09-19 16:51 ` Daniel P. Berrangé
2019-09-20 12:58 ` Eric Blake
2019-09-19 15:12 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:34 ` [Qemu-arm] " Kevin Wolf
2019-09-19 14:34 ` Kevin Wolf
2019-09-19 1:54 ` [Qemu-arm] [Qemu-devel] " no-reply
2019-09-19 1:54 ` no-reply
2019-09-19 7:32 ` [Qemu-arm] " David Hildenbrand
2019-09-19 7:32 ` [Qemu-devel] " David Hildenbrand
2019-09-19 7:41 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 7:41 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 7:53 ` [Qemu-arm] " David Hildenbrand
2019-09-19 7:53 ` [Qemu-devel] " David Hildenbrand
2019-09-19 8:20 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 8:20 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 8:23 ` [Qemu-arm] " David Hildenbrand
2019-09-19 8:23 ` [Qemu-devel] " David Hildenbrand
2019-09-19 8:59 ` [Qemu-arm] " Greg Kurz
2019-09-19 8:59 ` [Qemu-devel] " Greg Kurz
2019-09-19 9:28 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 9:28 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 10:08 ` Greg Kurz
2019-09-19 8:59 ` Max Reitz
2019-09-19 9:14 ` [Qemu-arm] " Vladimir Sementsov-Ogievskiy
2019-09-19 9:14 ` [Qemu-devel] " Vladimir Sementsov-Ogievskiy
2019-09-19 9:33 ` [Qemu-arm] " Max Reitz
2019-09-19 9:33 ` [Qemu-devel] " Max Reitz
2019-09-19 10:03 ` Vladimir Sementsov-Ogievskiy
2019-09-19 11:52 ` [Qemu-arm] " Max Reitz
2019-09-19 11:52 ` [Qemu-devel] " Max Reitz
2019-09-20 11:46 ` Vladimir Sementsov-Ogievskiy
2019-09-20 11:46 ` Vladimir Sementsov-Ogievskiy
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=20190919130317.GG10163@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=codyprime@gmail.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=farman@linux.ibm.com \
--cc=groug@kaod.org \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
--cc=sundeep.lkml@gmail.com \
--cc=vsementsov@virtuozzo.com \
/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.