lkml.org 
[lkml]   [2009]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Q: smp.c && barriers (Was: [PATCH 1/4] generic-smp: remove single ipi fallback for smp_call_function_many())
    From
    Date
    On Mon, 2009-02-16 at 21:49 +0100, Oleg Nesterov wrote:
    > I am trying to understand the barriers in smp.c, please help!
    >
    > "generic-ipi: fix the smp_mb() placement" commit
    > 561920a0d2bb6d63343e83acfd784c0a77bd28d1 added smp_read_barrier_depends()
    > to generic_smp_call_function_single_interrupt().
    >
    > Why it is needed? The comment says:
    >
    > /*
    > * Need to see other stores to list head for checking whether
    > * list is empty without holding q->lock
    > */
    > smp_read_barrier_depends();
    > while (!list_empty(&q->list)) {
    >
    > But we can't miss the addition to the call_single_queue.list,
    > if generic_exec_single() sees list_empty(&dst->list) it sends
    > another IPI?

    I was about to write a response, but found it to be a justification for
    the read_barrier_depends() at the end of the loop.

    > This commit also removed the barrier from csd_flag_wait(), is this OK?
    > Without the barrier, csd_flag_wait() can return before we see the result
    > of data->func() ?
    >
    > IOW,
    > int VAR = 0;
    >
    > void func(coid *unused)
    > {
    > VAR = 1;
    > }
    >
    > Now,
    >
    > smp_call_function_single(0, func, NULL, 1);
    > BUG_ON(VAR == 0);
    >
    > afaics, the BUG_ON() above is possible. Is this OK ?

    Would it not be the caller's responsibility to provide the needed
    serialization in this case?



    \
     
     \ /
      Last update: 2009-02-18 12:23    [W:0.032 / U:29.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site