On Mon, Jul 18, 2011 at 01:23:03PM +0200, Peter Zijlstra wrote: > 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? Why not use per cpu kernel_stack variable on all arches as x86_64 does? How big the advantage of using stack pointer to find current thread info is? -- Gleb. -- 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
