Linux 3.0.75

commit b47833937231eebab2fe46502426ea8158fae8d9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 25 21:24:11 2013 -0700

    Linux 3.0.75

commit 7a860c4dfb8ebaf777a7df185df4436ea343189a
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Fri Apr 5 20:50:09 2013 +0000

    Btrfs: make sure nbytes are right after log replay

    commit 4bc4bee4595662d8bff92180d5c32e3313a704b0 upstream.

    While trying to track down a tree log replay bug I noticed that fsck was always
    complaining about nbytes not being right for our fsynced file.  That is because
    the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
    nbytes are not necessarily updated properly when we log it.  So to fix this we
    need to set nbytes to whatever it is on the inode that is on disk, so when we
    replay the extents we can just add the bytes that are being added as we replay
    the extent.  This makes it work for the case that we have the wrong nbytes or
    the case that we logged everything and nbytes is actually correct.  With this
    I'm no longer getting nbytes errors out of btrfsck.

    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 856398d852436111d5cdbf30374f576671903998
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:53:07 2013 -0700

    vm: convert mtdchar mmap to vm_iomap_memory() helper

    commit 8558e4a26b00225efeb085725bc319f91201b239 upstream.

    This is my example conversion of a few existing mmap users.  The mtdchar
    case is actually disabled right now (and stays disabled), but I did it
    because it showed up on my "git grep", and I was familiar with the code
    due to fixing an overflow problem in the code in commit 9c603e53d380
    ("mtdchar: fix offset overflow detection").

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 102fe50d961cf56eb764959783485193884ab1e6
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:46:39 2013 -0700

    vm: convert HPET mmap to vm_iomap_memory() helper

    commit 2323036dfec8ce3ce6e1c86a49a31b039f3300d1 upstream.

    This is my example conversion of a few existing mmap users.  The HPET
    case is simple, widely available, and easy to test (Clemens Ladisch sent
    a trivial test-program for it).

    Test-program-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03a850de03bfed25270d20918ee02d9f0dbb1f21
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:57:35 2013 -0700

    vm: convert fb_mmap to vm_iomap_memory() helper

    commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream.

    This is my example conversion of a few existing mmap users.  The
    fb_mmap() case is a good example because it is a bit more complicated
    than some: fb_mmap() mmaps one of two different memory areas depending
    on the page offset of the mmap (but happily there is never any mixing of
    the two, so the helper function still works).

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69c8dbb74ce747df83ad81ba73db965d7a716726
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 10:01:04 2013 -0700

    vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper

    commit 0fe09a45c4848b5b5607b968d959fdc1821c161d upstream.

    This is my example conversion of a few existing mmap users.  The pcm
    mmap case is one of the more straightforward ones.

    Acked-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1a01d18320e37367e23f006f0dfbd74ff32de68
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Apr 16 13:45:37 2013 -0700

    vm: add vm_iomap_memory() helper function

    commit b4cbb197c7e7a68dbad0d491242e3ca67420c13e upstream.

    Various drivers end up replicating the code to mmap() their memory
    buffers into user space, and our core memory remapping function may be
    very flexible but it is unnecessarily complicated for the common cases
    to use.

    Our internal VM uses pfn's ("page frame numbers") which simplifies
    things for the VM, and allows us to pass physical addresses around in a
    denser and more efficient format than passing a "phys_addr_t" around,
    and having to shift it up and down by the page size.  But it just means
    that drivers end up doing that shifting instead at the interface level.

    It also means that drivers end up mucking around with internal VM things
    like the vma details (vm_pgoff, vm_start/end) way more than they really
    need to.

    So this just exports a function to map a certain physical memory range
    into user space (using a phys_addr_t based interface that is much more
    natural for a driver) and hides all the complexity from the driver.
    Some drivers will still end up tweaking the vm_page_prot details for
    things like prefetching or cacheability etc, but that's actually
    relevant to the driver, rather than caring about what the page offset of
    the mapping is into the particular IO memory region.

    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 22fd0f0bb5e791b7cd5b5e0c7d4c2172c722844d
Author: Dave Airlie <airlied@gmail.com>
Date:   Fri Jan 25 11:38:56 2013 +1000

    fbcon: fix locking harder

    commit 054430e773c9a1e26f38e30156eff02dedfffc17 upstream.

    Okay so Alan's patch handled the case where there was no registered fbcon,
    however the other path entered in set_con2fb_map pit.

    In there we called fbcon_takeover, but we also took the console lock in a couple
    of places. So push the console lock out to the callers of set_con2fb_map,

    this means fbmem and switcheroo needed to take the lock around the fb notifier
    entry points that lead to this.

    This should fix the efifb regression seen by Maarten.

    Tested-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
    Tested-by: Lu Hua <huax.lu@intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 456edf57d7a6fe1b238ec708b19063d78cf4b250
