Re: [tip:core/locking] locking, x86: Slightly shorten__ticket_spin_trylock()

[Ingo Molnar]

* tip-bot for Jan Beulich <JBeulich@xxxxxxxxxx> wrote:

> Commit-ID:  133ec7a235160dd44cbd4d82fff65a9983331df9
> Gitweb:     http://git.kernel.org/tip/133ec7a235160dd44cbd4d82fff65a9983331df9
> Author:     Jan Beulich <JBeulich@xxxxxxxxxx>
> AuthorDate: Fri, 27 Nov 2009 15:09:16 +0000
> Committer:  Ingo Molnar <mingo@xxxxxxx>
> CommitDate: Wed, 2 Dec 2009 11:11:11 +0100
> 
> locking, x86: Slightly shorten __ticket_spin_trylock()

-tip testing found that this causes a boot regression (locking during 
boot):

commit 133ec7a235160dd44cbd4d82fff65a9983331df9
Author: Jan Beulich <JBeulich@xxxxxxxxxx>
Date:   Fri Nov 27 15:09:16 2009 +0000

    locking, x86: Slightly shorten __ticket_spin_trylock()
    
    Since the callers generally expect a boolean value, there's no
    need to zero-extend the outcome of the comparison. It just
    requires that all of x86' trylock implementations return bo

After a couple of silent hangs in random places during bootup i got one 
bootup that has a more telling output:

CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Brought up 2 CPUs
Total of 2 processors activated (8041.67 BogoMIPS).
BUG: spinlock wrong owner on CPU#0, swapper/1
 lock: 7b20b340, .magic: dead4ead, .owner: swapper/0, .owner_cpu: -1
Pid: 1, comm: swapper Not tainted 2.6.32-rc8-tip-02745-g401930b-dirty 
#9729
Call Trace:
 [<792a9959>] ? _raw_spin_unlock+0x46/0x76
 [<79a8729c>] ? _spin_unlock_irqrestore+0x8/0x12
 [<790268ae>] ? wait_task_inactive+0x73/0xa3
 [<7902a0b5>] ? kthread_bind+0x1e/0x8a
 [<79037b46>] ? start_workqueue_thread+0x13/0x1d
 [<79037f99>] ? __create_workqueue_key+0x10b/0x165
 [<7a02e26e>] ? init_workqueues+0x78/0x83
 [<7a01d2f4>] ? kernel_init+0x12b/0x1ae
 [<7a01d1c9>] ? kernel_init+0x0/0x1ae
 [<79002dbf>] ? kernel_thread_helper+0x7/0x10
device: 'platform': device_add
khelper used greatest stack depth: 3336 bytes left

at first quick sight, this bit looks odd:

+       union { int i; bool b; } new;

+       return new.b;

shouldnt that be short based, to work correctly in the 0-255 CPUs case?

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