On 12/11, Paul Turner wrote: > > Peter's proposed follow-up above looks strictly more correct. We need > to evaluate the potential existence of a signal, *after* we return > from schedule, I still don't understand this... signal_pending_check(current->state) before schedule() should be fine even if it actually reads current->state twice and it races with wakeup/ signal_wake_up() which can change the caller's state. > but in the context of the state which we previously > _entered_ schedule() on. Yes, but only if we do this after return from schedule(). But somehow this change helps. It adds the subtle difference(s), for example __wait_on_bit_lock() won't do another test_and_set_bit() if the sleeping caller is killed, but this shouldn't matter. And if this does matter because it has a buggy user, then it is not clear why the change from Vladimir helps too. The common part is that both changes make "return 1" impossible, but according to another email from Peter this just makes the fail less likely. I am really puzzled. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|