Author: Tommi Rantala <tt.rantala@gmail.com>
Date:   Sat Apr 13 22:49:14 2013 +0300

    perf: Treat attr.config as u64 in perf_swevent_init()

    commit 8176cced706b5e5d15887584150764894e94e02f upstream.

    Trinity discovered that we fail to check all 64 bits of
    attr.config passed by user space, resulting to out-of-bounds
    access of the perf_swevent_enabled array in
    sw_perf_event_destroy().

    Introduced in commit b0a873ebb ("perf: Register PMU
    implementations").

    Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: davej@redhat.com
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb5489176fda28aff304b59e0405f7d7d4906224
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Mon Apr 22 15:40:15 2013 +0200

    Revert "sysfs: fix race between readdir and lseek"

    This reverts commit 991f76f837bf22c5bb07261cfd86525a0a96650c in Linus'
    tree which is f366c8f271888f48e15cc7c0ab70f184c220c8a4 in
    linux-stable.git

    It depends on ef3d0fd27e90f ("vfs: do (nearly) lockless generic_file_llseek")
    which is available only in 3.2+.

    When applied on 3.0 codebase, it causes A-A deadlock, whenever anyone does
    seek() on sysfs, as both generic_file_llseek() and sysfs_dir_llseek() obtain
    i_mutex.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0236d37edc0522f37b83eba35432815cd98789ff
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 14:05:39 2013 +0200

    crypto: algif - suppress sending source address information in recvmsg

    commit 72a763d805a48ac8c0bf48fdb510e84c12de51fe upstream.

    The current code does not set the msg_namelen member to 0 and therefore
    makes net/socket.c leak the local sockaddr_storage variable to userland
    -- 128 bytes of kernel stack memory. Fix that.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55aa9556812fe10d71bfe82ff61058a3a03cb0f6
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Mar 18 12:22:34 2013 -0700

    sched: Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s

    commit 383efcd00053ec40023010ce5034bd702e7ab373 upstream.

    try_to_wake_up_local() should only be invoked to wake up another
    task in the same runqueue and BUG_ON()s are used to enforce the
    rule. Missing try_to_wake_up_local() can stall workqueue
    execution but such stalls are likely to be finite either by
    another work item being queued or the one blocked getting
    unblocked.  There's no reason to trigger BUG while holding rq
    lock crashing the whole system.

    Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20130318192234.GD3042@htj.dyndns.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a9cb8d371991dceed054aec71541653e330180f
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Apr 7 21:10:48 2013 +0200

    ath9k_htc: accept 1.x firmware newer than 1.3

    commit 319e7bd96aca64a478f3aad40711c928405b8b77 upstream.

    Since the firmware has been open sourced, the minor version has been
    bumped to 1.4 and the API/ABI will stay compatible across further 1.x
    releases.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cef72624c31364e7020450571393a4d5a0e44b34
Author: Illia Ragozin <illia.ragozin@grapecom.com>
Date:   Wed Apr 10 19:43:34 2013 +0100

    ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon

    commit cd272d1ea71583170e95dde02c76166c7f9017e6 upstream.

    On Feroceon the L2 cache becomes non-coherent with the CPU
    when the L1 caches are disabled. Thus the L2 needs to be invalidated
    after both L1 caches are disabled.

    On kexec before the starting the code for relocation the kernel,
    the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
    but after L2 cache is never invalidated, because inv_all is not set
    in cache-feroceon-l2.c.
    So kernel relocation and decompression may has (and usually has) errors.
    Setting the function enables L2 invalidation and fixes the issue.

    Signed-off-by: Illia Ragozin <illia.ragozin@grapecom.com>
    Acked-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d715cdddb8cdf1c17bf1c5ff8fcc9852cd6ba79e
Author: Andrew Honig <ahonig@google.com>
Date:   Fri Mar 29 09:35:21 2013 -0700

    KVM: Allow cross page reads and writes from cached translations.

    commit 8f964525a121f2ff2df948dac908dcc65be21b5b upstream.

    This patch adds support for kvm_gfn_to_hva_cache_init functions for
    reads and writes that will cross a page.  If the range falls within
    the same memslot, then this will be a fast operation.  If the range
    is split between two memslots, then the slower kvm_read_guest and
    kvm_write_guest are used.

    Tested: Test against kvm_clock unit tests.

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17f13c27702d90899081bf70134132ed5f25158e
Author: Andy Honig <ahonig@google.com>
Date:   Wed Feb 20 14:49:16 2013 -0800

    KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)

    commit a2c118bfab8bc6b8bb213abfc35201e441693d55 upstream.

    If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows
    that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate
    that request.  ioapic_read_indirect contains an
    ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in
    non-debug builds.  In recent kernels this allows a guest to cause a kernel
    oops by reading invalid memory.  In older kernels (pre-3.3) this allows a
    guest to read from large ranges of host memory.

    Tested: tested against apic unit tests.

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df0ed3450c217a1cd571c0d4efa4dc6c458894a9
Author: Andy Honig <ahonig@google.com>
Date:   Wed Feb 20 14:48:10 2013 -0800

    KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use gfn_to_hva_cache functions (CVE-2013-1797)

    commit 0b79459b482e85cb7426aa7da683a9f2c97aeae1 upstream.

    There is a potential use after free issue with the handling of
    MSR_KVM_SYSTEM_TIME.  If the guest specifies a GPA in a movable or removable
    memory such as frame buffers then KVM might continue to write to that
    address even after it's removed via KVM_SET_USER_MEMORY_REGION.  KVM pins
    the page in memory so it's unlikely to cause an issue, but if the user
    space component re-purposes the memory previously used for the guest, then
    the guest will be able to corrupt that memory.

    Tested: Tested against kvmclock unit test

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7709255affba50d2ff4087d28308e03d1154afa
Author: Andy Honig <ahonig@google.com>
Date:   Mon Mar 11 09:34:52 2013 -0700

    KVM: x86: fix for buffer overflow in handling of MSR_KVM_SYSTEM_TIME (CVE-2013-1796)

    commit c300aa64ddf57d9c5d9c898a64b36877345dd4a9 upstream.

    If the guest sets the GPA of the time_page so that the request to update the
    time straddles a page then KVM will write onto an incorrect page.  The
    write is done byusing kmap atomic to get a pointer to the page for the time
    structure and then performing a memcpy to that page starting at an offset
    that the guest controls.  Well behaved guests always provide a 32-byte aligned
    address, however a malicious guest could use this to corrupt host kernel
    memory.

    Tested: Tested against kvmclock unit test.

    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c72cbc040d7160849369d59166f7be32d1991fd
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Wed Apr 17 15:58:33 2013 -0700

    hfsplus: fix potential overflow in hfsplus_file_truncate()

    commit 12f267a20aecf8b84a2a9069b9011f1661c779b4 upstream.

    Change a u32 to loff_t hfsplus_file_truncate().

    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aab5c5ca241d159f81e002aebb828c3c75bf4682
