Re: BUG: using smp_processor_id() in preemptible [00000000] code: icedove-bin/5449

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 27 May 2010 08:46:38 +0200 Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, 2010-05-26 at 16:02 -0700, Andrew Morton wrote:
> 
> > How is anyone supposed to use this?  What are the semantics of this
> > thing?  What are the units of its return value?  What is the base value
> > of its return value?  Does it return different times on different CPUs?
> > I assume so, otherwise why does sched_clock_cpu() exist?  <looks at
> > the sched_clock_cpu() documentation, collapses in giggles>
> 
> The point of the whole sched_clock_cpu() thing is to provide a fairly
> high resolution clock with bounded drift between cpus.
> 
> It also promises to be monotonic per cpu argument, that is,
> sched_clock_cpu(j) will, for a constant j always return a monotonic
> increasing timestamp.
> 
> It doesn't make much promises about its base (although people tend to
> want it to start at 0 on boot, but the users really shouldn't care).
> 
> sched_clock() doesn't promise either bounded drift between cpus nor
> monotonicity.
> 

OK, well please document these subtleties things in a very obvious place.

Right now the code is a landmine.  Some poor innocent drivers/foo/
developer can use them and add fantastically subtle
once-per-million-machine-year lockup-causing bugs which he'll never be
able to diagnose.