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