Author: Emese Revfy <re.emese@gmail.com>
Date:   Wed Apr 17 15:58:36 2013 -0700

    kernel/signal.c: stop info leak via the tkill and the tgkill syscalls

    commit b9e146d8eb3b9ecae5086d373b50fa0c1f3e7f0f upstream.

    This fixes a kernel memory contents leak via the tkill and tgkill syscalls
    for compat processes.

    This is visible in the siginfo_t->_sifields._rt.si_sigval.sival_ptr field
    when handling signals delivered from tkill.

    The place of the infoleak:

    int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from)
    {
            ...
            put_user_ex(ptr_to_compat(from->si_ptr), &to->si_ptr);
            ...
    }

    Signed-off-by: Emese Revfy <re.emese@gmail.com>
    Reviewed-by: PaX Team <pageexec@freemail.hu>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Serge Hallyn <serge.hallyn@canonical.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cf9b8f1a9ae1640f73cf8804484530e74eb9d5d
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Apr 17 15:58:30 2013 -0700

    hugetlbfs: add swap entry check in follow_hugetlb_page()

    commit 9cc3a5bd40067b9a0fbd49199d0780463fc2140f upstream.

    With applying the previous patch "hugetlbfs: stop setting VM_DONTDUMP in
    initializing vma(VM_HUGETLB)" to reenable hugepage coredump, if a memory
    error happens on a hugepage and the affected processes try to access the
    error hugepage, we hit VM_BUG_ON(atomic_read(&page->_count) <= 0) in
    get_page().

    The reason for this bug is that coredump-related code doesn't recognise
    "hugepage hwpoison entry" with which a pmd entry is replaced when a memory
    error occurs on a hugepage.

    In other words, physical address information is stored in different bit
    layout between hugepage hwpoison entry and pmd entry, so
    follow_hugetlb_page() which is called in get_dump_page() returns a wrong
    page from a given address.

    The expected behavior is like this:

      absent   is_swap_pte   FOLL_DUMP   Expected behavior
      -------------------------------------------------------------------
       true     false         false       hugetlb_fault
       false    true          false       hugetlb_fault
       false    false         false       return page
       true     false         true        skip page (to avoid allocation)
       false    true          true        hugetlb_fault
       false    false         true        return page

    With this patch, we can call hugetlb_fault() and take proper actions (we
    wait for migration entries, fail with VM_FAULT_HWPOISON_LARGE for
    hwpoisoned entries,) and as the result we can dump all hugepages except
    for hwpoisoned ones.

    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Rik van Riel <riel@redhat.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55fe10a686c3a8bce7bddc149e4ebb12f5a18c25
