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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 May 2010 16:02:52 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	piotr@...owicz.com, linux-kernel@...r.kernel.org,
	Jens Axboe <jens.axboe@...cle.com>,
	Divyesh Shah <dpshah@...gle.com>
Subject: Re: BUG: using smp_processor_id() in preemptible [00000000] code:
 icedove-bin/5449

On Tue, 25 May 2010 10:50:22 +0200
Peter Zijlstra <peterz@...radead.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.

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