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?