Re: [PATCH]kprobes fix bug when probed on task and isr functions

[Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>]

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.
http://sourceware.org/bugzilla/show_bug.cgi?id=1229

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/