On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > On 2012-08-19 11:42, Avi Kivity wrote: >> On 08/17/2012 06:04 PM, Jan Kiszka wrote: >>> >>>>> Can anyone imagine that such a barrier may actually be required? If it >>>>> is currently possible that env->stop is evaluated before we called into >>>>> sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the >>>>> signal without properly processing its reason (stop). >>> >>> Should not be required (TM): Both signal eating / stop checking and stop >>> setting / signal generation happens under the BQL, thus the ordering >>> must not make a difference here. >> >> Agree. >> >> >>> Don't see where we could lose a signal. Maybe due to a subtle memory >>> corruption that sets thread_kicked to non-zero, preventing the kicking >>> this way. >> >> Cannot be ruled out, yet too much of a coincidence. >> >> Could be a kernel bug (either in kvm or elsewhere), we've had several >> before in this area. >> >> Is this reproducible? > > Not for me. Peter only hit it very rarely, Peter obviously more easily. I have only hit this once and was not able to reproduce it. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
