lkml.org 
[lkml]   [2011]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Subjectcurrent_thread_info() vs task_thread_info(current)
    From
    Date
    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?


    \
     
     \ /
      Last update: 2011-07-18 13:25    [W:0.031 / U:119.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site