Thomas just spend a lovely morning trying to make sense of a trace where TIF_NEED_RESCHED wasn't set after resched_task() and magically appeared after local_bh_enable(). What happened is that on that particular platform softirqs ran on a separate stack, and current_thread_info() is relative to the stack pointer. The result is that current_thread_info() isn't the same as task_thread_info(current), *surprise*!! The immediate problem is of course that we can loose TIF flags when set through current_thread_info() from IRQ/SoftIRQ context. Now I was going to add a WARN() in x86_64's current_thread_info() to catch all these, sadly x86_64's implementation isn't prone to this particular issue, which means most people (kernel devs) will not be affected (i386 is affected, but nobody sane uses that anymore). Just to give an example, RCU uses set_need_resched(), set_need_resched() uses current_thread_info(). The use in force_quiescent_state() is from softirq afaict, the one in __rcu_pending() is from hardirq. On such platforms as Thomas was playing on, the TIF bit will be lost, since it will be set on the thread_info associated with some interrupt stack, not the current process. So how are we going to solve this? Naively I'd think that current_thread_info() is short for task_thread_info(current), and thus the platforms for where this isn't true are broken. I mean, what use is the thread_info not of a thread? Comments? -- 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
