These five patches almost get the Reviewed-by and are extracted from
previous "[PATCH RFC v7 0/9] qemu_thread_create: propagate errors to
callers to check."  The mentioned patch series have waited on one
multifd issue for a while and still needs a further discussion.

Thus separate(send) these five almost-done patches and hope they can
be merged for the next tag. Thanks for the review. :)

v2:
- Update the commit message for patch 1/5, and get one more
  Reviewed-by.
- Get one Reviewed-by for patch 3/5.


Fei Li (5):
  Fix segmentation fault when qemu_signal_init fails
  qemu_thread_join: fix segmentation fault
  migration: fix the multifd code when receiving less channels
  migration: remove unused &local_err parameter in multifd_save_cleanup
  migration: add more error handling for postcopy_ram_enable_notify

 migration/channel.c      | 11 ++++++-----
 migration/migration.c    | 14 ++++++++------
 migration/migration.h    |  2 +-
 migration/postcopy-ram.c |  1 +
 migration/ram.c          | 18 ++++++++++--------
 migration/ram.h          |  4 ++--
 migration/savevm.c       |  1 +
 util/main-loop.c         |  8 ++++----
 util/qemu-thread-posix.c |  3 +++
 util/qemu-thread-win32.c |  2 +-
 10 files changed, 37 insertions(+), 27 deletions(-)

-- 
2.13.7

On 11/29/18 4:03 AM, Fei Li wrote:
> These five patches almost get the Reviewed-by and are extracted from
> previous "[PATCH RFC v7 0/9] qemu_thread_create: propagate errors to
> callers to check."  The mentioned patch series have waited on one
> multifd issue for a while and still needs a further discussion.
> 
> Thus separate(send) these five almost-done patches and hope they can
> be merged for the next tag. Thanks for the review. :)

How likely are any of these crashers to affect an end user? Are any of 
them regressions over 3.0?  I'm trying to gauge if any of this is 
serious enough to warrant a -rc4, or if we are okay just documenting 
them as known corner-case bugs and deferring the fix to 4.0 and 
qemu-stable.  The fact that the series is still titled RFC is also an 
argument in favor of deferral.

> 
> v2:
> - Update the commit message for patch 1/5, and get one more
>    Reviewed-by.
> - Get one Reviewed-by for patch 3/5.
> 
> 
> Fei Li (5):
>    Fix segmentation fault when qemu_signal_init fails
>    qemu_thread_join: fix segmentation fault
>    migration: fix the multifd code when receiving less channels
>    migration: remove unused &local_err parameter in multifd_save_cleanup
>    migration: add more error handling for postcopy_ram_enable_notify

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On 11/29/2018 10:20 PM, Eric Blake wrote:
> On 11/29/18 4:03 AM, Fei Li wrote:
>> These five patches almost get the Reviewed-by and are extracted from
>> previous "[PATCH RFC v7 0/9] qemu_thread_create: propagate errors to
>> callers to check."  The mentioned patch series have waited on one
>> multifd issue for a while and still needs a further discussion.
>>
>> Thus separate(send) these five almost-done patches and hope they can
>> be merged for the next tag. Thanks for the review. :)
>
> How likely are any of these crashers to affect an end user? 
IMHO, they are not easily triggered.
> Are any of them regressions over 3.0?
I do not think so.
> I'm trying to gauge if any of this is serious enough to warrant a 
> -rc4, or if we are okay just documenting them as known corner-case 
> bugs and deferring the fix to 4.0 and qemu-stable.
Emm, actually not so emergency to be included in -rc4.
And I think it is ok to wait for maintainers to do the pick for the 
appropriate release.
BTW, why 4.0, but not 3.2 or 3.3 (I mean 3.minor version)?
> The fact that the series is still titled RFC is also an argument in 
> favor of deferral.
Sorry that I forgot to remove the RFC..

Have a nice day, thanks :)
Fei
>
>>
>> v2:
>> - Update the commit message for patch 1/5, and get one more
>>    Reviewed-by.
>> - Get one Reviewed-by for patch 3/5.
>>
>>
>> Fei Li (5):
>>    Fix segmentation fault when qemu_signal_init fails
>>    qemu_thread_join: fix segmentation fault
>>    migration: fix the multifd code when receiving less channels
>>    migration: remove unused &local_err parameter in multifd_save_cleanup
>>    migration: add more error handling for postcopy_ram_enable_notify
>

On 11/30/18 12:15 AM, Fei Li wrote:
> 
> 
> On 11/29/2018 10:20 PM, Eric Blake wrote:
>> On 11/29/18 4:03 AM, Fei Li wrote:
>>> These five patches almost get the Reviewed-by and are extracted from
>>> previous "[PATCH RFC v7 0/9] qemu_thread_create: propagate errors to
>>> callers to check."  The mentioned patch series have waited on one
>>> multifd issue for a while and still needs a further discussion.
>>>
>>> Thus separate(send) these five almost-done patches and hope they can
>>> be merged for the next tag. Thanks for the review. :)
>>
>> How likely are any of these crashers to affect an end user? 
> IMHO, they are not easily triggered.

A crash at the command line is annoying, but not too bad (because you 
didn't start the guest after all).  A crash after the guest has been 
running for some time, though, is worth considering (data loss should be 
avoided).  I won't make the final determination on this series, but hope 
that my questions are helpful to the maintainers for this code in 
ranking the severity of these crashes.

>> Are any of them regressions over 3.0?
> I do not think so.
>> I'm trying to gauge if any of this is serious enough to warrant a 
>> -rc4, or if we are okay just documenting them as known corner-case 
>> bugs and deferring the fix to 4.0 and qemu-stable.
> Emm, actually not so emergency to be included in -rc4.
> And I think it is ok to wait for maintainers to do the pick for the 
> appropriate release.
> BTW, why 4.0, but not 3.2 or 3.3 (I mean 3.minor version)?

See https://www.qemu.org/download/ for the explanation on version numbering

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org