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? -- error compiling committee.c: too many arguments to function -- 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
