All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Jeff Cody" <codyprime@gmail.com>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Alberto Garcia" <berto@igalia.com>,
	"Hailiang Zhang" <zhang.zhanghailiang@huawei.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"Aleksandar Rikalo" <arikalo@wavecomp.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Anthony Green" <green@moxielogic.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Xie Changlong" <xiechanglong.d@gmail.com>,
	"Peter Lieven" <pl@kamp.de>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Beniamino Galvani" <b.galvani@gmail.com>,
	"Eric Auger" <eric.auger@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Ronnie Sahlberg" <ronniesahlberg@gmail.com>,
	"John Snow" <jsnow@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Chris Wulff" <crwulff@gmail.com>,
	"Subbaraya Sundeep" <sundeep.lkml@gmail.com>,
	"Michael Walle" <michael@walle.cc>,
	"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Fam Zheng" <fam@euphon.net>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"sheepdog@lists.wpkg.org" <sheepdog@lists.wpkg.org>,
	"Matthew Rosato" <mjrosato@linux.ibm.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	"Eric Farman" <farman@linux.ibm.com>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Hannes Reinecke" <hare@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"Liu Yuan" <namei.unix@gmail.com>,
	"Artyom Tarasenko" <atar4qemu@gmail.com>,
	"Thomas Huth" <thuth@redhat.com>, "Amit Shah" <amit@kernel.org>,
	"Stefan Weil" <sw@weilnetz.de>, "Greg Kurz" <groug@kaod.org>,
	"Yuval Shaia" <yuval.shaia@oracle.com>,
	"qemu-s390x@nongnu.org" <qemu-s390x@nongnu.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"Peter Chubb" <peter.chubb@nicta.com.au>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"qemu-riscv@nongnu.org" <qemu-riscv@nongnu.org>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Aleksandar Markovic" <amarkovic@wavecomp.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Paul Burton" <pburton@wavecomp.com>,
	"Sagar Karandikar" <sagark@eecs.berkeley.edu>,
	"Paul Durrant" <paul@xen.org>, "Jason Wang" <jasowang@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Guan Xuetao" <gxt@mprc.pku.edu.cn>,
	"Ari Sundholm" <ari@tuxera.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Michael Roth" <mdroth@linux.vnet.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Joel Stanley" <joel@jms.id.au>,
	"Jason Dillaman" <dillaman@redhat.com>,
	"Antony Pavlov" <antonynpavlov@gmail.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"integration@gluster.org" <integration@gluster.org>,
	"Laszlo Ersek" <lersek@redhat.com>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
	"Max Reitz" <mreitz@redhat.com>,
	"Denis Lunev" <den@virtuozzo.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Vincenzo Maffione" <v.maffione@gmail.com>,
	"Marek Vasut" <marex@denx.de>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Pavel Dovgalyuk" <pavel.dovgaluk@ispras.ru>,
	"Giuseppe Lettieri" <g.lettieri@iet.unipi.it>,
	"Luigi Rizzo" <rizzo@iet.unipi.it>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Tony Krowiak" <akrowiak@linux.ibm.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Xiao Guangrong" <xiaoguangrong.eric@gmail.com>,
	"Pierre Morel" <pmorel@linux.ibm.com>,
	"Wen Congyang" <wencongyang2@huawei.com>,
	"Jean-Christophe Dubois" <jcd@tribudubois.net>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Stefan Berger" <stefanb@linux.ibm.com>
Subject: Re: [RFC v5 024/126] error: auto propagated local_err
Date: Thu, 5 Dec 2019 14:58:53 +0000	[thread overview]
Message-ID: <eef60af5-ff92-3df7-bad5-c981690d66ad@virtuozzo.com> (raw)
In-Reply-To: <87d0d3c5k7.fsf@dusky.pond.sub.org>

05.12.2019 15:36, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:
> 
>> 04.12.2019 17:59, Markus Armbruster wrote:
>>> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:
>>>
>>>> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
>>>> functions with errp OUT parameter.
>>>>
>>>> It has three goals:
>>>>
>>>> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
>>>> 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
>>>> error_abort by local_err+error_propagate, resulting coredump will
>>>> refer to error_propagate and not to the place where error happened.
>>>
>>> I get what you mean, but I have plenty of context.
>>>
>>>> (the macro itself doesn't fix the issue, but it allows to [3.] drop all
>>>> local_err+error_propagate pattern, which will definitely fix the issue)
>>>
>>> The parenthesis is not part of the goal.
>>>
>>>> [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.).
>>>
>>> The paragraph talks about two cases: 1. and 2.+3.
>>
>> Hmm, I don't think so.. 1. and 2. are issues. 3. is a refactoring.. We just
>> fix achieve 2 and 3 by one action.
>>
>>> Makes me think we
>>> want two paragraphs, each illustrated with an example.
>>>
>>> What about you provide the examples, and then I try to polish the prose?
>>
>> 1: error_fatal problem
>>
>> Assume the following code flow:
>>
>> int f1(errp) {
>>      ...
>>      ret = f2(errp);
>>      if (ret < 0) {
>>         error_append_hint(errp, "very useful hint");
>>         return ret;
>>      }
>>      ...
>> }
>>
>> Now, if we call f1 with &error_fatal argument and f2 fails, the program
>> will exit immediately inside f2, when setting the errp. User will not
>> see the hint.
>>
>> So, in this case we should use local_err.
> 
> How does this example look after the transformation?

