[lkml]   [2010]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2/3] scheduler: add full memory barriers upon task switch at runqueue lock/unlock

    On Mon, 1 Feb 2010, Mathieu Desnoyers wrote:
    > Here is the detailed execution scenario showing the race.

    No. You've added random smp_mb() calls, but you don't actually show what
    the f*ck they are protecting against.

    For example

    > First sys_membarrier smp_mb():

    I'm not AT ALL interested in the sys_membarrier() parts. You can hav ea
    million memory barriers there, and I won't care. I'm interested in what
    you think the memory barriers elsewhere protect against. It's a barrier
    between _which_ two operations?

    You can't say it's a barrier "around" the

    cpumask_clear(mm_cpumask, cpu);

    because a barrier is between two things. So if you want to add two
    barriers around that mm_cpumask acces, you need to describe the _three_
    events you're barriers between in that call-path (with mm_cpumask being
    just one of them)

    And then, once you've described _those_ three events, you describe what
    the sys_membarrier interaction is, and how mm_cpumask is involved there.

    I'm not interested in the user-space code. Don't even quote it. It's
    irrelevant apart from the actual semantics you want to guarantee for the
    new membarrier() system call. So don't quote the code, just explain what
    the actual barriers are.


     \ /
      Last update: 2010-02-01 19:41    [W:0.030 / U:15.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site