[lkml]   [2005]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH]kprobes fix bug when probed on task and isr functions
    On Thu, Sep 01, 2005 at 02:42:11PM -0700, Andrew Morton wrote:
    > Are you sure that other CPUs can safely read kprobe_cpu without taking the
    > lock? I don't see any memory barriers in there...

    I see your point, in the current code we read kprobe_cpu and compare it with
    ones own smp_processor_id() and if it *does* not match, then this cpu is allowed to
    take the kprobe_lock(). So in this context, if one CPU is trying to read(kprobe_cpu)
    the value while other is updating its own smp_processor_id() value,
    then this cpu can either get NR_CPU(stale data) or the correct CPU_ID
    of the other processor, which in any case does not match with its
    own smp_processor_id() and we are allowed to take the lock(where in we might have to
    wait spinning since we are any way serializing handling of probes).

    So to answer your question, for our current desing, we are safe to read
    kprobe_cpu outside of the lock.

    Here is the link which gives the status of testing this patch on
    various platforms.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-02 00:21    [W:0.021 / U:6.204 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site