From: Eric Blake <eblake@redhat.com> To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>, qemu-devel@nongnu.org Cc: "Kevin Wolf" <kwolf@redhat.com>, "Stefano Stabellini" <sstabellini@kernel.org>, "Michael Roth" <mdroth@linux.vnet.ibm.com>, qemu-block@nongnu.org, "Paul Durrant" <paul@xen.org>, "Laszlo Ersek" <lersek@redhat.com>, "Cornelia Huck" <cohuck@redhat.com>, "Greg Kurz" <groug@kaod.org>, "Max Reitz" <mreitz@redhat.com>, "Gerd Hoffmann" <kraxel@redhat.com>, "Stefan Hajnoczi" <stefanha@redhat.com>, "Anthony Perard" <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org, "Philippe Mathieu-Daudé" <philmd@redhat.com>, "Markus Armbruster" <armbru@redhat.com>, "Stefan Berger" <stefanb@linux.ibm.com> Subject: Re: [PATCH v6 02/11] error: auto propagated local_err Date: Fri, 17 Jan 2020 08:18:35 -0600 [thread overview] Message-ID: <d15df303-7152-d1e6-47b4-4a4c7d68ccf3@redhat.com> (raw) In-Reply-To: <20200110194158.14190-3-vsementsov@virtuozzo.com> On 1/10/20 1:41 PM, Vladimir Sementsov-Ogievskiy wrote: > Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of > functions with errp OUT parameter. s/with/with an/ > > It has three goals: > > 1. Fix issue with error_fatal & error_prepend/error_append_hint: user maybe s/&/and/ so it doesn't look like the C & operator. > can't see this additional information, because exit() happens in > error_setg earlier than information is added. [Reported by Greg Kurz] > > 2. Fix issue with error_abort & error_propagate: when we wrap and again > error_abort by local_err+error_propagate, resulting coredump will s/,/, the/ > refer to error_propagate and not to the place where error happened. > (the macro itself doesn't fix the issue, but it allows to [3.] drop all s/allows/allows us/ s/all/the/ > local_err+error_propagate pattern, which will definitely fix the issue) > [Reported by Kevin Wolf] > > 3. Drop local_err+error_propagate pattern, which is used to workaround > void functions with errp parameter, when caller wants to know resulting > status. (Note: actually these functions could be merely updated to > return int error code). > > To achieve these goals, we need to add invocation of the macro at start > of functions, which needs error_prepend/error_append_hint (1.); add > invocation of the macro at start of functions which do > local_err+error_propagate scenario the check errors, drop local errors > from them and just use *errp instead (2., 3.). To achieve these goals, later patches will add invocations of this macro at the start of functions with either use error_prepend/error_append_hint (solving 1) or which use local_err+error_propagate to check errors, switching those functions to use *errp instead (solving 2 and 3). > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > --- > > - * Receive an error and pass it on to the caller: > + * Receive an error and pass it on to the caller (DEPRECATED*): > * Error *err = NULL; > * foo(arg, &err); > * if (err) { > @@ -98,6 +98,50 @@ > * foo(arg, errp); > * for readability. > * > + * DEPRECATED* This pattern is deprecated now, use ERRP_AUTO_PROPAGATE macro s/use/use the/ > + * instead (defined below). > + * It's deprecated because of two things: > + * > + * 1. Issue with error_abort & error_propagate: when we wrap error_abort by s/&/and/ > + * local_err+error_propagate, resulting coredump will refer to error_propagate s/,/, the/ > + * and not to the place where error happened. > + * > + * 2. A lot of extra code of the same pattern > + * > +/* > + * ERRP_AUTO_PROPAGATE > + * > + * This macro is created to be the first line of a function which use > + * Error **errp parameter to report error. It's needed only in cases where we > + * want to use error_prepend, error_append_hint or dereference *errp. It's > + * still safe (but useless) in other cases. It doesn't _have_ to be the first line to compile (we require C99+ compilers, which allow declarations after statements); but rather because it makes it easier for our Coccinelle conversion script to catch outliers. But I think this text is okay, without calling out that extra information (maybe the commit message should mention it, though). > + * > + * If errp is NULL or points to error_fatal, it is rewritten to point to a > + * local Error object, which will be automatically propagated to the original > + * errp on function exit (see error_propagator_cleanup). > + * > + * After invocation of this macro it is always safe to dereference errp > + * (as it's not NULL anymore) and to add information (by error_prepend or > + * error_append_hint) > + * (as, if it was error_fatal, we swapped it with a local_error to be > + * propagated on cleanup). double () () looks odd, as does the mid-sentence newline. > + * > + * Note: we don't wrap the error_abort case, as we want resulting coredump > + * to point to the place where the error happened, not to error_propagate. > + */ > +#define ERRP_AUTO_PROPAGATE() \ > + g_auto(ErrorPropagator) _auto_errp_prop = {.errp = errp}; \ > + errp = ((errp == NULL || *errp == error_fatal) \ > + ? &_auto_errp_prop.local_err : errp) > + > /* > * Special error destination to abort on error. > * See error_setg() and error_propagate() for details. > The macro itself is fine, my comments are solely on the commit message and comments. Depending on how much cleanup Markus is willing to do rather than require a respin, you can add: Reviewed-by: Eric Blake <eblake@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com> To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>, qemu-devel@nongnu.org Cc: "Kevin Wolf" <kwolf@redhat.com>, "Stefano Stabellini" <sstabellini@kernel.org>, "Michael Roth" <mdroth@linux.vnet.ibm.com>, qemu-block@nongnu.org, "Paul Durrant" <paul@xen.org>, "Laszlo Ersek" <lersek@redhat.com>, "Cornelia Huck" <cohuck@redhat.com>, "Greg Kurz" <groug@kaod.org>, "Max Reitz" <mreitz@redhat.com>, "Gerd Hoffmann" <kraxel@redhat.com>, "Stefan Hajnoczi" <stefanha@redhat.com>, "Anthony Perard" <anthony.perard@citrix.com>, xen-devel@lists.xenproject.org, "Philippe Mathieu-Daudé" <philmd@redhat.com>, "Markus Armbruster" <armbru@redhat.com>, "Stefan Berger" <stefanb@linux.ibm.com> Subject: Re: [Xen-devel] [PATCH v6 02/11] error: auto propagated local_err Date: Fri, 17 Jan 2020 08:18:35 -0600 [thread overview] Message-ID: <d15df303-7152-d1e6-47b4-4a4c7d68ccf3@redhat.com> (raw) In-Reply-To: <20200110194158.14190-3-vsementsov@virtuozzo.com> On 1/10/20 1:41 PM, Vladimir Sementsov-Ogievskiy wrote: > Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of > functions with errp OUT parameter. s/with/with an/ > > It has three goals: > > 1. Fix issue with error_fatal & error_prepend/error_append_hint: user maybe s/&/and/ so it doesn't look like the C & operator. > can't see this additional information, because exit() happens in > error_setg earlier than information is added. [Reported by Greg Kurz] > > 2. Fix issue with error_abort & error_propagate: when we wrap and again > error_abort by local_err+error_propagate, resulting coredump will s/,/, the/ > refer to error_propagate and not to the place where error happened. > (the macro itself doesn't fix the issue, but it allows to [3.] drop all s/allows/allows us/ s/all/the/ > local_err+error_propagate pattern, which will definitely fix the issue) > [Reported by Kevin Wolf] > > 3. Drop local_err+error_propagate pattern, which is used to workaround > void functions with errp parameter, when caller wants to know resulting > status. (Note: actually these functions could be merely updated to > return int error code). > > To achieve these goals, we need to add invocation of the macro at start > of functions, which needs error_prepend/error_append_hint (1.); add > invocation of the macro at start of functions which do > local_err+error_propagate scenario the check errors, drop local errors > from them and just use *errp instead (2., 3.). To achieve these goals, later patches will add invocations of this macro at the start of functions with either use error_prepend/error_append_hint (solving 1) or which use local_err+error_propagate to check errors, switching those functions to use *errp instead (solving 2 and 3). > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > --- > > - * Receive an error and pass it on to the caller: > + * Receive an error and pass it on to the caller (DEPRECATED*): > * Error *err = NULL; > * foo(arg, &err); > * if (err) { > @@ -98,6 +98,50 @@ > * foo(arg, errp); > * for readability. > * > + * DEPRECATED* This pattern is deprecated now, use ERRP_AUTO_PROPAGATE macro s/use/use the/ > + * instead (defined below). > + * It's deprecated because of two things: > + * > + * 1. Issue with error_abort & error_propagate: when we wrap error_abort by s/&/and/ > + * local_err+error_propagate, resulting coredump will refer to error_propagate s/,/, the/ > + * and not to the place where error happened. > + * > + * 2. A lot of extra code of the same pattern > + * > +/* > + * ERRP_AUTO_PROPAGATE > + * > + * This macro is created to be the first line of a function which use > + * Error **errp parameter to report error. It's needed only in cases where we > + * want to use error_prepend, error_append_hint or dereference *errp. It's > + * still safe (but useless) in other cases. It doesn't _have_ to be the first line to compile (we require C99+ compilers, which allow declarations after statements); but rather because it makes it easier for our Coccinelle conversion script to catch outliers. But I think this text is okay, without calling out that extra information (maybe the commit message should mention it, though). > + * > + * If errp is NULL or points to error_fatal, it is rewritten to point to a > + * local Error object, which will be automatically propagated to the original > + * errp on function exit (see error_propagator_cleanup). > + * > + * After invocation of this macro it is always safe to dereference errp > + * (as it's not NULL anymore) and to add information (by error_prepend or > + * error_append_hint) > + * (as, if it was error_fatal, we swapped it with a local_error to be > + * propagated on cleanup). double () () looks odd, as does the mid-sentence newline. > + * > + * Note: we don't wrap the error_abort case, as we want resulting coredump > + * to point to the place where the error happened, not to error_propagate. > + */ > +#define ERRP_AUTO_PROPAGATE() \ > + g_auto(ErrorPropagator) _auto_errp_prop = {.errp = errp}; \ > + errp = ((errp == NULL || *errp == error_fatal) \ > + ? &_auto_errp_prop.local_err : errp) > + > /* > * Special error destination to abort on error. > * See error_setg() and error_propagate() for details. > The macro itself is fine, my comments are solely on the commit message and comments. Depending on how much cleanup Markus is willing to do rather than require a respin, you can add: Reviewed-by: Eric Blake <eblake@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-17 14:20 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-10 19:41 [PATCH v6 00/11] error: auto propagated local_err part I Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [PATCH v6 01/11] qapi/error: add (Error **errp) cleaning APIs Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-15 7:46 ` Greg Kurz 2020-01-15 7:46 ` [Xen-devel] " Greg Kurz 2020-01-17 13:15 ` Eric Blake 2020-01-17 13:15 ` [Xen-devel] " Eric Blake 2020-01-10 19:41 ` [PATCH v6 02/11] error: auto propagated local_err Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-13 8:50 ` Paul Durrant 2020-01-13 8:50 ` [Xen-devel] " Paul Durrant 2020-01-13 9:25 ` Vladimir Sementsov-Ogievskiy 2020-01-13 9:25 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-15 18:33 ` Greg Kurz 2020-01-15 18:33 ` [Xen-devel] " Greg Kurz 2020-01-17 14:18 ` Eric Blake [this message] 2020-01-17 14:18 ` Eric Blake 2020-01-10 19:41 ` [PATCH v6 03/11] scripts: add coccinelle script to use auto propagated errp Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-17 14:24 ` Eric Blake 2020-01-17 14:24 ` [Xen-devel] " Eric Blake 2020-01-17 14:50 ` Vladimir Sementsov-Ogievskiy 2020-01-17 14:50 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [PATCH v6 04/11] hw/sd/ssi-sd: fix error handling in ssi_sd_realize Vladimir Sementsov-Ogievskiy 2020-01-17 14:26 ` Eric Blake 2020-01-10 19:41 ` [PATCH v6 05/11] SD (Secure Card): introduce ERRP_AUTO_PROPAGATE Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [PATCH v6 06/11] pflash: " Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [PATCH v6 07/11] fw_cfg: " Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [PATCH v6 08/11] virtio-9p: " Vladimir Sementsov-Ogievskiy 2020-01-13 10:40 ` Greg Kurz 2020-01-10 19:41 ` [PATCH v6 09/11] TPM: " Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [PATCH v6 10/11] nbd: " Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [PATCH v6 11/11] xen: " Vladimir Sementsov-Ogievskiy 2020-01-10 19:41 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-13 8:57 ` Paul Durrant 2020-01-13 8:57 ` [Xen-devel] " Paul Durrant 2020-01-13 9:25 ` Vladimir Sementsov-Ogievskiy 2020-01-13 9:25 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-10 20:22 ` [Xen-devel] [PATCH v6 00/11] error: auto propagated local_err part I no-reply 2020-01-10 20:22 ` no-reply 2020-01-30 12:36 ` Vladimir Sementsov-Ogievskiy 2020-01-30 12:36 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy 2020-01-30 16:50 ` Markus Armbruster 2020-01-30 16:50 ` [Xen-devel] " Markus Armbruster
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=d15df303-7152-d1e6-47b4-4a4c7d68ccf3@redhat.com \ --to=eblake@redhat.com \ --cc=anthony.perard@citrix.com \ --cc=armbru@redhat.com \ --cc=cohuck@redhat.com \ --cc=groug@kaod.org \ --cc=kraxel@redhat.com \ --cc=kwolf@redhat.com \ --cc=lersek@redhat.com \ --cc=mdroth@linux.vnet.ibm.com \ --cc=mreitz@redhat.com \ --cc=paul@xen.org \ --cc=philmd@redhat.com \ --cc=qemu-block@nongnu.org \ --cc=qemu-devel@nongnu.org \ --cc=sstabellini@kernel.org \ --cc=stefanb@linux.ibm.com \ --cc=stefanha@redhat.com \ --cc=vsementsov@virtuozzo.com \ --cc=xen-devel@lists.xenproject.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: linkBe 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.