Author: Christoph Fritz <chf.fritz@googlemail.com>
Date:   Thu Apr 11 21:32:57 2013 +0200

    can: sja1000: fix handling on dt properties on little endian systems

    commit 0443de5fbf224abf41f688d8487b0c307dc5a4b4 upstream.

    To get correct endianes on little endian cpus (like arm) while reading device
    tree properties, this patch replaces of_get_property() with
    of_property_read_u32(). While there use of_property_read_bool() for the
    handling of the boolean "nxp,no-comparator-bypass" property.

    Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80d98a915c07e6de6c3a2c08dea843f441273081
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 17 09:50:59 2013 -0700

    Revert "8021q: fix a potential use-after-free"

    This reverts commit 9829fe9806e22d7a822f4c947cc432c8d1774b54 which is
    upstream commit 4a7df340ed1bac190c124c1601bfc10cde9fb4fb

    It turns out this causes problems on the 3.0-stable release.

    Reported-by: Thomas Voegtle <tv@lio96.de>
    Acked-by: Cong Wang <amwang@redhat.com>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27819a8a40b34b2db511181cfbfdf7f76281651d
Author: Michael Bohan <mbohan@codeaurora.org>
Date:   Tue Mar 19 19:19:25 2013 -0700

    hrtimer: Don't reinitialize a cpu_base lock on CPU_UP

    commit 84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0 upstream.

    The current code makes the assumption that a cpu_base lock won't be
    held if the CPU corresponding to that cpu_base is offline, which isn't
    always true.

    If a hrtimer is not queued, then it will not be migrated by
    migrate_hrtimers() when a CPU is offlined. Therefore, the hrtimer's
    cpu_base may still point to a CPU which has subsequently gone offline
    if the timer wasn't enqueued at the time the CPU went down.

    Normally this wouldn't be a problem, but a cpu_base's lock is blindly
    reinitialized each time a CPU is brought up. If a CPU is brought
    online during the period that another thread is performing a hrtimer
    operation on a stale hrtimer, then the lock will be reinitialized
    under its feet, and a SPIN_BUG() like the following will be observed:

    <0>[   28.082085] BUG: spinlock already unlocked on CPU#0, swapper/0/0
    <0>[   28.087078]  lock: 0xc4780b40, value 0x0 .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
    <4>[   42.451150] [<c0014398>] (unwind_backtrace+0x0/0x120) from [<c0269220>] (do_raw_spin_unlock+0x44/0xdc)
    <4>[   42.460430] [<c0269220>] (do_raw_spin_unlock+0x44/0xdc) from [<c071b5bc>] (_raw_spin_unlock+0x8/0x30)
    <4>[   42.469632] [<c071b5bc>] (_raw_spin_unlock+0x8/0x30) from [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8)
    <4>[   42.479521] [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8) from [<c00aa014>] (hrtimer_start+0x20/0x28)
    <4>[   42.489247] [<c00aa014>] (hrtimer_start+0x20/0x28) from [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320)
    <4>[   42.498709] [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320) from [<c00e6440>] (rcu_idle_enter+0xa0/0xb8)
    <4>[   42.508259] [<c00e6440>] (rcu_idle_enter+0xa0/0xb8) from [<c000f268>] (cpu_idle+0x24/0xf0)
    <4>[   42.516503] [<c000f268>] (cpu_idle+0x24/0xf0) from [<c06ed3c0>] (rest_init+0x88/0xa0)
    <4>[   42.524319] [<c06ed3c0>] (rest_init+0x88/0xa0) from [<c0c00978>] (start_kernel+0x3d0/0x434)

    As an example, this particular crash occurred when hrtimer_start() was
    executed on CPU #0. The code locked the hrtimer's current cpu_base
    corresponding to CPU #1. CPU #0 then tried to switch the hrtimer's
    cpu_base to an optimal CPU which was online. In this case, it selected
    the cpu_base corresponding to CPU #3.

    Before it could proceed, CPU #1 came online and reinitialized the
    spinlock corresponding to its cpu_base. Thus now CPU #0 held a lock
    which was reinitialized. When CPU #0 finally ended up unlocking the
    old cpu_base corresponding to CPU #1 so that it could switch to CPU
    #3, we hit this SPIN_BUG() above while in switch_hrtimer_base().

    CPU #0                            CPU #1
    ----                              ----
    ...                               <offline>
    hrtimer_start()
    lock_hrtimer_base(base #1)
    ...                               init_hrtimers_cpu()
    switch_hrtimer_base()             ...
    ...                               raw_spin_lock_init(&cpu_base->lock)
    raw_spin_unlock(&cpu_base->lock)  ...
    <spin_bug>

    Solve this by statically initializing the lock.

    Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
    Link: http://lkml.kernel.org/r/1363745965-23475-1-git-send-email-mbohan@codeaurora.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>