On Thu, 8 Jan 2009, Steven Rostedt wrote: > > Ouch! I think you are on to something: Yeah, there's somethign there, but looking at Chris' backtrace, there's nothing there to disable preemption. So if it was this simple case, it should still have preempted him to let the other process run and finish up. So I don't think Chris' softlockup is at least _exactly_ that case. There's something else going on too. That said, I do think it's a mistake for us to care about the value of "spin_on_owner()". I suspect v8 should - always have if (need_resched()) break in the outer loop. - drop the return value from "spin_on_owner()", and just break out if anything changes (including the need_resched() flag). - I'd also drop the "old_value < 0 &&" test, and just test the list_empty() unconditionally. Aim for really simple. As to what to do about the "!owner" case - we do want to spin on it, but the interaction with preemption is kind of nasty. I'd hesitate to make the mutex_[un]lock() use preempt_disable() to avoid scheduling in between getting the lock and settign the owner, though - because that would slow down the normal fast-path case. Maybe we should just limit the "spin on !owner" to some maximal count. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
