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

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

On Tue, 25 May 2010 10:50:22 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, 2010-05-24 at 05:03 +0200, Piotr Hosowicz wrote:
> > [  720.313607] BUG: using smp_processor_id() in preemptible [00000000] code: icedove-bin/5449
> > [  720.313612] caller is native_sched_clock+0x3c/0x68
> > [  720.313616] Pid: 5449, comm: icedove-bin Tainted: P            2.6.34-20100524-0407 #1
> > [  720.313618] Call Trace:
> > [  720.313624]  [<ffffffff811a533b>] debug_smp_processor_id+0xc7/0xe0
> > [  720.313629]  [<ffffffff81009b87>] native_sched_clock+0x3c/0x68
> > [  720.313634]  [<ffffffff81009a4d>] sched_clock+0x9/0xd
> > [  720.313637]  [<ffffffff811823ec>] blk_rq_init+0x92/0x9d
> > [  720.313641]  [<ffffffff81184227>] get_request+0x1bf/0x2c7
> > [  720.313646]  [<ffffffff8118435c>] get_request_wait+0x2d/0x19d 
> 
> This comes from wreckage in the blk tree..
> 
>
>
>
> +unsigned long long local_clock(void)
> +{
> +	unsigned long long clock;
> +	unsigned long flags;
> +
> +	local_irq_save(flags);
> +	clock = sched_clock_cpu(smp_processor_id());
> +	local_irq_restore(flags);
> +
> +	return clock;
> +}
> +

NAK NAK NAK NAK!  QAK!  HAK!  Crap code!  Stop adding undocumented
interfaces.  Just stop it.  Now.  Geeze.

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>

Because if it does return different times on different CPUs then any
and all of the sites which use it are going to need to cope with
time-going-backwards and I'm not at all confident that they get this
right.


Also, all these interfaces use a random mixture of `u64' and `unsigned
long long', but that's a far less serious problem.