[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.043 / U:0.692 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site