Hello! > We actually need to do something about this, as we might loop for ever > there. The robust cleanup code can fail (e.g. due to list corruption) > and we would see exit_state != 0 and the OWNER_DIED bit would never be > set, so we are stuck in a busy loop.
Yes... It is possible to take read_lock(&tasklist_lock) before: inc_preempt_count(); curval = futex_atomic_cmpxchg_inatomic(uaddr, uval, newval); dec_preempt_count(); and drop it after lookup_pi_state(). In this case exiting task will set FUTEX_OWNER_DIED, but will spin in exit_notify(), we will find valid pi_state and go slow path taking rtmutex. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/