Message ID | 20181129100340.13823-1-fli@suse.com |
---|---|
Headers | show |
Series | fix some segmentation faults and migration issues | expand |
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
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