[lkml]   [2012]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 5/8] x86: use this_cpu_xxx to replace percpu_xxx funcs
    On Tue, 6 Mar 2012, Ingo Molnar wrote:

    > > All percpu_xxx() functions get removed.
    > Fair enough - then please see my namespace comments for the
    > other patch, before we start spreading these APIs to hundreds of
    > places ...

    Its already almost everywhere... This removes some of the last holdouts.

    > Also, IMHO the lack of debugging API is troubling as well.

    For that there would need to be some basic understanding as to what is
    going on here. These are fundamentally atomic style operations and I keep
    hearing that people want to check if they are in a preempt section etc.
    I do not see how that is possible for the this_cpu_ops.

    However, checks could be done this for the __this_cpu_ops (which rely on
    the processor not changing during their execution for their fallback
    implementation, therefore preempt should be off) by simply adding a check
    to the basic macros (add to __this_cpu_ptr for example). The problem is
    then that there needs to be an audit first to see if there are cases where
    we run into trouble with such an approach. There are situations in which
    the use of __this_cpu ops is legitimate for other reasons if no concurrent
    per cpu access can occur or we cannot be moved to a different processor
    (because the process pinned to a processor f.e.)

    > Thomas found a couple of really, really hairy this_cpu related
    > bugs.

    Well yeah if one uses per cpu operations and then allows execution to
    occur on a different processor then one will not operate on the same
    entity. The same issue would have occurred if they had used the old
    percpu operations.

     \ /
      Last update: 2012-03-06 18:03    [W:0.024 / U:29.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site