lkml.org 
[lkml]   [2010]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG: using smp_processor_id() in preemptible [00000000] code: icedove-bin/5449
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.



\
 
 \ /
  Last update: 2010-05-27 01:05    [W:1.523 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site