lkml.org 
[lkml]   [2011]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu_read/write()
    I just found out that the this_cpu_*() functions do not perform the
    test to see if the usage is in atomic or not. Thus, the blind
    conversion of the per_cpu(*, smp_processor_id()) and the get_cpu_var()
    code to this_cpu_*() introduce the regression to detect the hard
    to find case where a per cpu variable is used in preempt code that
    migrates and causes bugs.

    I'm adding back a simple call to smp_processor_id() to
    this_cpu_read() and this_cpu_write() to see what errors I find.
    I found 4 places that required touch up. 3 were areas that the race
    is known and we don't care, but the memcg looks very buggy.

    Anyway, if I had known that the this_cpu_*() code removed this
    smp_processor_id() check, I would have NAK'd all the changes to the tracing
    code.

    I only modified this_cpu_read and *_write() I may decide other this_cpu_*
    code should be updated too. Especially the ones that return a value.

    -- Steve

    Steven Rostedt (5):
    x86: Remove const_udelay() caring about which cpu var it uses
    mm: Switch mod_state() to __this_cpu_read()
    memcg: Disable preemption in memcg_check_events()
    printk: Have wake_up_klogd() use __this_cpu_write()
    percpu: Add preempt checks back into this_cpu_read/write()

    ----
    arch/x86/lib/delay.c | 2 +-
    include/linux/percpu.h | 17 +++++++++++++++--
    kernel/printk.c | 2 +-
    mm/memcontrol.c | 2 ++
    mm/vmstat.c | 4 ++--
    5 files changed, 21 insertions(+), 6 deletions(-)


    \
     
     \ /
      Last update: 2011-09-19 23:29    [W:4.185 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site