Good point.

int f1(errp) {
    ERRP_AUTO_PROPAGATE();
    ...
    ret = f2(errp);
    if (ret < 0) {
       error_append_hint(errp, "very useful hint");
       return ret;
    }
    ...
}

- nothing changed, only add macro at start. But now errp is safe, if it was
error_fatal it is wrapped by local error, and will only call exit on automatic
propagation on f1 finish.

> 
>> 2: error_abort problem
>>
>> Now, consider functions without return value. We normally use local_err
>> variable to catch failures:
>>
>> void f1(errp) {
>>      Error *local_err = NULL;
>>      ...
>>      f2(&local_err);
>>      if (local_err) {
>>          error_propagate(errp, local_err);
>>          return;
>>      }
>>      ...
>> }
>>
>> Now, if we call f2 with &error_abort and f2 fails, the stack in resulting
>> crash dump will point to error_propagate, not to the failure point in f2,
>> which complicates debugging.
>>
>> So, we should never wrap error_abort by local_err.
> 
> Likewise.

And here:

void f1(errp) {
     ERRP_AUTO_PROPAGATE();
     ...
     f2(errp);
     if (*errp) {
         return;
     }
     ...

- if errp was NULL, it is wrapped, so dereferencing errp is safe. On return,
   local error is automatically propagated to original one.

> 
>>
>> ===
>>
>> Our solution:
>>
>> - Fixes [1.], adding invocation of new macro into functions with error_appen_hint/error_prepend,
>>     New macro will wrap error_fatal.
>> - Fixes [2.], by switching from hand-written local_err to smart macro, which never
>>     wraps error_abort.
>> - Handles [3.], by switching to macro, which is less code
>> - Additionally, macro doesn't wrap normal non-zero errp, to avoid extra propagations
>>     (in fact, error_propagate is called, but returns immediately on first if (!local_err))
> 


-- 
Best regards,
Vladimir

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Jeff Cody" <codyprime@gmail.com>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Alberto Garcia" <berto@igalia.com>,
	"Hailiang Zhang" <zhang.zhanghailiang@huawei.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"Aleksandar Rikalo" <arikalo@wavecomp.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Anthony Green" <green@moxielogic.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Xie Changlong" <xiechanglong.d@gmail.com>,
	"Peter Lieven" <pl@kamp.de>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Beniamino Galvani" <b.galvani@gmail.com>,
	"Eric Auger" <eric.auger@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Ronnie Sahlberg" <ronniesahlberg@gmail.com>,
	"John Snow" <jsnow@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Chris Wulff" <crwulff@gmail.com>,
	"Subbaraya Sundeep" <sundeep.lkml@gmail.com>,
	"Michael Walle" <michael@walle.cc>,
	"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Fam Zheng" <fam@euphon.net>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"sheepdog@lists.wpkg.org" <sheepdog@lists.wpkg.org>,
	"Matthew Rosato" <mjrosato@linux.ibm.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	"Eric Farman" <farman@linux.ibm.com>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Hannes Reinecke" <hare@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"Liu Yuan" <namei.unix@gmail.com>,
	"Artyom Tarasenko" <atar4qemu@gmail.com>,
	"Thomas Huth" <thuth@redhat.com>, "Amit Shah" <amit@kernel.org>,
	"Stefan Weil" <sw@weilnetz.de>, "Greg Kurz" <groug@kaod.org>,
	"Yuval Shaia" <yuval.shaia@oracle.com>,
	"qemu-s390x@nongnu.org" <qemu-s390x@nongnu.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"Peter Chubb" <peter.chubb@nicta.com.au>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"qemu-riscv@nongnu.org" <qemu-riscv@nongnu.org>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Aleksandar Markovic" <amarkovic@wavecomp.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Paul Burton" <pburton@wavecomp.com>,
	"Sagar Karandikar" <sagark@eecs.berkeley.edu>,
	"Paul Durrant" <paul@xen.org>, "Jason Wang" <jasowang@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Guan Xuetao" <gxt@mprc.pku.edu.cn>,
	"Ari Sundholm" <ari@tuxera.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Michael Roth" <mdroth@linux.vnet.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Joel Stanley" <joel@jms.id.au>,
	"Jason Dillaman" <dillaman@redhat.com>,
	"Antony Pavlov" <antonynpavlov@gmail.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"integration@gluster.org" <integration@gluster.org>,
	"Laszlo Ersek" <lersek@redhat.com>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
	"Max Reitz" <mreitz@redhat.com>,
	"Denis Lunev" <den@virtuozzo.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Vincenzo Maffione" <v.maffione@gmail.com>,
	"Marek Vasut" <marex@denx.de>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Pavel Dovgalyuk" <pavel.dovgaluk@ispras.ru>,
	"Giuseppe Lettieri" <g.lettieri@iet.unipi.it>,
	"Luigi Rizzo" <rizzo@iet.unipi.it>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Tony Krowiak" <akrowiak@linux.ibm.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Xiao Guangrong" <xiaoguangrong.eric@gmail.com>,
	"Pierre Morel" <pmorel@linux.ibm.com>,
	"Wen Congyang" <wencongyang2@huawei.com>,
	"Jean-Christophe Dubois" <jcd@tribudubois.net>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Stefan Berger" <stefanb@linux.ibm.com>
Subject: Re: [Xen-devel] [RFC v5 024/126] error: auto propagated local_err
Date: Thu, 5 Dec 2019 14:58:53 +0000	[thread overview]
Message-ID: <eef60af5-ff92-3df7-bad5-c981690d66ad@virtuozzo.com> (raw)
In-Reply-To: <87d0d3c5k7.fsf@dusky.pond.sub.org>

05.12.2019 15:36, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:
> 
>> 04.12.2019 17:59, Markus Armbruster wrote:
>>> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:
>>>
>>>> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
>>>> functions with errp OUT parameter.
>>>>
>>>> It has three goals:
>>>>
>>>> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
>>>> 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
>>>> error_abort by local_err+error_propagate, resulting coredump will
>>>> refer to error_propagate and not to the place where error happened.
>>>
>>> I get what you mean, but I have plenty of context.
>>>
>>>> (the macro itself doesn't fix the issue, but it allows to [3.] drop all
>>>> local_err+error_propagate pattern, which will definitely fix the issue)
>>>
>>> The parenthesis is not part of the goal.
>>>
>>>> [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.).
>>>
>>> The paragraph talks about two cases: 1. and 2.+3.
>>
>> Hmm, I don't think so.. 1. and 2. are issues. 3. is a refactoring.. We just
>> fix achieve 2 and 3 by one action.
>>
>>> Makes me think we
>>> want two paragraphs, each illustrated with an example.
>>>
>>> What about you provide the examples, and then I try to polish the prose?
>>
>> 1: error_fatal problem
>>
>> Assume the following code flow:
>>
>> int f1(errp) {
>>      ...
>>      ret = f2(errp);
>>      if (ret < 0) {
>>         error_append_hint(errp, "very useful hint");
>>         return ret;
>>      }
>>      ...
>> }
>>
>> Now, if we call f1 with &error_fatal argument and f2 fails, the program
>> will exit immediately inside f2, when setting the errp. User will not
>> see the hint.
>>
>> So, in this case we should use local_err.
> 
> How does this example look after the transformation?

Good point.

int f1(errp) {
    ERRP_AUTO_PROPAGATE();
    ...
    ret = f2(errp);
    if (ret < 0) {
       error_append_hint(errp, "very useful hint");
       return ret;
    }
    ...
}

- nothing changed, only add macro at start. But now errp is safe, if it was
error_fatal it is wrapped by local error, and will only call exit on automatic
propagation on f1 finish.

> 
>> 2: error_abort problem
>>
>> Now, consider functions without return value. We normally use local_err
>> variable to catch failures:
>>
>> void f1(errp) {
>>      Error *local_err = NULL;
>>      ...
>>      f2(&local_err);
>>      if (local_err) {
>>          error_propagate(errp, local_err);
>>          return;
>>      }
>>      ...
>> }
>>
>> Now, if we call f2 with &error_abort and f2 fails, the stack in resulting
>> crash dump will point to error_propagate, not to the failure point in f2,
>> which complicates debugging.
>>
>> So, we should never wrap error_abort by local_err.
> 
> Likewise.

And here:

void f1(errp) {
     ERRP_AUTO_PROPAGATE();
     ...
     f2(errp);
     if (*errp) {
         return;
     }
     ...

- if errp was NULL, it is wrapped, so dereferencing errp is safe. On return,
   local error is automatically propagated to original one.

> 
>>
>> ===
>>
>> Our solution:
>>
>> - Fixes [1.], adding invocation of new macro into functions with error_appen_hint/error_prepend,
>>     New macro will wrap error_fatal.
>> - Fixes [2.], by switching from hand-written local_err to smart macro, which never
>>     wraps error_abort.
>> - Handles [3.], by switching to macro, which is less code
>> - Additionally, macro doesn't wrap normal non-zero errp, to avoid extra propagations
>>     (in fact, error_propagate is called, but returns immediately on first if (!local_err))
> 


-- 
Best regards,
Vladimir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Ronnie Sahlberg" <ronniesahlberg@gmail.com>,
	"Jeff Cody" <codyprime@gmail.com>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Alberto Garcia" <berto@igalia.com>,
	"Hailiang Zhang" <zhang.zhanghailiang@huawei.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"Aleksandar Rikalo" <arikalo@wavecomp.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
	"Laszlo Ersek" <lersek@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Xie Changlong" <xiechanglong.d@gmail.com>,
	"Peter Lieven" <pl@kamp.de>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Beniamino Galvani" <b.galvani@gmail.com>,
	"Eric Auger" <eric.auger@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"John Snow" <jsnow@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Chris Wulff" <crwulff@gmail.com>,
	"Subbaraya Sundeep" <sundeep.lkml@gmail.com>,
	"Michael Walle" <michael@walle.cc>,
	"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Fam Zheng" <fam@euphon.net>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"sheepdog@lists.wpkg.org" <sheepdog@lists.wpkg.org>,
	"Matthew Rosato" <mjrosato@linux.ibm.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	"Eric Farman" <farman@linux.ibm.com>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Hannes Reinecke" <hare@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"Liu Yuan" <namei.unix@gmail.com>,
	"Artyom Tarasenko" <atar4qemu@gmail.com>,
	"Thomas Huth" <thuth@redhat.com>, "Amit Shah" <amit@kernel.org>,
	"Stefan Weil" <sw@weilnetz.de>, "Greg Kurz" <groug@kaod.org>,
	"Yuval Shaia" <yuval.shaia@oracle.com>,
	"qemu-s390x@nongnu.org" <qemu-s390x@nongnu.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"Peter Chubb" <peter.chubb@nicta.com.au>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"qemu-riscv@nongnu.org" <qemu-riscv@nongnu.org>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Aleksandar Markovic" <amarkovic@wavecomp.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Paul Burton" <pburton@wavecomp.com>,
	"Sagar Karandikar" <sagark@eecs.berkeley.edu>,
	"Paul Durrant" <paul@xen.org>,
	"Anthony Green" <green@moxielogic.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Guan Xuetao" <gxt@mprc.pku.edu.cn>,
	"Ari Sundholm" <ari@tuxera.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Michael Roth" <mdroth@linux.vnet.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Joel Stanley" <joel@jms.id.au>,
	"Jason Dillaman" <dillaman@redhat.com>,
	"Antony Pavlov" <antonynpavlov@gmail.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"integration@gluster.org" <integration@gluster.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
	"Max Reitz" <mreitz@redhat.com>,
	"Denis Lunev" <den@virtuozzo.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Vincenzo Maffione" <v.maffione@gmail.com>,
	"Marek Vasut" <marex@denx.de>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Pavel Dovgalyuk" <pavel.dovgaluk@ispras.ru>,
	"Giuseppe Lettieri" <g.lettieri@iet.unipi.it>,
	"Luigi Rizzo" <rizzo@iet.unipi.it>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Tony Krowiak" <akrowiak@linux.ibm.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Xiao Guangrong" <xiaoguangrong.eric@gmail.com>,
	"Pierre Morel" <pmorel@linux.ibm.com>,
	"Wen Congyang" <wencongyang2@huawei.com>,
	"Jean-Christophe Dubois" <jcd@tribudubois.net>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Stefan Berger" <stefanb@linux.ibm.com>
Subject: Re: [RFC v5 024/126] error: auto propagated local_err
Date: Thu, 5 Dec 2019 14:58:53 +0000	[thread overview]
Message-ID: <eef60af5-ff92-3df7-bad5-c981690d66ad@virtuozzo.com> (raw)
In-Reply-To: <87d0d3c5k7.fsf@dusky.pond.sub.org>

05.12.2019 15:36, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:
> 
>> 04.12.2019 17:59, Markus Armbruster wrote:
>>> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:
>>>
>>>> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
>>>> functions with errp OUT parameter.
>>>>
>>>> It has three goals:
>>>>
>>>> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
>>>> 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
>>>> error_abort by local_err+error_propagate, resulting coredump will
>>>> refer to error_propagate and not to the place where error happened.
>>>
>>> I get what you mean, but I have plenty of context.
>>>
>>>> (the macro itself doesn't fix the issue, but it allows to [3.] drop all
>>>> local_err+error_propagate pattern, which will definitely fix the issue)
>>>
>>> The parenthesis is not part of the goal.
>>>
>>>> [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.).
>>>
>>> The paragraph talks about two cases: 1. and 2.+3.
>>
>> Hmm, I don't think so.. 1. and 2. are issues. 3. is a refactoring.. We just
>> fix achieve 2 and 3 by one action.
>>
>>> Makes me think we
>>> want two paragraphs, each illustrated with an example.
>>>
>>> What about you provide the examples, and then I try to polish the prose?
>>
>> 1: error_fatal problem
>>
>> Assume the following code flow:
>>
>> int f1(errp) {
>>      ...
>>      ret = f2(errp);
>>      if (ret < 0) {
>>         error_append_hint(errp, "very useful hint");
>>         return ret;
>>      }
>>      ...
>> }
>>
>> Now, if we call f1 with &error_fatal argument and f2 fails, the program
>> will exit immediately inside f2, when setting the errp. User will not
>> see the hint.
>>
>> So, in this case we should use local_err.
> 
> How does this example look after the transformation?

Good point.

int f1(errp) {
    ERRP_AUTO_PROPAGATE();
    ...
    ret = f2(errp);
    if (ret < 0) {
       error_append_hint(errp, "very useful hint");
       return ret;
    }
    ...
}

- nothing changed, only add macro at start. But now errp is safe, if it was
error_fatal it is wrapped by local error, and will only call exit on automatic
propagation on f1 finish.

> 
>> 2: error_abort problem
>>
>> Now, consider functions without return value. We normally use local_err
>> variable to catch failures:
>>
>> void f1(errp) {
>>      Error *local_err = NULL;
>>      ...
>>      f2(&local_err);
>>      if (local_err) {
>>          error_propagate(errp, local_err);
>>          return;
>>      }
>>      ...
>> }
>>
>> Now, if we call f2 with &error_abort and f2 fails, the stack in resulting
>> crash dump will point to error_propagate, not to the failure point in f2,
>> which complicates debugging.
>>
>> So, we should never wrap error_abort by local_err.
> 
> Likewise.

And here:

void f1(errp) {
     ERRP_AUTO_PROPAGATE();
     ...
     f2(errp);
     if (*errp) {
         return;
     }
     ...

- if errp was NULL, it is wrapped, so dereferencing errp is safe. On return,
   local error is automatically propagated to original one.

> 
>>
>> ===
>>
>> Our solution:
>>
>> - Fixes [1.], adding invocation of new macro into functions with error_appen_hint/error_prepend,
>>     New macro will wrap error_fatal.
>> - Fixes [2.], by switching from hand-written local_err to smart macro, which never
>>     wraps error_abort.
>> - Handles [3.], by switching to macro, which is less code
>> - Additionally, macro doesn't wrap normal non-zero errp, to avoid extra propagations
>>     (in fact, error_propagate is called, but returns immediately on first if (!local_err))
> 


-- 
Best regards,
Vladimir

  reply	other threads:[~2019-12-05 15:00 UTC|newest]

Thread overview: 288+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 16:03 [RFC v5 000/126] error: auto propagated local_err Vladimir Sementsov-Ogievskiy
2019-10-11 16:03 ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:03 ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-10-11 16:03 ` [RFC v5 001/126] hw/core/loader-fit: fix freeing errp in fit_load_fdt Vladimir Sementsov-Ogievskiy
2019-10-11 16:03 ` [RFC v5 002/126] net/net: Clean up variable shadowing in net_client_init() Vladimir Sementsov-Ogievskiy
2019-10-12  6:04   ` Philippe Mathieu-Daudé
2019-10-11 16:03 ` [RFC v5 003/126] error: rename errp to errp_in where it is IN-argument Vladimir Sementsov-Ogievskiy
2019-10-11 18:29   ` Eric Blake
2019-10-11 16:03 ` [RFC v5 004/126] hmp: drop Error pointer indirection in hmp_handle_error Vladimir Sementsov-Ogievskiy
2019-10-11 16:33   ` Dr. David Alan Gilbert
2019-10-11 18:32   ` Eric Blake
2019-10-11 18:35     ` Dr. David Alan Gilbert
2019-10-11 16:03 ` [RFC v5 005/126] vnc: drop Error pointer indirection in vnc_client_io_error Vladimir Sementsov-Ogievskiy
2019-10-11 16:03 ` [RFC v5 006/126] qdev-monitor: well form error hint helpers Vladimir Sementsov-Ogievskiy
2019-11-08 20:49   ` Marc-André Lureau
2019-10-11 16:03 ` [RFC v5 007/126] nbd: well form nbd_iter_channel_error errp handler Vladimir Sementsov-Ogievskiy
2019-10-11 16:48   ` Eric Blake
2019-10-11 16:03 ` [RFC v5 008/126] ppc: well form kvmppc_hint_smt_possible error hint helper Vladimir Sementsov-Ogievskiy
2019-11-08 20:50   ` Marc-André Lureau
2019-10-11 16:03 ` [RFC v5 009/126] 9pfs: well form error hint helpers Vladimir Sementsov-Ogievskiy
2019-10-12 14:59   ` Greg Kurz
2019-10-11 16:03 ` [RFC v5 010/126] hw/core/qdev: cleanup Error ** variables Vladimir Sementsov-Ogievskiy
2019-10-11 16:52   ` Eric Blake
2019-11-08 20:55   ` Marc-André Lureau
2019-10-11 16:03 ` [RFC v5 011/126] block/snapshot: rename Error ** parameter to more common errp Vladimir Sementsov-Ogievskiy
2019-10-11 16:52   ` Eric Blake
2019-10-11 16:03 ` [RFC v5 012/126] hw/i386/amd_iommu: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:03 ` [RFC v5 013/126] qga: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 014/126] monitor/qmp-cmds: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 015/126] hw/s390x: " Vladimir Sementsov-Ogievskiy
2019-11-12 13:01   ` Cornelia Huck
2019-10-11 16:04 ` [RFC v5 016/126] hw/sd: " Vladimir Sementsov-Ogievskiy
2019-10-11 18:12   ` Eric Blake
2019-10-11 16:04 ` [RFC v5 017/126] hw/tpm: " Vladimir Sementsov-Ogievskiy
2019-10-11 17:00   ` Stefan Berger
2019-10-11 16:04 ` [RFC v5 018/126] hw/usb: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 019/126] include/block/snapshot.h: " Vladimir Sementsov-Ogievskiy
2019-10-11 18:13   ` Eric Blake
2019-10-11 16:04 ` [RFC v5 020/126] include/qom/object.h: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:07   ` Philippe Mathieu-Daudé
2019-10-11 16:04 ` [RFC v5 021/126] qapi/error: add (Error **errp) cleaning APIs Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 022/126] backends/cryptodev: drop local_err from cryptodev_backend_complete() Vladimir Sementsov-Ogievskiy
2019-10-12  6:08   ` Philippe Mathieu-Daudé
2019-11-08 20:59   ` Marc-André Lureau
2019-10-11 16:04 ` [RFC v5 023/126] hw/vfio/ap: drop local_err from vfio_ap_realize Vladimir Sementsov-Ogievskiy
2019-11-08 21:00   ` Marc-André Lureau
2019-11-12 13:06   ` Cornelia Huck
2019-11-12 15:29     ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 024/126] error: auto propagated local_err Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-08 21:10   ` Marc-André Lureau
2019-11-08 21:10     ` Marc-André Lureau
2019-11-08 21:10     ` [Xen-devel] " Marc-André Lureau
2019-11-08 22:45     ` Eric Blake
2019-11-08 22:45       ` Eric Blake
2019-11-08 22:45       ` [Xen-devel] " Eric Blake
2019-12-04 14:59   ` Markus Armbruster
2019-12-04 14:59     ` Markus Armbruster
2019-12-04 14:59     ` [Xen-devel] " Markus Armbruster
2019-12-05  9:38     ` Vladimir Sementsov-Ogievskiy
2019-12-05  9:38       ` Vladimir Sementsov-Ogievskiy
2019-12-05  9:38       ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-12-05 12:36       ` Markus Armbruster
2019-12-05 12:36         ` Markus Armbruster
2019-12-05 12:36         ` [Xen-devel] " Markus Armbruster
2019-12-05 14:58         ` Vladimir Sementsov-Ogievskiy [this message]
2019-12-05 14:58           ` Vladimir Sementsov-Ogievskiy
2019-12-05 14:58           ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-12-05 16:36           ` Vladimir Sementsov-Ogievskiy
2019-12-05 16:36             ` Vladimir Sementsov-Ogievskiy
2019-12-05 16:36             ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-12-06  8:13             ` Markus Armbruster
2019-12-06  8:13               ` Markus Armbruster
2019-12-06  8:13               ` [Xen-devel] " Markus Armbruster
2019-12-05 17:32           ` Eric Blake
2019-12-05 17:32             ` Eric Blake
2019-12-05 17:32             ` [Xen-devel] " Eric Blake
2019-10-11 16:04 ` [RFC v5 025/126] scripts: add coccinelle script to use auto propagated errp Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-10-11 17:12   ` Eric Blake
2019-10-11 17:12     ` Eric Blake
2019-10-11 17:12     ` [Xen-devel] " Eric Blake
2019-10-11 18:15     ` Eric Blake
2019-10-11 18:15       ` Eric Blake
2019-10-11 18:15       ` [Xen-devel] " Eric Blake
2019-10-14  8:19     ` Vladimir Sementsov-Ogievskiy
2019-10-14  8:19       ` Vladimir Sementsov-Ogievskiy
2019-10-14  8:19       ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-10-14 14:00       ` Eric Blake
2019-10-14 14:00         ` Eric Blake
2019-10-14 14:00         ` [Xen-devel] " Eric Blake
2019-10-11 16:04 ` [RFC v5 026/126] python: add commit-per-subsystem.py Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-08 21:18   ` Marc-André Lureau
2019-11-08 21:18     ` Marc-André Lureau
2019-11-08 21:18     ` [Xen-devel] " Marc-André Lureau
2019-11-11 16:37   ` Aleksandar Markovic
2019-11-11 16:37     ` Aleksandar Markovic
2019-11-11 16:37     ` [Xen-devel] " Aleksandar Markovic
2019-11-12 13:08   ` Cornelia Huck
2019-11-12 13:08     ` Cornelia Huck
2019-11-12 13:08     ` [Xen-devel] " Cornelia Huck
2019-10-11 16:04 ` [RFC v5 027/126] misc: introduce ERRP_AUTO_PROPAGATE Vladimir Sementsov-Ogievskiy
2019-10-11 18:44   ` Eric Blake
2019-10-14  8:51     ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 028/126] s390x: " Vladimir Sementsov-Ogievskiy
2019-11-12 13:20   ` Cornelia Huck
2019-10-11 16:04 ` [RFC v5 029/126] tcg: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 030/126] kvm: " Vladimir Sementsov-Ogievskiy
2019-11-12 13:31   ` Cornelia Huck
2019-10-11 16:04 ` [RFC v5 031/126] xen: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04   ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-20 15:38   ` Anthony PERARD
2019-11-20 15:38     ` [Xen-devel] " Anthony PERARD
2019-10-11 16:04 ` [RFC v5 032/126] Hosts: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 033/126] ARM Machines: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 034/126] MIPS " Vladimir Sementsov-Ogievskiy
2019-10-12  6:22   ` Philippe Mathieu-Daudé
2019-10-14  8:55     ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 035/126] PowerPC " Vladimir Sementsov-Ogievskiy
2019-11-19 18:00   ` Greg Kurz
2019-10-11 16:04 ` [RFC v5 036/126] SPARC " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 037/126] S390 " Vladimir Sementsov-Ogievskiy
2019-11-12 13:33   ` Cornelia Huck
2019-10-11 16:04 ` [RFC v5 038/126] X86 " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 039/126] IDE: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 040/126] Floppy: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 041/126] IPack: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 042/126] PCI: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 043/126] ACPI/SMBIOS: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 044/126] Network devices: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 045/126] pflash: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:11   ` Philippe Mathieu-Daudé
2019-10-11 16:04 ` [RFC v5 046/126] SCSI: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 047/126] SD (Secure Card): " Vladimir Sementsov-Ogievskiy
2019-10-12  6:13   ` Philippe Mathieu-Daudé
2019-10-11 16:04 ` [RFC v5 048/126] USB: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 049/126] USB (serial adapter): " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 050/126] VFIO: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 051/126] vfio-ccw: " Vladimir Sementsov-Ogievskiy
2019-11-12 13:35   ` Cornelia Huck
2019-10-11 16:04 ` [RFC v5 052/126] vhost: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 053/126] virtio: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 054/126] virtio-9p: " Vladimir Sementsov-Ogievskiy
2019-11-19 16:56   ` Greg Kurz
2019-11-19 16:59     ` Vladimir Sementsov-Ogievskiy
2019-11-19 17:08       ` Greg Kurz
2019-10-11 16:04 ` [RFC v5 055/126] virtio-blk: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 056/126] virtio-ccw: " Vladimir Sementsov-Ogievskiy
2019-11-12 13:37   ` Cornelia Huck
2019-10-11 16:04 ` [RFC v5 057/126] virtio-input: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 058/126] virtio-serial: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 059/126] virtio-rng: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 060/126] megasas: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 061/126] NVDIMM: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 062/126] eepro100: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 063/126] virtio-gpu: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 064/126] fw_cfg: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:13   ` Philippe Mathieu-Daudé
2019-10-11 16:04 ` [RFC v5 065/126] XIVE: " Vladimir Sementsov-Ogievskiy
2019-11-19 18:14   ` Greg Kurz
2019-10-11 16:04 ` [RFC v5 066/126] Audio: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 067/126] block: " Vladimir Sementsov-Ogievskiy
2019-10-11 19:15   ` Eric Blake
2019-10-11 16:04 ` [RFC v5 068/126] scsi: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 069/126] chardev: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 070/126] cmdline: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 071/126] Dump: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 072/126] Memory API: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:04 ` [RFC v5 073/126] SPICE: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 074/126] Graphics: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 075/126] Main loop: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:24   ` Philippe Mathieu-Daudé
2019-10-11 16:05 ` [RFC v5 076/126] Human Monitor (HMP): " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 077/126] net: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 078/126] hostmem: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 079/126] cryptodev: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 080/126] QAPI: " Vladimir Sementsov-Ogievskiy
2019-10-11 19:22   ` Eric Blake
2019-10-11 16:05 ` [RFC v5 081/126] qga: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 082/126] QOM: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 083/126] QMP: " Vladimir Sementsov-Ogievskiy
2019-10-11 19:25   ` Eric Blake
2019-10-11 16:05 ` [RFC v5 084/126] SLIRP: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:26   ` Philippe Mathieu-Daudé
2019-10-11 16:05 ` [RFC v5 085/126] Tracing: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:26   ` Philippe Mathieu-Daudé
2019-10-11 16:05 ` [RFC v5 086/126] TPM: " Vladimir Sementsov-Ogievskiy
2019-10-16 14:35   ` Stefan Berger
2019-10-11 16:05 ` [RFC v5 087/126] Migration: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 088/126] Cryptography: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 089/126] I/O Channels: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 090/126] Sockets: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 091/126] colo: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 092/126] Record/replay: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 093/126] VMDK: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 094/126] RBD: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 095/126] Sheepdog: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 096/126] VHDX: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 097/126] VDI: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 098/126] iSCSI: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 099/126] nbd: " Vladimir Sementsov-Ogievskiy
2019-10-11 19:39   ` Eric Blake
2019-10-11 16:05 ` [RFC v5 100/126] NFS: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 101/126] SSH: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 102/126] CURL: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 103/126] GLUSTER: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 104/126] NVMe Block Driver: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 105/126] Bootdevice: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 106/126] Quorum: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 107/126] blklogwrites: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 108/126] blkverify: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 109/126] parallels: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 110/126] qed: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 111/126] raw: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 112/126] qcow2: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 113/126] qcow: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 114/126] blkdebug: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 115/126] vpc: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 116/126] vvfat: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 117/126] Replication: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 118/126] PVRDMA: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 119/126] hw/core/bus.c: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:29   ` Philippe Mathieu-Daudé
2019-10-11 16:05 ` [RFC v5 120/126] hw/cpu/core.c: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 121/126] hw/sd/ssi-sd.c: " Vladimir Sementsov-Ogievskiy
2019-10-12  6:33   ` Philippe Mathieu-Daudé
2019-10-14  9:07     ` Vladimir Sementsov-Ogievskiy
2019-10-14  9:14       ` Philippe Mathieu-Daudé
2019-10-14  9:15         ` Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 122/126] iothread.c: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 123/126] memory_mapping.c: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 124/126] target/tilegx/cpu.c: " Vladimir Sementsov-Ogievskiy
2019-10-12  7:13   ` Philippe Mathieu-Daudé
2019-10-11 16:05 ` [RFC v5 125/126] tests/test-image-locking.c: " Vladimir Sementsov-Ogievskiy
2019-10-11 16:05 ` [RFC v5 126/126] util/qemu-config.c: " Vladimir Sementsov-Ogievskiy
2019-10-11 17:02 ` [RFC v5 000/126] error: auto propagated local_err Eric Blake
2019-10-11 17:02   ` Eric Blake
2019-10-11 17:02   ` [Xen-devel] " Eric Blake
2019-10-14  8:37   ` Vladimir Sementsov-Ogievskiy
2019-10-14  8:37     ` Vladimir Sementsov-Ogievskiy
2019-10-14  8:37     ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-10-12  2:10 ` no-reply
2019-10-12  2:10   ` no-reply
2019-10-14  9:14   ` Vladimir Sementsov-Ogievskiy
2019-10-14  9:14     ` Vladimir Sementsov-Ogievskiy
2019-10-14  9:14     ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-10-12  2:52 ` no-reply
2019-10-12  2:52   ` no-reply
2019-10-14  9:11   ` Vladimir Sementsov-Ogievskiy
2019-10-14  9:11     ` Vladimir Sementsov-Ogievskiy
2019-10-14  9:11     ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-08 15:30 ` Vladimir Sementsov-Ogievskiy
2019-11-08 15:30   ` Vladimir Sementsov-Ogievskiy
2019-11-08 15:30   ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-08 18:57   ` Marc-André Lureau
2019-11-08 18:57     ` Marc-André Lureau
2019-11-08 18:57     ` [Xen-devel] " Marc-André Lureau
2019-11-12 13:46     ` Cornelia Huck
2019-11-12 13:46       ` Cornelia Huck
2019-11-12 13:46       ` [Xen-devel] " Cornelia Huck
2019-11-12 15:33       ` Vladimir Sementsov-Ogievskiy
2019-11-12 15:33         ` Vladimir Sementsov-Ogievskiy
2019-11-12 15:33         ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-20  9:50   ` Vladimir Sementsov-Ogievskiy
2019-11-20  9:50     ` Vladimir Sementsov-Ogievskiy
2019-11-20  9:50     ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-20 11:34     ` Greg Kurz
2019-11-20 12:12       ` Vladimir Sementsov-Ogievskiy
2019-11-20 12:59     ` Eric Blake
2019-11-20 12:59       ` Eric Blake
2019-11-20 12:59       ` [Xen-devel] " Eric Blake
2019-11-20 13:13       ` Kevin Wolf
2019-11-20 13:13         ` Kevin Wolf
2019-11-20 13:13         ` [Xen-devel] " Kevin Wolf
2019-11-28  8:54 ` Markus Armbruster
2019-11-28  8:54   ` Markus Armbruster
2019-11-28  8:54   ` [Xen-devel] " Markus Armbruster
2019-11-28  9:20   ` Vladimir Sementsov-Ogievskiy
2019-11-28  9:20     ` Vladimir Sementsov-Ogievskiy
2019-11-28  9:20     ` [Xen-devel] " Vladimir Sementsov-Ogievskiy
2019-11-28 12:21     ` Markus Armbruster
2019-11-28 12:21       ` Markus Armbruster
2019-11-28 12:21       ` [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=eef60af5-ff92-3df7-bad5-c981690d66ad@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=Andrew.Baumann@microsoft.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=alistair@alistair23.me \
    --cc=amarkovic@wavecomp.com \
    --cc=amit@kernel.org \
    --cc=andrew@aj.id.au \
    --cc=anthony.perard@citrix.com \
    --cc=antonynpavlov@gmail.com \
    --cc=arei.gonglei@huawei.com \
    --cc=ari@tuxera.com \
    --cc=arikalo@wavecomp.com \
    --cc=armbru@redhat.com \
    --cc=atar4qemu@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=b.galvani@gmail.com \
    --cc=berrange@redhat.com \
    --cc=berto@igalia.com \
    --cc=borntraeger@de.ibm.com \
    --cc=clg@kaod.org \
    --cc=codyprime@gmail.com \
    --cc=cohuck@redhat.com \
    --cc=crwulff@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=dgilbert@redhat.com \
    --cc=dillaman@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=fam@euphon.net \
    --cc=farman@linux.ibm.com \
    --cc=g.lettieri@iet.unipi.it \
    --cc=green@moxielogic.com \
    --cc=groug@kaod.org \
    --cc=gxt@mprc.pku.edu.cn \
    --cc=hare@suse.com \
    --cc=hpoussin@reactos.org \
    --cc=imammedo@redhat.com \
    --cc=integration@gluster.org \
    --cc=jan.kiszka@siemens.com \
    --cc=jasowang@redhat.com \
    --cc=jcd@tribudubois.net \
    --cc=jcmvbkbc@gmail.com \
    --cc=joel@jms.id.au \
    --cc=jsnow@redhat.com \
    --cc=kbastian@mail.uni-paderborn.de \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lersek@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=marex@denx.de \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=michael@walle.cc \
    --cc=mjrosato@linux.ibm.com \
    --cc=mreitz@redhat.com \
    --cc=mst@redhat.com \
    --cc=namei.unix@gmail.com \
    --cc=palmer@sifive.com \
    --cc=pasic@linux.ibm.com \
    --cc=paul@xen.org \
    --cc=pavel.dovgaluk@ispras.ru \
    --cc=pbonzini@redhat.com \
    --cc=pburton@wavecomp.com \
    --cc=peter.chubb@nicta.com.au \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=pl@kamp.de \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rizzo@iet.unipi.it \
    --cc=rjones@redhat.com \
    --cc=ronniesahlberg@gmail.com \
    --cc=rth@twiddle.net \
    --cc=sagark@eecs.berkeley.edu \
    --cc=samuel.thibault@ens-lyon.org \
    --cc=sheepdog@lists.wpkg.org \
    --cc=shorne@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=stefanb@linux.ibm.com \
    --cc=stefanha@redhat.com \
    --cc=sundeep.lkml@gmail.com \
    --cc=sw@weilnetz.de \
    --cc=thuth@redhat.com \
    --cc=v.maffione@gmail.com \
    --cc=wencongyang2@huawei.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiaoguangrong.eric@gmail.com \
    --cc=xiechanglong.d@gmail.com \
    --cc=yuval.shaia@oracle.com \
    --cc=zhang.zhanghailiang@huawei.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.