On Thu, 2011-01-06 at 21:38 +1100, Nick Piggin wrote: > I can't see how the usage in libata could be right. If we're waiting > for some modifications inside the critical section, then it seems we > could load some shared data before the lock is actually released, on > an architecture which does load/load reordering. At best it needs some > good comments and perhaps a barrier or two. > > The spin_unlock_wait in do_exit seems like it shouldn't be needed -- > exit_pi_state_list takes the pi_lock after the task has died anyway, > so I can't see what the problem would be. Removing the call (and > perhaps put a BUG_ON(!(curr->flags & PF_EXITING)) in exit_pi_state_list > would do the same thing, avoid the barrier, and localize fuxtex exit > protocol to futex.c. Jeff, Tejun, could you look at the ata-eh thing, then I'll put sorting through the futex thing on my todo list. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
