Linux 3.0.44

commit b9a7985a8d9ca00d8ce977756fde1306c9ab1e41
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Oct 2 09:50:36 2012 -0700

    Linux 3.0.44

commit 54d4d42b2558d2053519852dfef7ded62775e058
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jul 13 19:15:40 2012 +0100

    ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+

    commit a76d7bd96d65fa5119adba97e1b58d95f2e78829 upstream.

    The open-coded mutex implementation for ARMv6+ cores suffers from a
    severe lack of barriers, so in the uncontended case we don't actually
    protect any accesses performed during the critical section.

    Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
    code but optimised to remove a branch instruction, as the mutex fastpath
    was previously inlined. Now that this is executed out-of-line, we can
    reuse the atomic access code for the locking (in fact, we use the xchg
    code as this produces shorter critical sections).

    This patch uses the generic xchg based implementation for mutexes on
    ARMv6+, which introduces barriers to the lock/unlock operations and also
    has the benefit of removing a fair amount of inline assembly code.

    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Reported-by: Shan Kang <kangshan0910@gmail.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b15ab4ac6ae748d3552b0cb112dff5c9c567d4ca
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Sep 26 13:09:53 2012 -0400

    USB: Fix race condition when removing host controllers

    commit 0d00dc2611abbe6ad244d50569c2ee82ce42846c upstream.

    This patch (as1607) fixes a race that can occur if a USB host
    controller is removed while a process is reading the
    /sys/kernel/debug/usb/devices file.

    The usb_device_read() routine uses the bus->root_hub pointer to
    determine whether or not the root hub is registered.  The is not a
    valid test, because the pointer is set before the root hub gets
    registered and remains set even after the root hub is unregistered and
    deallocated.  As a result, usb_device_read() or usb_device_dump() can
    access freed memory, causing an oops.

    The patch changes the test to use the hcd->rh_registered flag, which
    does get set and cleared at the appropriate times.  It also makes sure
    to hold the usb_bus_list_lock mutex while setting the flag, so that
    usb_device_read() will become aware of new root hubs as soon as they
    are registered.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ef8fa7479fff9313387b873413f5ae233a2bd04
Author: Andi Kleen <andi@firstfloor.org>
Date:   Fri Nov 19 13:16:22 2010 +0100

    MCE: Fix vm86 handling for 32bit mce handler

    commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream.

    When running on 32bit the mce handler could misinterpret
    vm86 mode as ring 0. This can affect whether it does recovery
    or not; it was possible to panic when recovery was actually
    possible.

    Fix this by always forcing vm86 to look like ring 3.

    [ Backport to 3.0 notes:
    Things changed there slightly:
       - move mce_get_rip() up. It fills up m->cs and m->ip values which
         are evaluated in mce_severity(). Therefore move it up right before
         the mce_severity call. This seem to be another bug in 3.0?
       - Place the backport (fix m->cs in V86 case) to where m->cs gets
         filled which is mce_get_rip() in 3.0
    ]

    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca465bac8c69a79377547f7563c671a530eb977c
Author: Yasunori Goto <y-goto@jp.fujitsu.com>
Date:   Tue Jan 17 17:40:31 2012 +0900

    sched: Fix ancient race in do_exit()

    commit b5740f4b2cb3503b436925eb2242bc3d75cd3dfe upstream.

    try_to_wake_up() has a problem which may change status from TASK_DEAD to
    TASK_RUNNING in race condition with SMI or guest environment of virtual
    machine. As a result, exited task is scheduled() again and panic occurs.

    Here is the sequence how it occurs:

     ----------------------------------+-----------------------------
                                       |
                CPU A                  |             CPU B
     ----------------------------------+-----------------------------

    TASK A calls exit()....

    do_exit()

      exit_mm()
        down_read(mm->mmap_sem);

        rwsem_down_failed_common()

          set TASK_UNINTERRUPTIBLE
          set waiter.task <= task A
          list_add to sem->wait_list
               :
          raw_spin_unlock_irq()
          (I/O interruption occured)

                                          __rwsem_do_wake(mmap_sem)

                                            list_del(&waiter->list);
                                            waiter->task = NULL
                                            wake_up_process(task A)
                                              try_to_wake_up()
                                                 (task is still
                                                   TASK_UNINTERRUPTIBLE)
                                                  p->on_rq is still 1.)

                                                  ttwu_do_wakeup()
                                                     (*A)
                                                       :
         (I/O interruption handler finished)

          if (!waiter.task)
              schedule() is not called
              due to waiter.task is NULL.

          tsk->state = TASK_RUNNING

              :
                                                  check_preempt_curr();
                                                      :
      task->state = TASK_DEAD
                                                  (*B)
                                            <---    set TASK_RUNNING (*C)

         schedule()
         (exit task is running again)
         BUG_ON() is called!
     --------------------------------------------------------

    The execution time between (*A) and (*B) is usually very short,
    because the interruption is disabled, and setting TASK_RUNNING at (*C)
    must be executed before setting TASK_DEAD.

    HOWEVER, if SMI is interrupted between (*A) and (*B),
    (*C) is able to execute AFTER setting TASK_DEAD!
    Then, exited task is scheduled again, and BUG_ON() is called....

    If the system works on guest system of virtual machine, the time
    between (*A) and (*B) may be also long due to scheduling of hypervisor,
    and same phenomenon can occur.

    By this patch, do_exit() waits for releasing task->pi_lock which is used
    in try_to_wake_up(). It guarantees the task becomes TASK_DEAD after
    waking up.

    Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20120117174031.3118.E1E9C6FF@jp.fujitsu.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81e80587f3fc5239bdcdcb69750e24448485d7f6
Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Date:   Fri May 11 15:29:50 2012 -0700

    spi/spi-fsl-spi: reference correct pdata in fsl_spi_cs_control

    commit 067aa4815a9bc12a569d8a06afef50ba5773afbf upstream.

    Commit 178db7d3, "spi: Fix device unregistration when unregistering
    the bus master", changed spi device initialization of dev.parent pointer
    to be the master's device pointer instead of his parent.

    This introduced a bug in spi-fsl-spi, since its usage of spi device
    pointer was not updated accordingly. This was later fixed by commit
    5039a86, "spi/mpc83xx: fix NULL pdata dereference bug", but it missed
    another spot on fsl_spi_cs_control function where we also need to update
    usage of spi device pointer. This change address that.

    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Cc: Alfredo Capella <alfredo.capella@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7388a987be7ae204e00e27f1ef6d3e1b7689637c
Author: Kenth Eriksson <kenth.eriksson@transmode.com>
Date:   Fri Mar 30 17:05:30 2012 +0200

    spi/mpc83xx: fix NULL pdata dereference bug

    commit 5039a86973cd35bdb2f64d28ee12f13fe2bb5a4c upstream.

    Commit 178db7d3, "spi: Fix device unregistration when unregistering
    the bus master", changed device initialization to be children of the
    bus master, not children of the bus masters parent device. The pdata
    pointer used in fsl_spi_chipselect must updated to reflect the changed
    initialization.

    Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
    Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Cc: Alfredo Capella <alfredo.capella@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aaa9ef3b913499bdcc81ac859624a06ffea62374
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Wed Sep 12 09:03:23 2012 +0200

    UBI: fix a horrible memory deallocation bug

    commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream

    UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when
    freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened
    only when we were doing auto-format, so many systems were unaffected. However,
    there are still many users affected.

    It is strange, but the system did not crash and nothing bad happened when
    the SLUB memory allocator was used. However, in case of SLOB we observed an
    crash right away.

    This problem was introduced in 2.6.39 by commit
    "6c1e875 UBI: add slab cache for ubi_scan_leb objects"

    Reported-by: Richard Genoud <richard.genoud@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41cc15ce40dbe5cbc938f9e4acdf0fb0156fd374
Author: Chris Boot <bootc@bootc.net>
Date:   Tue Apr 24 07:24:52 2012 +0000

    e1000e: Disable ASPM L1 on 82574

    commit d4a4206ebbaf48b55803a7eb34e330530d83a889 upstream.

    ASPM on the 82574 causes trouble. Currently the driver disables L0s for
    this NIC but only disables L1 if the MTU is >1500. This patch simply
    causes L1 to be disabled regardless of the MTU setting.

    Signed-off-by: Chris Boot <bootc@bootc.net>
    Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>
    Cc: Nix <nix@esperi.org.uk>
    Link: https://lkml.org/lkml/2012/3/19/362
    Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfa379de3ffabed3dd9715144804535484e51f4e
Author: Al Cooper <acooper@gmail.com>
Date:   Fri Mar 16 15:54:17 2012 -0400

    mmc: Prevent 1.8V switch for SD hosts that don't support UHS modes.

    commit 4188bba0e9e7ba58d231b528df495666f2742b74 upstream.

    The driver should not try to switch to 1.8V when the SD 3.0 host
    controller does not have any UHS capabilities bits set (SDR50, DDR50
    or SDR104). See page 72 of "SD Specifications Part A2 SD Host
    Controller Simplified Specification Version 3.00" under
    "1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the host
    capabilities data structure for all V3.0 host controllers, only set them
    if SDR104, SDR50 or DDR50 is set in the host capabilities register. This
    will prevent the switch to 1.8V later.

    Signed-off-by: Al Cooper <acooper@gmail.com>
    Acked-by: Arindam Nath <arindam.nath@amd.com>
    Acked-by: Philip Rakity <prakity@marvell.com>
    Acked-by: Girish K S <girish.shivananjappa@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09e4ad5aa68deaebac4e9d2831624e5ca33a439d
Author: Subhash Jadavani <subhashj@codeaurora.org>
Date:   Wed Aug 10 11:16:01 2011 +0530

    mmc: sd: Handle SD3.0 cards not supporting UHS-I bus speed mode

    commit f2815f68dabbb373fd1c9f0fd4a609d486697c2b upstream.

    Here is Essential conditions to indicate Version 3.00 Card
    (SD_SPEC=2 and SD_SPEC3=1) :
    (1) The card shall support CMD6
    (2) The card shall support CMD8
    (3) The card shall support CMD42
    (4) User area capacity shall be up to 2GB (SDSC) or 32GB (SDHC)
        User area capacity shall be more than or equal to 32GB and
        up to 2TB (SDXC)
    (5) Speed Class shall be supported (SDHC or SDXC)

    So even if SD card doesn't support any of the newly defined
    UHS-I bus speed mode, it can advertise itself as SD3.0 cards
    as long as it supports all the essential conditions of
    SD3.0 cards. Given this, these type of cards should atleast
    run in High Speed mode @50MHZ if it supports HS.

    But current initialization sequence for SD3.0 cards is
    such that these non-UHS-I SD3.0 cards runs in Default
    Speed mode @25MHz.

    This patch makes sure that these non-UHS-I SD3.0 cards run
    in High Speed Mode @50MHz.

    Tested this patch with SanDisk Extreme SDHC 8GB Class 10 card.

    Reported-by: "Hiremath, Vaibhav" <hvaibhav@ti.com>
    Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>

commit 9523d5244a925f514e5daf04e5030a68e91f55cd
Author: Phillip Lougher <phillip@squashfs.org.uk>
Date:   Mon Jan 2 17:47:14 2012 +0000

    Squashfs: fix mount time sanity check for corrupted superblock

    commit cc37f75a9ffbbfcb1c3297534f293c8284e3c5a6 upstream.

    A Squashfs filesystem containing nothing but an empty directory,
    although unusual and ultimately pointless, is still valid.

    The directory_table >= next_table sanity check rejects these
    filesystems as invalid because the directory_table is empty and
    equal to next_table.

    Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b960ba52595157ae215c4e899e9da99fbc81959a
Author: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Date:   Fri Jul 6 17:19:43 2012 +0900

    pch_uart: Fix parity setting issue

    commit 38bd2a1ac736901d1cf4971c78ef952ba92ef78b upstream.

    Parity Setting value is reverse.
    E.G. In case of setting ODD parity, EVEN value is set.
    This patch inverts "if" condition.

    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b14f6f47a76380216419e70a3d569eed730a47b
Author: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Date:   Fri Jul 6 17:19:42 2012 +0900

    pch_uart: Fix rx error interrupt setting issue

    commit 9539dfb7ac1c84522fe1f79bb7dac2990f3de44a upstream.

    Rx Error interrupt(E.G. parity error) is not enabled.
    So, when parity error occurs, error interrupt is not occurred.
    As a result, the received data is not dropped.

    This patch adds enable/disable rx error interrupt code.

    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00b35456c281ca28739b83e6493ae5e981c68bf5
Author: Alan Cox <alan@linux.intel.com>
Date:   Mon Jul 2 18:51:38 2012 +0100

    pch_uart: Fix missing break for 16 byte fifo

    commit 9bc03743fff0770dc5a5324ba92e67cc377f16ca upstream.

    Otherwise we fall back to the wrong value.

    Reported-by: <dcb314@hotmail.com>
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44091
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abfbc26e32cd42374213c90766a5f416ad58732c
Author: Douglas Bagnall <douglas@paradise.net.nz>
Date:   Fri Jul 6 23:27:57 2012 -0300

    media: Avoid sysfs oops when an rc_dev's raw device is absent

    commit 720bb6436ff30fccad05cf5bdf961ea5b1f5686d upstream.

    For some reason, when the lirc daemon learns that a usb remote control
    has been unplugged, it wants to read the sysfs attributes of the
    disappearing device. This is useful for uncovering transient
    inconsistencies, but less so for keeping the system running when such
    inconsistencies exist.

    Under some circumstances (like every time I unplug my dvb stick from
    my laptop), lirc catches an rc_dev whose raw event handler has been
    removed (presumably by ir_raw_event_unregister), and proceeds to
    interrogate the raw protocols supported by the NULL pointer.

    This patch avoids the NULL dereference, and ignores the issue of how
    this state of affairs came about in the first place.

    Version 2 incorporates changes recommended by Mauro Carvalho Chehab
    (-ENODEV instead of -EINVAL, and a signed-off-by).

    Signed-off-by: Douglas Bagnall <douglas@paradise.net.nz>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe979e2c0aa6e5b9157c3b381b43de2ca6965d7e
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Sep 11 20:49:53 2012 -0400

    time: Move ktime_t overflow checking into timespec_valid_strict

    commit cee58483cf56e0ba355fdd97ff5e8925329aa936 upstream

    Andreas Bombe reported that the added ktime_t overflow checking added to
    timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
    timekeeping inputs") was causing problems with X.org because it caused
    timeouts larger then KTIME_T to be invalid.

    Previously, these large timeouts would be clamped to KTIME_MAX and would
    never expire, which is valid.

    This patch splits the ktime_t overflow checking into a new
    timespec_valid_strict function, and converts the timekeeping codes
    internal checking to use this more strict function.

    Reported-and-tested-by: Andreas Bombe <aeb@debian.org>
    Cc: Zhouping Liu <zliu@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ffa9a8069801e36e2aceed5a77482b8b0841757
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Sep 11 20:49:52 2012 -0400

    time: Avoid making adjustments if we haven't accumulated anything

    commit bf2ac312195155511a0f79325515cbb61929898a upstream

    If update_wall_time() is called and the current offset isn't large
    enough to accumulate, avoid re-calling timekeeping_adjust which may
    change the clock freq and can cause 1ns inconsistencies with
    CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE.

    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44fa9a0111168832510f8add6d589e73eac6793d
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Sep 11 20:49:51 2012 -0400

    time: Improve sanity checking of timekeeping inputs

    commit 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b upstream

    Unexpected behavior could occur if the time is set to a value large
    enough to overflow a 64bit ktime_t (which is something larger then the
    year 2262).

    Also unexpected behavior could occur if large negative offsets are
    injected via adjtimex.

    So this patch improves the sanity check timekeeping inputs by
    improving the timespec_valid() check, and then makes better use of
    timespec_valid() to make sure we don't set the time to an invalid
    negative value or one that overflows ktime_t.

    Note: This does not protect from setting the time close to overflowing
    ktime_t and then letting natural accumulation cause the overflow.

    Reported-by: CAI Qian <caiqian@redhat.com>
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Zhouping Liu <zliu@redhat.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81cee4e9e6329bff1adafefed0ff2db85b360a41
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jun 4 00:18:19 2012 +0000

    drop_monitor: dont sleep in atomic context

    commit bec4596b4e6770c7037f21f6bd27567b152dc0d6 upstream.

    drop_monitor calls several sleeping functions while in atomic context.

     BUG: sleeping function called from invalid context at mm/slub.c:943
     in_atomic(): 1, irqs_disabled(): 0, pid: 2103, name: kworker/0:2
     Pid: 2103, comm: kworker/0:2 Not tainted 3.5.0-rc1+ #55
     Call Trace:
      [<ffffffff810697ca>] __might_sleep+0xca/0xf0
      [<ffffffff811345a3>] kmem_cache_alloc_node+0x1b3/0x1c0
      [<ffffffff8105578c>] ? queue_delayed_work_on+0x11c/0x130
      [<ffffffff815343fb>] __alloc_skb+0x4b/0x230
      [<ffffffffa00b0360>] ? reset_per_cpu_data+0x160/0x160 [drop_monitor]
      [<ffffffffa00b022f>] reset_per_cpu_data+0x2f/0x160 [drop_monitor]
      [<ffffffffa00b03ab>] send_dm_alert+0x4b/0xb0 [drop_monitor]
      [<ffffffff810568e0>] process_one_work+0x130/0x4c0
      [<ffffffff81058249>] worker_thread+0x159/0x360
      [<ffffffff810580f0>] ? manage_workers.isra.27+0x240/0x240
      [<ffffffff8105d403>] kthread+0x93/0xa0
      [<ffffffff816be6d4>] kernel_thread_helper+0x4/0x10
      [<ffffffff8105d370>] ? kthread_freezable_should_stop+0x80/0x80
      [<ffffffff816be6d0>] ? gs_change+0xb/0xb

    Rework the logic to call the sleeping functions in right context.

    Use standard timer/workqueue api to let system chose any cpu to perform
    the allocation and netlink send.

    Also avoid a loop if reset_per_cpu_data() cannot allocate memory :
    use mod_timer() to wait 1/10 second before next try.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c51de7f1479784bf4f7d8fb86968fc87c252a3a
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Tue May 1 08:18:02 2012 +0000

    drop_monitor: prevent init path from scheduling on the wrong cpu

    commit 4fdcfa12843bca38d0c9deff70c8720e4e8f515f upstream.

    I just noticed after some recent updates, that the init path for the drop
    monitor protocol has a minor error.  drop monitor maintains a per cpu structure,
    that gets initalized from a single cpu.  Normally this is fine, as the protocol
    isn't in use yet, but I recently made a change that causes a failed skb
    allocation to reschedule itself .  Given the current code, the implication is
    that this workqueue reschedule will take place on the wrong cpu.  If drop
    monitor is used early during the boot process, its possible that two cpus will
    access a single per-cpu structure in parallel, possibly leading to data
    corruption.

    This patch fixes the situation, by storing the cpu number that a given instance
    of this per-cpu data should be accessed from.  In the case of a need for a
    reschedule, the cpu stored in the struct is assigned the rescheule, rather than
    the currently executing cpu

    Tested successfully by myself.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2f89a7caf4491dba4086663139e6fbc1ab59711
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Fri Apr 27 10:11:49 2012 +0000

    drop_monitor: Make updating data->skb smp safe

    commit 3885ca785a3618593226687ced84f3f336dc3860 upstream.

    Eric Dumazet pointed out to me that the drop_monitor protocol has some holes in
    its smp protections.  Specifically, its possible to replace data->skb while its
    being written.  This patch corrects that by making data->skb an rcu protected
    variable.  That will prevent it from being overwritten while a tracepoint is
    modifying it.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
    CC: David Miller <davem@davemloft.net>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34c0bc428c081c314c4b4ebf6c0fd335cf53c133
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Fri Apr 27 10:11:48 2012 +0000

    drop_monitor: fix sleeping in invalid context warning

    commit cde2e9a651b76d8db36ae94cd0febc82b637e5dd upstream.

    Eric Dumazet pointed out this warning in the drop_monitor protocol to me:

    [   38.352571] BUG: sleeping function called from invalid context at kernel/mutex.c:85
    [   38.352576] in_atomic(): 1, irqs_disabled(): 0, pid: 4415, name: dropwatch
    [   38.352580] Pid: 4415, comm: dropwatch Not tainted 3.4.0-rc2+ #71
    [   38.352582] Call Trace:
    [   38.352592]  [<ffffffff8153aaf0>] ? trace_napi_poll_hit+0xd0/0xd0
    [   38.352599]  [<ffffffff81063f2a>] __might_sleep+0xca/0xf0
    [   38.352606]  [<ffffffff81655b16>] mutex_lock+0x26/0x50
    [   38.352610]  [<ffffffff8153aaf0>] ? trace_napi_poll_hit+0xd0/0xd0
    [   38.352616]  [<ffffffff810b72d9>] tracepoint_probe_register+0x29/0x90
    [   38.352621]  [<ffffffff8153a585>] set_all_monitor_traces+0x105/0x170
    [   38.352625]  [<ffffffff8153a8ca>] net_dm_cmd_trace+0x2a/0x40
    [   38.352630]  [<ffffffff8154a81a>] genl_rcv_msg+0x21a/0x2b0
    [   38.352636]  [<ffffffff810f8029>] ? zone_statistics+0x99/0xc0
    [   38.352640]  [<ffffffff8154a600>] ? genl_rcv+0x30/0x30
    [   38.352645]  [<ffffffff8154a059>] netlink_rcv_skb+0xa9/0xd0
    [   38.352649]  [<ffffffff8154a5f0>] genl_rcv+0x20/0x30
    [   38.352653]  [<ffffffff81549a7e>] netlink_unicast+0x1ae/0x1f0
    [   38.352658]  [<ffffffff81549d76>] netlink_sendmsg+0x2b6/0x310
    [   38.352663]  [<ffffffff8150824f>] sock_sendmsg+0x10f/0x130
    [   38.352668]  [<ffffffff8150abe0>] ? move_addr_to_kernel+0x60/0xb0
    [   38.352673]  [<ffffffff81515f04>] ? verify_iovec+0x64/0xe0
    [   38.352677]  [<ffffffff81509c46>] __sys_sendmsg+0x386/0x390
    [   38.352682]  [<ffffffff810ffaf9>] ? handle_mm_fault+0x139/0x210
    [   38.352687]  [<ffffffff8165b5bc>] ? do_page_fault+0x1ec/0x4f0
    [   38.352693]  [<ffffffff8106ba4d>] ? set_next_entity+0x9d/0xb0
    [   38.352699]  [<ffffffff81310b49>] ? tty_ldisc_deref+0x9/0x10
    [   38.352703]  [<ffffffff8106d363>] ? pick_next_task_fair+0x63/0x140
    [   38.352708]  [<ffffffff8150b8d4>] sys_sendmsg+0x44/0x80
    [   38.352713]  [<ffffffff8165f8e2>] system_call_fastpath+0x16/0x1b

    It stems from holding a spinlock (trace_state_lock) while attempting to register
    or unregister tracepoint hooks, making in_atomic() true in this context, leading
    to the warning when the tracepoint calls might_sleep() while its taking a mutex.
    Since we only use the trace_state_lock to prevent trace protocol state races, as
    well as hardware stat list updates on an rcu write side, we can just convert the
    spinlock to a mutex to avoid this problem.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
    CC: David Miller <davem@davemloft.net>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae04311e04e09892048fbdf7e23e852d8f8f3ced
Author: Jarod Wilson <jarod@redhat.com>
Date:   Mon Jun 4 13:05:24 2012 -0300

    media: lirc_sir: make device registration work

    commit 4b71ca6bce8fab3d08c61bf330e781f957934ae1 upstream.

    For one, the driver device pointer needs to be filled in, or the lirc core
    will refuse to load the driver. And we really need to wire up all the
    platform_device bits. This has been tested via the lirc sourceforge tree
    and verified to work, been sitting there for months, finally getting
    around to sending it. :\

    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    CC: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64ac72f81b1b41819dab596d1524bd5cae4813fd
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jun 22 13:36:05 2012 +0200

    sched: Fix race in task_group()

    commit 8323f26ce3425460769605a6aece7a174edaa7d1 upstream.

    Stefan reported a crash on a kernel before a3e5d1091c1 ("sched:
    Don't call task_group() too many times in set_task_rq()"), he
    found the reason to be that the multiple task_group()
    invocations in set_task_rq() returned different values.

    Looking at all that I found a lack of serialization and plain
    wrong comments.

    The below tries to fix it using an extra pointer which is
    updated under the appropriate scheduler locks. Its not pretty,
    but I can't really see another way given how all the cgroup
    stuff works.

    Reported-and-tested-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1340364965.18025.71.camel@twins
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf0a716684d6743275fdc45c6a43317272fba142
Author: Thomas Renninger <trenn@suse.de>
Date:   Thu Jul 12 12:24:33 2012 +0200

    cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression

    commit c4686c71a9183f76e3ef59098da5c098748672f6 upstream.

    Commit d640113fe80e45ebd4a5b420b introduced a regression on SMP
    systems where the processor core with ACPI id zero is disabled
    (typically should be the case because of hyperthreading).
    The regression got spread through stable kernels.
    On 3.0.X it got introduced via 3.0.18.

    Such platforms may be rare, but do exist.
    Look out for a disabled processor with acpi_id 0 in dmesg:
    ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled)

    This problem has been observed on a:
    HP Proliant BL280c G6 blade

    This patch restricts the introduced workaround to platforms
    with nr_cpu_ids <= 1.

    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 894682fdede531729e9597cab56615e479933ffd
Author: Daniel J Blueman <daniel@quora.org>
Date:   Mon Jul 23 12:22:37 2012 +0800

    libata: Prevent interface errors with Seagate FreeAgent GoFlex

    commit c531077f40abc9f2129c4c83a30b3f8d6ce1c0e7 upstream.

    When using my Seagate FreeAgent GoFlex eSATAp external disk enclosure,
    interface errors are always seen until 1.5Gbps is negotiated [1]. This
    occurs using any disk in the enclosure, and when the disk is connected
    directly with a generic passive eSATAp cable, we see stable 3Gbps
    operation as expected.

    Blacklist 3Gbps mode to avoid dataloss and the ~30s delay bus reset
    and renegotiation incurs.

    Signed-off-by: Daniel J Blueman <daniel@quora.org>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25dee10e0c0b7093df5c32284cc85817820c6003
Author: Weiping Pan <wpan@redhat.com>
Date:   Mon Jul 23 10:37:48 2012 +0800

    rds: set correct msg_namelen

    commit 06b6a1cf6e776426766298d055bb3991957d90a7 upstream.

    Jay Fenlason (fenlason@redhat.com) found a bug,
    that recvfrom() on an RDS socket can return the contents of random kernel
    memory to userspace if it was called with a address length larger than
    sizeof(struct sockaddr_in).
    rds_recvmsg() also fails to set the addr_len paramater properly before
    returning, but that's just a bug.
    There are also a number of cases wher recvfrom() can return an entirely bogus
    address. Anything in rds_recvmsg() that returns a non-negative value but does
    not go through the "sin = (struct sockaddr_in *)msg->msg_name;" code path
    at the end of the while(1) loop will return up to 128 bytes of kernel memory
    to userspace.

    And I write two test programs to reproduce this bug, you will see that in
    rds_server, fromAddr will be overwritten and the following sock_fd will be
    destroyed.
    Yes, it is the programmer's fault to set msg_namelen incorrectly, but it is
    better to make the kernel copy the real length of address to user space in
    such case.

    How to run the test programs ?
    I test them on 32bit x86 system, 3.5.0-rc7.

    1 compile
    gcc -o rds_client rds_client.c
    gcc -o rds_server rds_server.c

    2 run ./rds_server on one console

    3 run ./rds_client on another console

    4 you will see something like:
    server is waiting to receive data...
    old socket fd=3
    server received data from client:data from client
    msg.msg_namelen=32
    new socket fd=-1067277685
    sendmsg()
    : Bad file descriptor

    /***************** rds_client.c ********************/

    int main(void)
    {
    	int sock_fd;
    	struct sockaddr_in serverAddr;
    	struct sockaddr_in toAddr;
    	char recvBuffer[128] = "data from client";
    	struct msghdr msg;
    	struct iovec iov;

    	sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
    	if (sock_fd < 0) {
    		perror("create socket error\n");
    		exit(1);
    	}

    	memset(&serverAddr, 0, sizeof(serverAddr));
    	serverAddr.sin_family = AF_INET;
    	serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
    	serverAddr.sin_port = htons(4001);

    	if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
    		perror("bind() error\n");
    		close(sock_fd);
    		exit(1);
    	}

    	memset(&toAddr, 0, sizeof(toAddr));
    	toAddr.sin_family = AF_INET;
    	toAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
    	toAddr.sin_port = htons(4000);
    	msg.msg_name = &toAddr;
    	msg.msg_namelen = sizeof(toAddr);
    	msg.msg_iov = &iov;
    	msg.msg_iovlen = 1;
    	msg.msg_iov->iov_base = recvBuffer;
    	msg.msg_iov->iov_len = strlen(recvBuffer) + 1;
    	msg.msg_control = 0;
    	msg.msg_controllen = 0;
    	msg.msg_flags = 0;

    	if (sendmsg(sock_fd, &msg, 0) == -1) {
    		perror("sendto() error\n");
    		close(sock_fd);
    		exit(1);
    	}

    	printf("client send data:%s\n", recvBuffer);

    	memset(recvBuffer, '\0', 128);

    	msg.msg_name = &toAddr;
    	msg.msg_namelen = sizeof(toAddr);
    	msg.msg_iov = &iov;
    	msg.msg_iovlen = 1;
    	msg.msg_iov->iov_base = recvBuffer;
    	msg.msg_iov->iov_len = 128;
    	msg.msg_control = 0;
    	msg.msg_controllen = 0;
    	msg.msg_flags = 0;
    	if (recvmsg(sock_fd, &msg, 0) == -1) {
    		perror("recvmsg() error\n");
    		close(sock_fd);
    		exit(1);
    	}

    	printf("receive data from server:%s\n", recvBuffer);

    	close(sock_fd);

    	return 0;
    }

    /***************** rds_server.c ********************/

    int main(void)
    {
    	struct sockaddr_in fromAddr;
    	int sock_fd;
    	struct sockaddr_in serverAddr;
    	unsigned int addrLen;
    	char recvBuffer[128];
    	struct msghdr msg;
    	struct iovec iov;

    	sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
    	if(sock_fd < 0) {
    		perror("create socket error\n");
    		exit(0);
    	}

    	memset(&serverAddr, 0, sizeof(serverAddr));
    	serverAddr.sin_family = AF_INET;
    	serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
    	serverAddr.sin_port = htons(4000);
    	if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
    		perror("bind error\n");
    		close(sock_fd);
    		exit(1);
    	}

    	printf("server is waiting to receive data...\n");
    	msg.msg_name = &fromAddr;

    	/*
    	 * I add 16 to sizeof(fromAddr), ie 32,
    	 * and pay attention to the definition of fromAddr,
    	 * recvmsg() will overwrite sock_fd,
    	 * since kernel will copy 32 bytes to userspace.
    	 *
    	 * If you just use sizeof(fromAddr), it works fine.
    	 * */
    	msg.msg_namelen = sizeof(fromAddr) + 16;
    	/* msg.msg_namelen = sizeof(fromAddr); */
    	msg.msg_iov = &iov;
    	msg.msg_iovlen = 1;
    	msg.msg_iov->iov_base = recvBuffer;
    	msg.msg_iov->iov_len = 128;
    	msg.msg_control = 0;
    	msg.msg_controllen = 0;
    	msg.msg_flags = 0;

    	while (1) {
    		printf("old socket fd=%d\n", sock_fd);
    		if (recvmsg(sock_fd, &msg, 0) == -1) {
    			perror("recvmsg() error\n");
    			close(sock_fd);
    			exit(1);
    		}
    		printf("server received data from client:%s\n", recvBuffer);
    		printf("msg.msg_namelen=%d\n", msg.msg_namelen);
    		printf("new socket fd=%d\n", sock_fd);
    		strcat(recvBuffer, "--data from server");
    		if (sendmsg(sock_fd, &msg, 0) == -1) {
    			perror("sendmsg()\n");
    			close(sock_fd);
    			exit(1);
    		}
    	}

    	close(sock_fd);
    	return 0;
    }

    Signed-off-by: Weiping Pan <wpan@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45516ddc16abc923104d78bb3eb772ac0a09e33e
Author: Li Zhong <zhong@linux.vnet.ibm.com>
Date:   Tue Jul 24 15:02:49 2012 -0700

    Fix a dead loop in async_synchronize_full()

    [Fixed upstream by commits 2955b47d2c1983998a8c5915cb96884e67f7cb53 and
    a4683487f90bfe3049686fc5c566bdc1ad03ace6 from Dan Williams, but they are much
    more intrusive than this tiny fix, according to Andrew - gregkh]

    This patch tries to fix a dead loop in  async_synchronize_full(), which
    could be seen when preemption is disabled on a single cpu machine.

    void async_synchronize_full(void)
    {
            do {
                    async_synchronize_cookie(next_cookie);
            } while (!list_empty(&async_running) || !
    list_empty(&async_pending));
    }

    async_synchronize_cookie() calls async_synchronize_cookie_domain() with
    &async_running as the default domain to synchronize.

    However, there might be some works in the async_pending list from other
    domains. On a single cpu system, without preemption, there is no chance
    for the other works to finish, so async_synchronize_full() enters a dead
    loop.

    It seems async_synchronize_full() wants to synchronize all entries in
    all running lists(domains), so maybe we could just check the entry_count
    to know whether all works are finished.

    Currently, async_synchronize_cookie_domain() expects a non-NULL running
    list ( if NULL, there would be NULL pointer dereference ), so maybe a
    NULL pointer could be used as an indication for the functions to
    synchronize all works in all domains.

    Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
    Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Dan Williams <dan.j.williams@gmail.com>
    Cc: Christian Kujau <lists@nerdbynature.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b64295e8b4d340a136f02f08baffa9efc0f2e0bc
Author: Rustad, Mark D <mark.d.rustad@intel.com>
Date:   Wed Jul 18 09:06:07 2012 +0000

    net: Statically initialize init_net.dev_base_head

    commit 734b65417b24d6eea3e3d7457e1f11493890ee1d upstream.

    This change eliminates an initialization-order hazard most
    recently seen when netprio_cgroup is built into the kernel.

    With thanks to Eric Dumazet for catching a bug.

    Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41ed10ac178bd4caed55434e43cb797602da93fc
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Sat Aug 25 19:28:06 2012 +0200

    Bluetooth: Add support for Apple vendor-specific devices

    commit 1fa6535faf055cd71311ab887e94fc234f04ee18 upstream.

    As pointed out by Gustavo and Marcel, all Apple-specific Broadcom
    devices seen so far have the same interface class, subclass and
    protocol numbers. This patch adds an entry which matches all of them,
    using the new USB_VENDOR_AND_INTERFACE_INFO() macro.

    In particular, this patch adds support for the MacBook Pro Retina
    (05ac:8286), which is not in the present list.

    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Tested-by: Shea Levy <shea@shealevy.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d94c8cee9e45bb2afdff13058f70e52c758e8f7
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Mon Aug 6 15:36:49 2012 -0300

    Bluetooth: Use USB_VENDOR_AND_INTERFACE() for Broadcom devices

    commit 92c385f46b30f4954e9dd2d2005c12d233b479ea upstream.

    Many Broadcom devices has a vendor specific devices class, with this rule
    we match all existent and future controllers with this behavior.

    We also remove old rules to that matches product id for Broadcom devices.

    Tested-by: John Hommel <john.hommel@hp.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d10d2f0a2855dfcf21ddbc2a962ad342cd02db1f
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Tue Jul 10 14:07:38 2012 -0500

    Bluetooth: btusb: Add vendor specific ID (0a5c:21f4) BCM20702A0

    commit 61c964ba1748e984cb232b431582815899bf10fe upstream.

    Patch adds support for BCM20702A0 device id (0a5c:21f4).

    usb-devices after patch was applied:
    T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0a5c ProdID=21f4 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=E4D53DF154D6
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    usb-devices before patch was applied:
    T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0a5c ProdID=21f4 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=E4D53DF154D6
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Tested-by: Chris Gagnon <chris.gagnon@canonical.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b69eba70b90f0d5a058bfd129c94cb98ccc43ef2
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue May 15 18:44:15 2012 +0100

    x86: Fix boot on Twinhead H12Y

    commit 80b3e557371205566a71e569fbfcce5b11f92dbe upstream.

    Despite lots of investigation into why this is needed we don't
    know or have an elegant cure. The only answer found on this
    laptop is to mark a problem region as used so that Linux doesn't
    put anything there.

    Currently all the users add reserve= command lines and anyone
    not knowing this needs to find the magic page that documents it.
    Automate it instead.

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Tested-and-bugfixed-by: Arne Fitzenreiter <arne@fitzenreiter.de>
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=10231
    Link: http://lkml.kernel.org/r/20120515174347.5109.94551.stgit@bluebook
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc713e264ea9badd399aa34f208154a64e4e1b3b
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date:   Sun Sep 2 00:28:19 2012 +0800

    workqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic

    commit 96e65306b81351b656835c15931d1d237b252f27 upstream.

    The compiler may compile the following code into TWO write/modify
    instructions.

    	worker->flags &= ~WORKER_UNBOUND;
    	worker->flags |= WORKER_REBIND;

    so the other CPU may temporarily see worker->flags which doesn't have
    either WORKER_UNBOUND or WORKER_REBIND set and perform local wakeup
    prematurely.

    Fix it by using single explicit assignment via ACCESS_ONCE().

    Because idle workers have another WORKER_NOT_RUNNING flag, this bug
    doesn't exist for them; however, update it to use the same pattern for
    consistency.

    tj: Applied the change to idle workers too and updated comments and
        patch description a bit.

    Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2471ec3e86a473ec354b4707e8e2d2367d1af00
Author: Wang Xingchao <xingchao.wang@intel.com>
Date:   Thu Sep 13 07:43:22 2012 +0800

    drm/i915: HDMI - Clear Audio Enable bit for Hot Plug

    commit b98b60167279df3acac9422c3c9820d9ebbcf9fb upstream.

    Clear Audio Enable bit to trigger unsolicated event to notify Audio
    Driver part the HDMI hot plug change. The patch fixed the bug when
    remove HDMI cable the bit was not cleared correctly.

    In intel_hdmi_dpms(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
    be set to trigger unsolicated event to notify Alsa driver the change.

    intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
    remove the hdmi cable, here's debug log:

    [  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
    [  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0

    so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this
    cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.

    This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:

    [  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
    [  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0

    Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7693ca135d181dbc9748f0612bf010cc1681eba0
Author: AceLan Kao <acelan.kao@canonical.com>
Date:   Wed Jul 4 15:20:14 2012 +0800

    asus-nb-wmi: add some video toggle keys

    commit 3766054fff4af1b58a1440a284907887f4d2e8be upstream.

    There are some new video switch keys that used by newer machines.
    0xA0 - SDSP HDMI only
    0xA1 - SDSP LCD + HDMI
    0xA2 - SDSP CRT + HDMI
    0xA3 - SDSP TV + HDMI
    But in Linux, there is no suitable userspace application to handle this,
    so, mapping them all to KEY_SWITCHVIDEOMODE.

    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06aac3b6df0a805f066aa8f5dcf830eeb7f353a3
Author: Corentin Chary <corentin.chary@gmail.com>
Date:   Mon Aug 20 23:01:51 2012 +0200

    asus-laptop: HRWS/HWRS typo

    commit 8871e99f89b7d7b1ea99de550eea2a56273f42ab upstream.

    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=24222
    Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 062a59eeb37259c1cb09bf2cfd1388e729265815
Author: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Date:   Mon Aug 20 15:16:04 2012 +0100

    drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping

    commit 52e9b39d9a89ae33662596bd30e62dd56bddbe73 upstream.

    There is a more recent APU stepping with a new PCI ID
    shipping in the same board by Fujitsu which needs the
    same quirk to correctly mark the back plane connectors.

    Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eafd7bd375bbfda99f57d5f0e615e9d81bef4c0d
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Aug 21 16:29:47 2012 +1000

    fbcon: fix race condition between console lock and cursor timer (v1.1)

    commit d8636a2717bb3da2a7ce2154bf08de90bb8c87b0 upstream.

    So we've had a fair few reports of fbcon handover breakage between
    efi/vesafb and i915 surface recently, so I dedicated a couple of
    days to finding the problem.

    Essentially the last thing we saw was the conflicting framebuffer
    message and that was all.

    So after much tracing with direct netconsole writes (printks
    under console_lock not so useful), I think I found the race.

    Thread A (driver load)    Thread B (timer thread)
      unbind_con_driver ->              |
      bind_con_driver ->                |
      vc->vc_sw->con_deinit ->          |
      fbcon_deinit ->                   |
      console_lock()                    |
          |                             |
          |                       fbcon_flashcursor timer fires
          |                       console_lock() <- blocked for A
          |
          |
    fbcon_del_cursor_timer ->
      del_timer_sync
      (BOOM)

    Of course because all of this is under the console lock,
    we never see anything, also since we also just unbound the active
    console guess what we never see anything.

    Hopefully this fixes the problem for anyone seeing vesafb->kms
    driver handoff.

    v1.1: add comment suggestion from Alan.

    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Tested-by: Josh Boyer <jwboyer@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b3746b3cad8d6176432c1513bc3099266bae955
Author: Robin Holt <holt@sgi.com>
Date:   Tue Aug 21 16:16:02 2012 -0700

    drivers/misc/sgi-xp/xpc_uv.c: SGI XPC fails to load when cpu 0 is out of IRQ resources

    commit 7838f994b4fceff24c343f4e26a6cf4393869579 upstream.

    On many of our larger systems, CPU 0 has had all of its IRQ resources
    consumed before XPC loads.  Worst cases on machines with multiple 10
    GigE cards and multiple IB cards have depleted the entire first socket
    of IRQs.

    This patch makes selecting the node upon which IRQs are allocated (as
    well as all the other GRU Message Queue structures) specifiable as a
    module load param and has a default behavior of searching all nodes/cpus
    for an available resources.

    [akpm@linux-foundation.org: fix build: include cpu.h and module.h]
    Signed-off-by: Robin Holt <holt@sgi.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 d6163c4d59f7797c801e84ec537c6d7f99341717
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Wed Aug 15 21:31:55 2012 +0200

    PM / Runtime: Clear power.deferred_resume on success in rpm_suspend()

    commit 58a34de7b1a920d287d17d2ca08bc9aaf7e6d35b upstream.

    The power.deferred_resume can only be set if the runtime PM status
    of device is RPM_SUSPENDING and it should be cleared after its
    status has been changed, regardless of whether or not the runtime
    suspend has been successful.  However, it only is cleared on
    suspend failure, while it may remain set on successful suspend and
    is happily leaked to rpm_resume() executed in that case.

    That shouldn't happen, so if power.deferred_resume is set in
    rpm_suspend() after the status has been changed to RPM_SUSPENDED,
    clear it before calling rpm_resume().  Then, it doesn't need to be
    cleared before changing the status to RPM_SUSPENDING any more,
    because it's always cleared after the status has been changed to
    either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure).

    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5af14b89d07f9ea69a582687adb1edcaa82f03b9
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Wed Aug 15 21:31:45 2012 +0200

    PM / Runtime: Fix rpm_resume() return value for power.no_callbacks set

    commit 7f321c26c04807834fef4c524d2b21573423fc74 upstream.

    For devices whose power.no_callbacks flag is set, rpm_resume()
    should return 1 if the device's parent is already active, so that
    the callers of pm_runtime_get() don't think that they have to wait
    for the device to resume (asynchronously) in that case (the core
    won't queue up an asynchronous resume in that case, so there's
    nothing to wait for anyway).

    Modify the code accordingly (and make sure that an idle notification
    will be queued up on success, even if 1 is to be returned).

    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f20560e86297b92b4dff11cb2e6daa61b3f88368
Author: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date:   Tue Aug 21 16:16:10 2012 -0700

    drivers/rtc/rtc-rs5c348.c: fix hour decoding in 12-hour mode

    commit 7dbfb315b2aaef0a115765946bf3026d074c33a7 upstream.

    Correct the offset by subtracting 20 from tm_hour before taking the
    modulo 12.

    [ "Why 20?" I hear you ask. Or at least I did.

      Here's the reason why: RS5C348_BIT_PM is 32, and is - stupidly -
      included in the RS5C348_HOURS_MASK define.  So it's really subtracting
      out that bit to get "hour+12".  But then because it does things modulo
      12, it needs to add the 12 in again afterwards anyway.

      This code is confused.  It would be much clearer if RS5C348_HOURS_MASK
      just didn't include the RS5C348_BIT_PM bit at all, then it wouldn't
      need to do the silly subtract either.

      Whatever. It's all just math, the end result is the same.   - Linus ]

    Reported-by: James Nute <newten82@gmail.com>
    Tested-by: James Nute <newten82@gmail.com>
    Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
    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 d0179ca85eb702e31c645556f4dc2e58a3af31f4
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 10 15:22:09 2012 +0100

    mutex: Place lock in contended state after fastpath_lock failure

    commit 0bce9c46bf3b15f485d82d7e81dabed6ebcc24b1 upstream.

    ARM recently moved to asm-generic/mutex-xchg.h for its mutex
    implementation after the previous implementation was found to be missing
    some crucial memory barriers. However, this has revealed some problems
    running hackbench on SMP platforms due to the way in which the
    MUTEX_SPIN_ON_OWNER code operates.

    The symptoms are that a bunch of hackbench tasks are left waiting on an
    unlocked mutex and therefore never get woken up to claim it. This boils
    down to the following sequence of events:

            Task A        Task B        Task C        Lock value
    0                                                     1
    1       lock()                                        0
    2                     lock()                          0
    3                     spin(A)                         0
    4       unlock()                                      1
    5                                   lock()            0
    6                     cmpxchg(1,0)                    0
    7                     contended()                    -1
    8       lock()                                        0
    9       spin(C)                                       0
    10                                  unlock()          1
    11      cmpxchg(1,0)                                  0
    12      unlock()                                      1

    At this point, the lock is unlocked, but Task B is in an uninterruptible
    sleep with nobody to wake it up.

    This patch fixes the problem by ensuring we put the lock into the
    contended state if we fail to acquire it on the fastpath, ensuring that
    any blocked waiters are woken up when the mutex is released.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Chris Mason <chris.mason@fusionio.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3439be1c0b9df0ca9b760ff4861be5d6145da26
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Jul 26 12:03:59 2012 -0700

    xhci: Fix bug after deq ptr set to link TRB.

    commit 50d0206fcaea3e736f912fd5b00ec6233fb4ce44 upstream.

    This patch fixes a particularly nasty bug that was revealed by the ring
    expansion patches.  The bug has been present since the very beginning of
    the xHCI driver history, and could have caused general protection faults
    from bad memory accesses.

    The first thing to note is that a Set TR Dequeue Pointer command can
    move the dequeue pointer to a link TRB, if the canceled or stalled
    transfer TD ended just before a link TRB.  The function to increment the
    dequeue pointer, inc_deq, was written before cancellation and stall
    support was added.  It assumed that the dequeue pointer could never
    point to a link TRB.  It would unconditionally increment the dequeue
    pointer at the start of the function, check if the pointer was now on a
    link TRB, and move it to the top of the next segment if so.

    This means that if a Set TR Dequeue Point command moved the dequeue
    pointer to a link TRB, a subsequent call to inc_deq() would move the
    pointer off the segment and into la-la-land.  It would then read from
    that memory to determine if it was a link TRB.  Other functions would
    often call inc_deq() until the dequeue pointer matched some other
    pointer, which means this function would quite happily read all of
    system memory before wrapping around to the right pointer value.

    Often, there would be another endpoint segment from a different ring
    allocated from the same DMA pool, which would be contiguous to the
    segment inc_deq just stepped off of.  inc_deq would eventually find the
    link TRB in that segment, and blindly move the dequeue pointer back to
    the top of the correct ring segment.

    The only reason the original code worked at all is because there was
    only one ring segment.  With the ring expansion patches, the dequeue
    pointer would eventually wrap into place, but the dequeue segment would
    be out-of-sync.  On the second TD after the dequeue pointer was moved to
    a link TRB, trb_in_td() would fail (because the dequeue pointer and
    dequeue segment were out-of-sync), and this message would appear:

    ERROR Transfer event TRB DMA ptr not part of current TD

    This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
    port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
    I/O to offline device"),

    	https://bugzilla.kernel.org/show_bug.cgi?id=43333

    and possibly other general protection fault bugs as well.

    This patch should be backported to kernels as old as 2.6.31.  A separate
    patch will be created for kernels older than 3.4, since inc_deq was
    modified in 3.4 and this patch will not apply.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: James Ettle <theholyettlz@googlemail.com>
    Tested-by: Matthew Hall <mhall@mhcomputing.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8ec66c5a565c5ca47d2740226f3e2035c1883bf
Author: Moiz Sonasath <m-sonasath@ti.com>
Date:   Wed Sep 5 08:34:26 2012 +0300

    usb: host: xhci: fix compilation error for non-PCI based stacks

    commit 296365781903226a3fb8758901eaeec09d2798e4 upstream.

    For non PCI-based stacks, this function call
    usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
    made from xhci_shutdown is not applicable.

    Ideally, we wouldn't have any PCI-specific code on
    a generic driver such as the xHCI stack, but it looks
    like we should just stub usb_disable_xhci_ports() out
    for non-PCI devices.

    [ balbi@ti.com: slight improvement to commit log ]

    This patch should be backported to kernels as old as 3.0, since the
    commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch
    PPT ports to EHCI on shutdown.") was marked for stable.

    Signed-off-by: Moiz Sonasath<m-sonasath@ti.com>
    Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1e81baa2d46338345c6f16c0e873ef3e7d73188
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Wed Aug 22 11:53:18 2012 -0500

    xhci: Recognize USB 3.0 devices as superspeed at powerup

    commit 29d214576f936db627ff62afb9ef438eea18bcd2 upstream.

    On Intel Panther Point chipset USB 3.0 devices show up as
    high-speed devices on powerup, but after an s3 cycle they are
    correctly recognized as SuperSpeed. At powerup switch the port
    to xHCI so that USB 3.0 devices are correctly recognized.

    BugLink: http://bugs.launchpad.net/bugs/1000424

    This patch should be backported to kernels as old as 3.0, that contain
    commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
    EHCI/xHCI port switching."

    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f78e6ad433084ec0b7bc40ff9910f458609ee9cb
Author: Matthew Garrett <mjg@redhat.com>
Date:   Tue Aug 14 16:44:49 2012 -0400

    xhci: Make handover code more robust

    commit e955a1cd086de4d165ae0f4c7be7289d84b63bdc upstream.

    My test platform (Intel DX79SI) boots reliably under BIOS, but frequently
    crashes when booting via UEFI. I finally tracked this down to the xhci
    handoff code. It seems that reads from the device occasionally just return
    0xff, resulting in xhci_find_next_cap_offset generating a value that's
    larger than the resource region. We then oops when attempting to read the
    value. Sanity checking that value lets us avoid the crash.

    I've no idea what's causing the underlying problem, and xhci still doesn't
    actually *work* even with this, but the machine at least boots which will
    probably make further debugging easier.

    This should be backported to kernels as old as 2.6.31, that contain the
    commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff
    and HW initialization."

    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0a168c0f20189efc03264785edd55baf00d5acc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Aug 13 19:57:03 2012 +0300

    xhci: Fix a logical vs bitwise AND bug

    commit 052c7f9ffb0e95843e75448d02664459253f9ff8 upstream.

    The intent was to test whether the flag was set.

    This patch should be backported to stable kernels as old as 3.0, since
    it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 "xhci:
    Switch PPT ports to EHCI on shutdown.", which was marked for stable.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a4c06b80e8b0de688d0e71b7206aabeb2f8ea7f
Author: Keng-Yu Lin <kengyu@canonical.com>
Date:   Fri Aug 10 01:39:23 2012 +0800

    Intel xhci: Only switch the switchable ports

    commit a96874a2a92feaef607ddd3137277a788cb927a6 upstream.

    With a previous patch to enable the EHCI/XHCI port switching, it switches
    all the available ports.

    The assumption is not correct because the BIOS may expect some ports
    not switchable by the OS.

    There are two more registers that contains the information of the switchable
    and non-switchable ports.

    This patch adds the checking code for the two register so that only the
    switchable ports are altered.

    This patch should be backported to kernels as old as 3.0, that contain
    commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
    EHCI/xHCI port switching."

    Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d515ad3c27b2f41a0f2b29af61bb8cc131345782
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 4 10:41:02 2012 -0400

    USB: add device quirk for Joss Optical touchboard

    commit 92fc7a8b0f20bdb243c706daf42658e8e0cd2ef0 upstream.

    This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss
    infrared touchboard device.  The device doesn't like to be asked for
    its interface strings.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: adam ? <adam3337@wp.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15e87566fc6fafda50aca428dc068f9c157ec68f
Author: Éric Piel <piel@delmic.com>
Date:   Tue Sep 4 17:25:06 2012 +0200

    USB: ftdi-sio: add support for more Physik Instrumente devices

    commit dafc4f7be1a556ca3868d343c00127728b397068 upstream.

    Commit b69cc672052540 added support for the E-861.  After acquiring a C-867, I
    realised that every Physik Instrumente's device has a different PID. They are
    listed in the Windows device driver's .inf file. So here are all PIDs for the
    current (and probably future) USB devices from Physik Instrumente.

    Compiled, but only actually tested on the E-861 and C-867.

    Signed-off-by: Éric Piel <piel@delmic.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c361a311e59d5ce7ee86b022b0dc1114e79bdbd
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Sep 10 12:01:05 2012 +0200

    USB: ftdi_sio: do not claim CDC ACM function

    commit f08dea734844aa42ec57c229b0b73b3d7d21f810 upstream.

    The Microchip vid:pid 04d8:000a is used for their CDC ACM
    demo firmware application.  This is a device with a single
    function conforming to the CDC ACM specification and with
    the intention of demonstrating CDC ACM class firmware and
    driver interaction.  The demo is used on a number of
    development boards, and may also be used unmodified by
    vendors using Microchip hardware.

    Some vendors have re-used this vid:pid for other types of
    firmware, emulating FTDI chips. Attempting to continue to
    support such devices without breaking class based
    applications that by matching on interface
    class/subclass/proto being ff/ff/00.  I have no information
    about the actual device or interface descriptors, but this
    will at least make the proper CDC ACM devices work again.
    Anyone having details of the offending device's descriptors
    should update this entry with the details.

    Reported-by: Florian Wöhrl <fw@woehrl.biz>
    Reported-by: Xiaofan Chen <xiaofanc@gmail.com>
    Cc: Alan Cox <alan@linux.intel.com>
    Cc: Bruno Thomsen <bruno.thomsen@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a16bd7c72f5579461fd2c6059f2bf75ad6355ec8
Author: Horst Schirmeier <horst@schirmeier.com>
Date:   Fri Aug 31 00:00:28 2012 +0200

    USB: ftdi_sio: PID for NZR SEM 16+ USB

    commit 26a538b9ea2a3ee10dafc0068f0560dfd7b7ba37 upstream.

    This adds the USB PID for the NZR SEM 16+ USB energy monitor device
    <http://www.nzr.de>.  It works perfectly with the GPL software on
    <http://schou.dk/linux/sparometer/>.

    Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebf16a5b74e2f91cbfce4179064c35529ba9afad
Author: Pavankumar Kondeti <pkondeti@codeaurora.org>
Date:   Fri Sep 7 11:23:28 2012 +0530

    EHCI: Update qTD next pointer in QH overlay region during unlink

    commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream.

    There is a possibility of QH overlay region having reference to a stale
    qTD pointer during unlink.

    Consider an endpoint having two pending qTD before unlink process begins.
    The endpoint's QH queue looks like this.

    qTD1 --> qTD2 --> Dummy

    To unlink qTD2, QH is removed from asynchronous list and Asynchronous
    Advance Doorbell is programmed.  The qTD1's next qTD pointer is set to
    qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
    interrupt.  If QH's current qTD pointer points to qTD1, transfer overlay
    region still have reference to qTD2. But qtD2 is just unlinked and freed.
    This may cause EHCI system error.  Fix this by updating qTD next pointer
    in QH overlay region with the qTD next pointer of the current qTD.

    Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 863f36bf5ad7edde2ec1196b098fec951fca16d3
Author: Weston Andros Adamson <dros@netapp.com>
Date:   Thu Sep 6 15:54:27 2012 -0400

    NFS: return error from decode_getfh in decode open

    commit 01913b49cf1dc6409a07dd2a4cc6af2e77f3c410 upstream.

    If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last
    decode_* call must have succeeded.

    Signed-off-by: Weston Andros Adamson <dros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d351ebe91e308cebfefc6808fd96a53c9d8f0c7b
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Sep 4 11:05:07 2012 -0400

    NFS: Fix a problem with the legacy binary mount code

    commit 872ece86ea5c367aa92f44689c2d01a1c767aeb3 upstream.

    Apparently, am-utils is still using the legacy binary mountdata interface,
    and is having trouble parsing /proc/mounts due to the 'port=' field being
    incorrectly set.

    The following patch should fix up the regression.

    Reported-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 839e17b7fb531eec48714abf5962b0a1310f71d9
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Sep 3 14:56:02 2012 -0400

    NFS: Fix the initialisation of the readdir 'cookieverf' array

    commit c3f52af3e03013db5237e339c817beaae5ec9e3a upstream.

    When the NFS_COOKIEVERF helper macro was converted into a static
    inline function in commit 99fadcd764 (nfs: convert NFS_*(inode)
    helpers to static inline), we broke the initialisation of the
    readdir cookies, since that depended on doing a memset with an
    argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore
    changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *).

    At this point, NFS_COOKIEVERF seems to be more of an obfuscation
    than a helper, so the best thing would be to just get rid of it.

    Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881

    Reported-by: Andi Kleen <andi@firstfloor.org>
    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4395a14b80188c83d6b126f5617d2f1be852b2d
Author: Gertjan van Wingerde <gwingerde@gmail.com>
Date:   Fri Aug 31 19:22:11 2012 +0200

    rt2x00: Fix rfkill polling prior to interface start.

    commit a396e10019eaf3809b0219c966865aaafec12630 upstream.

    We need to program the rfkill switch GPIO pin direction to input at
    device initialization time, not only when the interface is brought up.
    Doing this only when the interface is brought up could lead to rfkill
    detecting the switch is turned on erroneously and inability to create
    the interface and bringing it up.

    Reported-and-tested-by: Andreas Messer <andi@bastelmap.de>
    Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d89abc3c415b30f16746ef54b75c18c7ef13f66b
Author: Gertjan van Wingerde <gwingerde@gmail.com>
Date:   Fri Aug 31 19:22:10 2012 +0200

    rt2x00: Fix word size of rt2500usb MAC_CSR19 register.

    commit 6ced58a5dbb94dbfbea1b33ca3c56d1e929cd548 upstream.

    The register is 16 bits wide, not 32.

    Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e24fd5136ca6d256900392565dfc895d5a2ed9b2
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Tue Sep 11 17:21:45 2012 +0200

    dmaengine: at_hdmac: check that each sg data length is non-null

    commit c456797681db814f4f5b36909e8e94047bf53d9c upstream.

    Avoid the construction of a malformed DMA request sent to
    the DMA controller.
    Log message is for debug only because this condition is unlikely to
    append and may only trigger at driver development time.

    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b77c2c77ade979204e5c6915c61e1d6196f70c5
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Tue Sep 11 17:21:44 2012 +0200

    dmaengine: at_hdmac: fix comment in atc_prep_slave_sg()

    commit c618a9be0e8c0f36baee2560860a0118a428fb26 upstream.

    s/dma_memcpy/slave_sg/ and it is sg length that we are
    talking about.

    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cfb6b1d3632beffef774aad1f7b906fe1934fb2
Author: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Date:   Fri Sep 14 15:36:57 2012 -0700

    cfg80211: fix possible circular lock on reg_regdb_search()

    commit a85d0d7f3460b1a123b78e7f7e39bf72c37dfb78 upstream.

    When call_crda() is called we kick off a witch hunt search
    for the same regulatory domain on our internal regulatory
    database and that work gets kicked off on a workqueue, this
    is done while the cfg80211_mutex is held. If that workqueue
    kicks off it will first lock reg_regdb_search_mutex and
    later cfg80211_mutex but to ensure two CPUs will not contend
    against cfg80211_mutex the right thing to do is to have the
    reg_regdb_search() wait until the cfg80211_mutex is let go.

    The lockdep report is pasted below.

    cfg80211: Calling CRDA to update world regulatory domain

    ======================================================
    [ INFO: possible circular locking dependency detected ]
    3.3.8 #3 Tainted: G           O
    -------------------------------------------------------
    kworker/0:1/235 is trying to acquire lock:
     (cfg80211_mutex){+.+...}, at: [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]

    but task is already holding lock:
     (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #2 (reg_regdb_search_mutex){+.+...}:
           [<800a8384>] lock_acquire+0x60/0x88
           [<802950a8>] mutex_lock_nested+0x54/0x31c
           [<81645778>] is_world_regdom+0x9f8/0xc74 [cfg80211]

    -> #1 (reg_mutex#2){+.+...}:
           [<800a8384>] lock_acquire+0x60/0x88
           [<802950a8>] mutex_lock_nested+0x54/0x31c
           [<8164539c>] is_world_regdom+0x61c/0xc74 [cfg80211]

    -> #0 (cfg80211_mutex){+.+...}:
           [<800a77b8>] __lock_acquire+0x10d4/0x17bc
           [<800a8384>] lock_acquire+0x60/0x88
           [<802950a8>] mutex_lock_nested+0x54/0x31c
           [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]

    other info that might help us debug this:

    Chain exists of:
      cfg80211_mutex --> reg_mutex#2 --> reg_regdb_search_mutex

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----
      lock(reg_regdb_search_mutex);
                                   lock(reg_mutex#2);
                                   lock(reg_regdb_search_mutex);
      lock(cfg80211_mutex);

     *** DEADLOCK ***

    3 locks held by kworker/0:1/235:
     #0:  (events){.+.+..}, at: [<80089a00>] process_one_work+0x230/0x460
     #1:  (reg_regdb_work){+.+...}, at: [<80089a00>] process_one_work+0x230/0x460
     #2:  (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]

    stack backtrace:
    Call Trace:
    [<80290fd4>] dump_stack+0x8/0x34
    [<80291bc4>] print_circular_bug+0x2ac/0x2d8
    [<800a77b8>] __lock_acquire+0x10d4/0x17bc
    [<800a8384>] lock_acquire+0x60/0x88
    [<802950a8>] mutex_lock_nested+0x54/0x31c
    [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]

    Reported-by: Felix Fietkau <nbd@openwrt.org>
    Tested-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
    Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf90cf86548beeebe5217548de6922c025372ec1
Author: Ira W. Snyder <iws@ovro.caltech.edu>
Date:   Tue Sep 11 15:58:15 2012 -0700

    can: janz-ican3: fix support for older hardware revisions

    commit e21093ef6fb4cbecdf926102286dbe280ae965db upstream.

    The Revision 1.0 Janz CMOD-IO Carrier Board does not have support for
    the reset registers. To support older hardware, the code is changed to
    use the hardware reset register on the Janz VMOD-ICAN3 hardware itself.

    Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2704f7f5dc86a8c8c3a5bdd22942f839ff556642
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Sep 19 14:58:45 2012 +0200

    can: ti_hecc: fix oops during rmmod

    commit ab04c8bd423edb03e2148350a091836c196107fc upstream.

    This patch fixes an oops which occurs when unloading the driver, while the
    network interface is still up. The problem is that first the io mapping is
    teared own, then the CAN device is unregistered, resulting in accessing the
    hardware's iomem:

    [  172.744232] Unable to handle kernel paging request at virtual address c88b0040
    [  172.752441] pgd = c7be4000
    [  172.755645] [c88b0040] *pgd=87821811, *pte=00000000, *ppte=00000000
    [  172.762207] Internal error: Oops: 807 [#1] PREEMPT ARM
    [  172.767517] Modules linked in: ti_hecc(-) can_dev
    [  172.772430] CPU: 0    Not tainted  (3.5.0alpha-00037-g3554cc0 #126)
    [  172.778961] PC is at ti_hecc_close+0xb0/0x100 [ti_hecc]
    [  172.784423] LR is at __dev_close_many+0x90/0xc0
    [  172.789123] pc : [<bf00c768>]    lr : [<c033be58>]    psr: 60000013
    [  172.789123] sp : c5c1de68  ip : 00040081  fp : 00000000
    [  172.801025] r10: 00000001  r9 : c5c1c000  r8 : 00100100
    [  172.806457] r7 : c5d0a48c  r6 : c5d0a400  r5 : 00000000  r4 : c5d0a000
    [  172.813232] r3 : c88b0000  r2 : 00000001  r1 : c5d0a000  r0 : c5d0a000
    [  172.820037] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    [  172.827423] Control: 10c5387d  Table: 87be4019  DAC: 00000015
    [  172.833404] Process rmmod (pid: 600, stack limit = 0xc5c1c2f0)
    [  172.839447] Stack: (0xc5c1de68 to 0xc5c1e000)
    [  172.843994] de60:                   bf00c6b8 c5c1dec8 c5d0a000 c5d0a000 00200200 c033be58
    [  172.852478] de80: c5c1de44 c5c1dec8 c5c1dec8 c033bf2c c5c1de90 c5c1de90 c5d0a084 c5c1de44
    [  172.860992] dea0: c5c1dec8 c033c098 c061d3dc c5d0a000 00000000 c05edf28 c05edb34 c000d724
    [  172.869476] dec0: 00000000 c033c2f8 c5d0a084 c5d0a084 00000000 c033c370 00000000 c5d0a000
    [  172.877990] dee0: c05edb00 c033c3b8 c5d0a000 bf00d3ac c05edb00 bf00d7c8 bf00d7c8 c02842dc
    [  172.886474] df00: c02842c8 c0282f90 c5c1c000 c05edb00 bf00d7c8 c0283668 bf00d7c8 00000000
    [  172.894989] df20: c0611f98 befe2f80 c000d724 c0282d10 bf00d804 00000000 00000013 c0068a8c
    [  172.903472] df40: c5c538e8 685f6974 00636365 c61571a8 c5cb9980 c61571a8 c6158a20 c00c9bc4
    [  172.911987] df60: 00000000 00000000 c5cb9980 00000000 c5cb9980 00000000 c7823680 00000006
    [  172.920471] df80: bf00d804 00000880 c5c1df8c 00000000 000d4267 befe2f80 00000001 b6d90068
    [  172.928985] dfa0: 00000081 c000d5a0 befe2f80 00000001 befe2f80 00000880 b6d90008 00000008
    [  172.937469] dfc0: befe2f80 00000001 b6d90068 00000081 00000001 00000000 befe2eac 00000000
    [  172.945983] dfe0: 00000000 befe2b18 00023ba4 b6e6addc 60000010 befe2f80 a8e00190 86d2d344
    [  172.954498] [<bf00c768>] (ti_hecc_close+0xb0/0x100 [ti_hecc]) from [<c033be58>] (__dev__registered_many+0xc0/0x2a0)
    [  172.984161] [<c033c098>] (rollback_registered_many+0xc0/0x2a0) from [<c033c2f8>] (rollback_registered+0x20/0x30)
    [  172.994750] [<c033c2f8>] (rollback_registered+0x20/0x30) from [<c033c370>] (unregister_netdevice_queue+0x68/0x98)
    [  173.005401] [<c033c370>] (unregister_netdevice_queue+0x68/0x98) from [<c033c3b8>] (unregister_netdev+0x18/0x20)
    [  173.015899] [<c033c3b8>] (unregister_netdev+0x18/0x20) from [<bf00d3ac>] (ti_hecc_remove+0x60/0x80 [ti_hecc])
    [  173.026245] [<bf00d3ac>] (ti_hecc_remove+0x60/0x80 [ti_hecc]) from [<c02842dc>] (platform_drv_remove+0x14/0x18)
    [  173.036712] [<c02842dc>] (platform_drv_remove+0x14/0x18) from [<c0282f90>] (__device_release_driver+0x7c/0xbc)

    Tested-by: Jan Luebbe <jlu@pengutronix.de>
    Cc: Anant Gole <anantgole@ti.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f3db96002cb3b4b85d5f2d37aa38c1d698074b4
Author: Søren Holm <sgh@sgh.dk>
Date:   Mon Sep 17 21:50:57 2012 +0000

    asix: Support DLink DUB-E100 H/W Ver C1

    commit ed3770a9cd5764a575b83810ea679bbff2b03082 upstream.

    Signed-off-by: Søren Holm <sgh@sgh.dk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31a4eee5e38205ba0b3c47d3e46c29d046cba89d
Author: Anisse Astier <anisse@astier.eu>
Date:   Wed Sep 19 11:10:48 2012 -0700

    Input: i8042 - disable mux on Toshiba C850D

    commit 8669cf6793bb38307a30fb6b9565ddc8840ebd3f upstream.

    On Toshiba Satellite C850D, the touchpad and the keyboard might randomly
    not work at boot. Preventing MUX mode activation solves this issue.

    Signed-off-by: Anisse Astier <anisse@astier.eu>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0869211839131f4ebe41c92f6300e1e40c77d57
Author: Wen Congyang <wency@cn.fujitsu.com>
Date:   Thu Sep 20 14:04:47 2012 +0800

    tracing: Don't call page_to_pfn() if page is NULL

    commit 85f2a2ef1d0ab99523e0b947a2b723f5650ed6aa upstream.

    When allocating memory fails, page is NULL. page_to_pfn() will
    cause the kernel panicked if we don't use sparsemem vmemmap.

    Link: http://lkml.kernel.org/r/505AB1FF.8020104@cn.fujitsu.com

    Acked-by: Mel Gorman <mel@csn.ul.ie>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Minchan Kim <minchan@kernel.org>
    Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae9973c90989ac2893398af11b02351d6d623450
Author: Matthew Leach <matthew.leach@arm.com>
Date:   Tue Sep 11 17:56:57 2012 +0100

    ARM: 7532/1: decompressor: reset SCTLR.TRE for VMSA ARMv7 cores

    commit e1e5b7e4251c7538ca08c2c5545b0c2fbd8a6635 upstream.

    This patch zeroes the SCTLR.TRE bit prior to setting the mapping as
    cacheable for ARMv7 cores in the decompressor, ensuring that the
    memory region attributes are obtained from the C and B bits, not from
    the page tables.

    Cc: Nicolas Pitre <nico@fluxnic.net>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Matthew Leach <matthew.leach@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8751608ef925da4b504643236d6e5b6961db7d9
Author: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Date:   Thu Sep 13 13:29:30 2012 +0900

    ARM: fix bad applied patch for arch/arm/Kconfig of stable 3.0.y tree.

    No upstream commit as this is a merge error in the 3.0 tree.

    ARM_ERRATA_764369 and PL310_ERRATA_769419 do not appear in config menu in
    stable 3.0.y tree.
    This is because backported patch for arm/arm/Kconfig applied wrong place.
    This patch solves it.

    Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5001e3e06b4da65f189c77c35183399cc87adf5f
Author: Toshi Kani <toshi.kani@hp.com>
Date:   Mon Aug 27 12:52:24 2012 -0600

    hpwdt: Fix kdump issue in hpwdt

    commit 308b135e4fcc00c80c07e0e04e7afa8edf78583c upstream.

    kdump can be interrupted by watchdog timer when the timer is left
    activated on the crash kernel. Changed the hpwdt driver to disable
    watchdog timer at boot-time. This assures that watchdog timer is
    disabled until /dev/watchdog is opened, and prevents watchdog timer
    to be left running on the crash kernel.

    Signed-off-by: Toshi Kani <toshi.kani@hp.com>
    Tested-by: Lisa Mitchell <lisa.mitchell@hp.com>
    Signed-off-by: Thomas Mingarelli <Thomas.Mingarelli@hp.com>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d1abc4c1f74a2c6d48217bd6874e3f12a025547
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Fri Sep 14 16:34:25 2012 -0500

    SCSI: hpsa: fix handling of protocol error

    commit 256d0eaac87da1e993190846064f339f4c7a63f5 upstream.

    If a command status of CMD_PROTOCOL_ERR is received, this
    information should be conveyed to the SCSI mid layer, not
    dropped on the floor.  CMD_PROTOCOL_ERR may be received
    from the Smart Array for any commands destined for an external
    RAID controller such as a P2000, or commands destined for tape
    drives or CD/DVD-ROM drives, if for instance a cable is
    disconnected.  This mostly affects multipath configurations, as
    disconnecting a cable on a non-multipath configuration is not
    going to do anything good regardless of whether CMD_PROTOCOL_ERR
    is handled correctly or not.  Not handling CMD_PROTOCOL_ERR
    correctly in a multipath configaration involving external RAID
    controllers may cause data corruption, so this is quite a serious
    bug.  This bug should not normally cause a problem for direct
    attached disk storage.

    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 880d7a7bbe89120cd9d17590bec160ad11b03ca0
Author: Eddie Wai <eddie.wai@broadcom.com>
Date:   Tue Aug 21 10:35:53 2012 -0700

    SCSI: bnx2i: Fixed NULL ptr deference for 1G bnx2 Linux iSCSI offload

    commit d6532207116307eb7ecbfa7b9e02c53230096a50 upstream.

    This patch fixes the following kernel panic invoked by uninitialized fields
    in the chip initialization for the 1G bnx2 iSCSI offload.

    One of the bits in the chip initialization is being used by the latest
    firmware to control overflow packets.  When this control bit gets enabled
    erroneously, it would ultimately result in a bad packet placement which would
    cause the bnx2 driver to dereference a NULL ptr in the placement handler.

    This can happen under certain stress I/O environment under the Linux
    iSCSI offload operation.

    This change only affects Broadcom's 5709 chipset.

    Unable to handle kernel NULL pointer dereference at 0000000000000008 RIP:
     [<ffffffff881f0e7d>] :bnx2:bnx2_poll_work+0xd0d/0x13c5
    Pid: 0, comm: swapper Tainted: G     ---- 2.6.18-333.el5debug #2
    RIP: 0010:[<ffffffff881f0e7d>]  [<ffffffff881f0e7d>] :bnx2:bnx2_poll_work+0xd0d/0x13c5
    RSP: 0018:ffff8101b575bd50  EFLAGS: 00010216
    RAX: 0000000000000005 RBX: ffff81007c5fb180 RCX: 0000000000000000
    RDX: 0000000000000ffc RSI: 00000000817e8000 RDI: 0000000000000220
    RBP: ffff81015bbd7ec0 R08: ffff8100817e9000 R09: 0000000000000000
    R10: ffff81007c5fb180 R11: 00000000000000c8 R12: 000000007a25a010
    R13: 0000000000000000 R14: 0000000000000005 R15: ffff810159f80558
    FS:  0000000000000000(0000) GS:ffff8101afebc240(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000008 CR3: 0000000000201000 CR4: 00000000000006a0
    Process swapper (pid: 0, threadinfo ffff8101b5754000, task ffff8101afebd820)
    Stack:  000000000000000b ffff810159f80000 0000000000000040 ffff810159f80520
     ffff810159f80500 00cf00cf8008e84b ffffc200100939e0 ffff810009035b20
     0000502900000000 000000be00000001 ffff8100817e7810 00d08101b575bea8
    Call Trace:
     <IRQ>  [<ffffffff8008e0d0>] show_schedstat+0x1c2/0x25b
     [<ffffffff881f1886>] :bnx2:bnx2_poll+0xf6/0x231
     [<ffffffff8000c9b9>] net_rx_action+0xac/0x1b1
     [<ffffffff800125a0>] __do_softirq+0x89/0x133
     [<ffffffff8005e30c>] call_softirq+0x1c/0x28
     [<ffffffff8006d5de>] do_softirq+0x2c/0x7d
     [<ffffffff8006d46e>] do_IRQ+0xee/0xf7
     [<ffffffff8005d625>] ret_from_intr+0x0/0xa
     <EOI>  [<ffffffff801a5780>] acpi_processor_idle_simple+0x1c5/0x341
     [<ffffffff801a573d>] acpi_processor_idle_simple+0x182/0x341
     [<ffffffff801a55bb>] acpi_processor_idle_simple+0x0/0x341
     [<ffffffff80049560>] cpu_idle+0x95/0xb8
     [<ffffffff80078b1c>] start_secondary+0x479/0x488

    Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
    Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9772793ce1e36cae113b1bc97451700c08cef906
Author: sreekanth.reddy@lsi.com <sreekanth.reddy@lsi.com>
Date:   Wed Aug 22 16:55:13 2012 +0530

    SCSI: mpt2sas: Fix for issue - Unable to boot from the drive connected to HBA

    commit 10cce6d8b5af0b32bc4254ae4a28423a74c0921c upstream.

    This patch checks whether HBA is SAS2008 B0 controller.
    if it is a SAS2008 B0 controller then it use IO-APIC interrupt instead of MSIX,
    as SAS2008 B0 controller doesn't support MSIX interrupts.

    [jejb: fix whitespace problems]
    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0871df8f1c83eaa4c97f402a39809a66ba63373
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Sep 11 13:39:08 2012 -0700

    hwmon: (ads7871) Add 'name' sysfs attribute

    commit 4e21f4eaa49f78d3e977e316514c941053871c76 upstream.

    The 'name' sysfs attribute is mandatory for hwmon devices, but was missing
    in this driver.

    Cc: Paul Thomas <pthomas8589@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Paul Thomas <pthomas8589@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe7e822c7b55d55cf2b1367d5a01d4ac254bb2f2
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Sun Sep 23 20:27:32 2012 +0200

    hwmon: (fam15h_power) Tweak runavg_range on resume

    commit 5f0ecb907deb1e6f28071ee3bd568903b9da1be4 upstream.

    The quirk introduced with commit
    00250ec90963b7ef6678438888f3244985ecde14 (hwmon: fam15h_power: fix
    bogus values with current BIOSes) is not only required during driver
    load but also when system resumes from suspend. The BIOS might set the
    previously recommended (but unsuitable) initilization value for the
    running average range register during resume.

    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Tested-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d83fc0bb961f8b4775b30bcee27fe9721da8400c
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Aug 17 10:22:37 2012 -0400

    xen/boot: Disable NUMA for PV guests.

    commit 8d54db795dfb1049d45dc34f0dddbc5347ec5642 upstream.

    The hypervisor is in charge of allocating the proper "NUMA" memory
    and dealing with the CPU scheduler to keep them bound to the proper
    NUMA node. The PV guests (and PVHVM) have no inkling of where they
    run and do not need to know that right now. In the future we will
    need to inject NUMA configuration data (if a guest spans two or more
    NUMA nodes) so that the kernel can make the right choices. But those
    patches are not yet present.

    In the meantime, disable the NUMA capability in the PV guest, which
    also fixes a bootup issue. Andre says:

    "we see Dom0 crashes due to the kernel detecting the NUMA topology not
    by ACPI, but directly from the northbridge (CONFIG_AMD_NUMA).

    This will detect the actual NUMA config of the physical machine, but
    will crash about the mismatch with Dom0's virtual memory. Variation of
    the theme: Dom0 sees what it's not supposed to see.

    This happens with the said config option enabled and on a machine where
    this scanning is still enabled (K8 and Fam10h, not Bulldozer class)

    We have this dump then:
    NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10
    Scanning NUMA topology in Northbridge 24
    Number of physical nodes 4
    Node 0 MemBase 0000000000000000 Limit 0000000040000000
    Node 1 MemBase 0000000040000000 Limit 0000000138000000
    Node 2 MemBase 0000000138000000 Limit 00000001f8000000
    Node 3 MemBase 00000001f8000000 Limit 0000000238000000
    Initmem setup node 0 0000000000000000-0000000040000000
      NODE_DATA [000000003ffd9000 - 000000003fffffff]
    Initmem setup node 1 0000000040000000-0000000138000000
      NODE_DATA [0000000137fd9000 - 0000000137ffffff]
    Initmem setup node 2 0000000138000000-00000001f8000000
      NODE_DATA [00000001f095e000 - 00000001f0984fff]
    Initmem setup node 3 00000001f8000000-0000000238000000
    Cannot find 159744 bytes in node 3
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
    Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar
    RIP: e030:[<ffffffff81d220e6>]  [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
    .. snip..
      [<ffffffff81d23024>] sparse_early_usemaps_alloc_node+0x64/0x178
      [<ffffffff81d23348>] sparse_init+0xe4/0x25a
      [<ffffffff81d16840>] paging_init+0x13/0x22
      [<ffffffff81d07fbb>] setup_arch+0x9c6/0xa9b
      [<ffffffff81683954>] ? printk+0x3c/0x3e
      [<ffffffff81d01a38>] start_kernel+0xe5/0x468
      [<ffffffff81d012cf>] x86_64_start_reservations+0xba/0xc1
      [<ffffffff81007153>] ? xen_setup_runstate_info+0x2c/0x36
      [<ffffffff81d050ee>] xen_start_kernel+0x565/0x56c
    "

    so we just disable NUMA scanning by setting numa_off=1.

    Reported-and-Tested-by: Andre Przywara <andre.przywara@amd.com>
    Acked-by: Andre Przywara <andre.przywara@amd.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2aab4667576b39a1cba50b0322da6d21bbdfc9dd
Author: qiuxishi <qiuxishi@gmail.com>
Date:   Mon Sep 17 14:09:24 2012 -0700

    memory hotplug: fix section info double registration bug

    commit f14851af0ebb32745c6c5a2e400aa0549f9d20df upstream.

    There may be a bug when registering section info.  For example, on my
    Itanium platform, the pfn range of node0 includes the other nodes, so
    other nodes' section info will be double registered, and memmap's page
    count will equal to 3.

      node0: start_pfn=0x100,    spanned_pfn=0x20fb00, present_pfn=0x7f8a3, => 0x000100-0x20fc00
      node1: start_pfn=0x80000,  spanned_pfn=0x80000,  present_pfn=0x80000, => 0x080000-0x100000
      node2: start_pfn=0x100000, spanned_pfn=0x80000,  present_pfn=0x80000, => 0x100000-0x180000
      node3: start_pfn=0x180000, spanned_pfn=0x80000,  present_pfn=0x80000, => 0x180000-0x200000

      free_all_bootmem_node()
    	register_page_bootmem_info_node()
    		register_page_bootmem_info_section()

    When hot remove memory, we can't free the memmap's page because
    page_count() is 2 after put_page_bootmem().

      sparse_remove_one_section()
    	free_section_usemap()
    		free_map_bootmem()
    			put_page_bootmem()

    [akpm@linux-foundation.org: add code comment]
    Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: "Luck, Tony" <tony.luck@intel.com>
    Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.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 0f8c1df34ab4a2796724e9a2217b803547346628
Author: Jianguo Wu <wujianguo@huawei.com>
Date:   Mon Sep 17 14:08:56 2012 -0700

    mm/ia64: fix a memory block size bug

    commit 05cf96398e1b6502f9e191291b715c7463c9d5dd upstream.

    I found following definition in include/linux/memory.h, in my IA64
    platform, SECTION_SIZE_BITS is equal to 32, and MIN_MEMORY_BLOCK_SIZE
    will be 0.

      #define MIN_MEMORY_BLOCK_SIZE     (1 << SECTION_SIZE_BITS)

    Because MIN_MEMORY_BLOCK_SIZE is int type and length of 32bits,
    so MIN_MEMORY_BLOCK_SIZE(1 << 32) will will equal to 0.
    Actually when SECTION_SIZE_BITS >= 31, MIN_MEMORY_BLOCK_SIZE will be wrong.
    This will cause wrong system memory infomation in sysfs.
    I think it should be:

      #define MIN_MEMORY_BLOCK_SIZE     (1UL << SECTION_SIZE_BITS)

    And "echo offline > memory0/state" will cause following call trace:

      kernel BUG at mm/memory_hotplug.c:885!
      sh[6455]: bugcheck! 0 [1]
      Pid: 6455, CPU 0, comm:                   sh
      psr : 0000101008526030 ifs : 8000000000000fa4 ip  : [<a0000001008c40f0>]    Not tainted (3.6.0-rc1)
      ip is at offline_pages+0x210/0xee0
      Call Trace:
        show_stack+0x80/0xa0
        show_regs+0x640/0x920
        die+0x190/0x2c0
        die_if_kernel+0x50/0x80
        ia64_bad_break+0x3d0/0x6e0
        ia64_native_leave_kernel+0x0/0x270
        offline_pages+0x210/0xee0
        alloc_pages_current+0x180/0x2a0

    Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Cc: "Luck, Tony" <tony.luck@intel.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    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 9680ec7a46f19fd9b143adc8c69493834f450eee
Author: Benoît Locher <Benoit.Locher@skf.com>
Date:   Mon Aug 27 15:02:45 2012 +0200

    can: mcp251x: avoid repeated frame bug

    commit cab32f39dcc5b35db96497dc0a026b5dea76e4e7 upstream.

    The MCP2515 has a silicon bug causing repeated frame transmission, see section
    5 of MCP2515 Rev. B Silicon Errata Revision G (March 2007).

    Basically, setting TXBnCTRL.TXREQ in either SPI mode (00 or 11) will eventually
    cause the bug. The workaround proposed by Microchip is to use mode 00 and send
    a RTS command on the SPI bus to initiate the transmission.

    Signed-off-by: Benoît Locher <Benoit.Locher@skf.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc2f6ff9239c013e9ad1ff5a64b86d85d7fc4a3f
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Jun 19 08:00:00 2012 -0700

    hwmon: (twl4030-madc-hwmon) Initialize uninitialized structure elements

    commit 73d7c119255615a26070f9d6cdb722a166a29015 upstream.

    twl4030_madc_conversion uses do_avg and type structure elements of
    twl4030_madc_request. Initialize structure to avoid random operation.

    Fix for: Coverity CID 200794 Uninitialized scalar variable.

    Cc: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d344b6d390854d7c5774e550171b75db50a330fe
Author: Kevin Hilman <khilman@ti.com>
Date:   Mon Sep 17 14:09:17 2012 -0700

    drivers/rtc/rtc-twl.c: ensure all interrupts are disabled during probe

    commit 8dcebaa9a0ae8a0487f4342f3d56d2cb1c980860 upstream.

    On some platforms, bootloaders are known to do some interesting RTC
    programming.  Without going into the obscurities as to why this may be
    the case, suffice it to say the the driver should not make any
    assumptions about the state of the RTC when the driver loads.  In
    particular, the driver probe should be sure that all interrupts are
    disabled until otherwise programmed.

    This was discovered when finding bursty I2C traffic every second on
    Overo platforms.  This I2C overhead was keeping the SoC from hitting
    deep power states.  The cause was found to be the RTC firing every
    second on the I2C-connected TWL PMIC.

    Special thanks to Felipe Balbi for suggesting to look for a rogue driver
    as the source of the I2C traffic rather than the I2C driver itself.

    Special thanks to Steve Sakoman for helping track down the source of the
    continuous RTC interrups on the Overo boards.

    Signed-off-by: Kevin Hilman <khilman@ti.com>
    Cc: Felipe Balbi <balbi@ti.com>
    Tested-by: Steve Sakoman <steve@sakoman.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Tested-by: Shubhrajyoti Datta <omaplinuxkernel@gmail.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 54fd21ca117a5dd36a1bf7e0b92bef2c89c2201e
Author: Li Haifeng <omycle@gmail.com>
Date:   Mon Sep 17 14:09:21 2012 -0700

    mm/page_alloc: fix the page address of higher page's buddy calculation

    commit 0ba8f2d59304dfe69b59c034de723ad80f7ab9ac upstream.

    The heuristic method for buddy has been introduced since commit
    43506fad21ca ("mm/page_alloc.c: simplify calculation of combined index
    of adjacent buddy lists").  But the page address of higher page's buddy
    was wrongly calculated, which will lead page_is_buddy to fail for ever.
    IOW, the heuristic method would be disabled with the wrong page address
    of higher page's buddy.

    Calculating the page address of higher page's buddy should be based
    higher_page with the offset between index of higher page and index of
    higher page's buddy.

    Signed-off-by: Haifeng Li <omycle@gmail.com>
    Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: KyongHo Cho <pullip.cho@samsung.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Johannes Weiner <jweiner@redhat.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 f2657804a840a7c5ed60b9a96c8e81e845579a25
Author: NeilBrown <neilb@suse.de>
Date:   Thu Aug 16 16:46:12 2012 +1000

    md: Don't truncate size at 4TB for RAID0 and Linear

    commit 667a5313ecd7308d79629c0738b0db588b0b0a4e upstream.

    commit 27a7b260f71439c40546b43588448faac01adb93
       md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.

    changed 0.90 metadata handling to truncated size to 4TB as that is
    all that 0.90 can record.
    However for RAID0 and Linear, 0.90 doesn't need to record the size, so
    this truncation is not needed and causes working arrays to become too small.

    So avoid the truncation for RAID0 and Linear

    This bug was introduced in 3.1 and is suitable for any stable kernels
    from then onwards.
    As the offending commit was tagged for 'stable', any stable kernel
    that it was applied to should also get this patch.  That includes
    at least 2.6.32, 2.6.33 and 3.0. (Thanks to Ben Hutchings for
    providing that list).

    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e5369da75bc02e9e0bfdd5c1bb64a70021f1d8b
Author: Mel Gorman <mgorman@suse.de>
Date:   Sun Aug 19 14:41:03 2012 +1200

    Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

    commit 67a806d9499353fabd5b5ff07337f3aa88a1c3ba upstream.

    The following build error occurred during an alpha build:

      net/core/sock.c:274:36: error: initializer element is not constant

    Dave Anglin says:
    > Here is the line in sock.i:
    >
    > struct static_key memalloc_socks = ((struct static_key) { .enabled =
    > ((atomic_t) { (0) }) });

    The above line contains two compound literals.  It also uses a designated
    initializer to initialize the field enabled.  A compound literal is not a
    constant expression.

    The location of the above statement isn't fully clear, but if a compound
    literal occurs outside the body of a function, the initializer list must
    consist of constant expressions.

    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Michael Cree <mcree@orcon.net.nz>
    Acked-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8ec0c2008088108f6d4919ed2013bbca1651d13
Author: Bjørn Mork <bjorn@mork.no>
Date:   Sun Sep 2 15:41:34 2012 +0200

    kobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()"

    commit 60e233a56609fd963c59e99bd75c663d63fa91b6 upstream.

    Fengguang Wu <fengguang.wu@intel.com> writes:

    > After the __devinit* removal series, I can still get kernel panic in
    > show_uevent(). So there are more sources of bug..
    >
    > Debug patch:
    >
    > @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
    >                 goto out;
    >
    >         /* copy keys to file */
    > -       for (i = 0; i < env->envp_idx; i++)
    > +       dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name);
    > +       for (i = 0; i < env->envp_idx; i++) {
    > +               printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]);
    >                 count += sprintf(&buf[count], "%s\n", env->envp[i]);
    > +       }
    >
    > Oops message, the env[] is again not properly initilized:
    >
    > [   44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
    > [   44.069552] uevent 0 env[0]: (null)

    This is a completely different CONFIG_HOTPLUG problem, only
    demonstrating another reason why CONFIG_HOTPLUG should go away.  I had a
    hard time trying to disable it anyway ;-)

    The problem this time is lots of code assuming that a call to
    add_uevent_var() will guarantee that env->buflen > 0.  This is not true
    if CONFIG_HOTPLUG is unset.  So things like this end up overwriting
    env->envp_idx because the array index is -1:

    	if (add_uevent_var(env, "MODALIAS="))
    		return -ENOMEM;
            len = input_print_modalias(&env->buf[env->buflen - 1],
    				   sizeof(env->buf) - env->buflen,
    				   dev, 0);

    Don't know what the best action is, given that there seem to be a *lot*
    of this around the kernel.  This patch "fixes" the problem for me, but I
    don't know if it can be considered an appropriate fix.

    [ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
    always be on is the longterm fix, but it's too late for 3.6 and older
    kernels to resolve this that way - gregkh ]

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad0b57d5fc1e7ce32e8d693ae0b8ea6df3eb63b3
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue Sep 4 16:07:18 2012 +0100

    ahci: Add alternate identifier for the 88SE9172

    commit 17c60c6b763cb5b83b0185e7d38d01d18e55a05a upstream.

    This can also appear as 0x9192. Reported in bugzilla and confirmed with the
    board documentation for these boards.

    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42970
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0afe8813641fda8e31a24add2f753488a8dd7c8a
Author: Shawn Guo <shawn.guo@linaro.org>
Date:   Wed Aug 22 23:10:01 2012 +0800

    mmc: sdhci-esdhc: break out early if clock is 0

    commit 74f330bceaa7b88d06062e1cac3d519a3dfc041e upstream.

    Since commit 30832ab56 ("mmc: sdhci: Always pass clock request value
    zero to set_clock host op") was merged, esdhc_set_clock starts hitting
    "if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated.  This
    causes SDHCI card-detection function being broken.  Fix the regression
    by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation.

    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2df2bfdbb4136e7051d12787dd2966cffc2a0eaa
Author: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Date:   Tue Jul 17 17:16:09 2012 +0300

    mmc: mxs-mmc: fix deadlock in SDIO IRQ case

    commit 1af36b2a993dddfa3d6860ec4879c9e8abc9b976 upstream.

    Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler.

    Backtrace:
    [   79.660000] =============================================
    [   79.660000] [ INFO: possible recursive locking detected ]
    [   79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted
    [   79.660000] ---------------------------------------------
    [   79.660000] swapper/0 is trying to acquire lock:
    [   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4
    [   79.660000]
    [   79.660000] but task is already holding lock:
    [   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
    [   79.660000]
    [   79.660000] other info that might help us debug this:
    [   79.660000]  Possible unsafe locking scenario:
    [   79.660000]
    [   79.660000]        CPU0
    [   79.660000]        ----
    [   79.660000]   lock(&(&host->lock)->rlock#2);
    [   79.660000]   lock(&(&host->lock)->rlock#2);
    [   79.660000]
    [   79.660000]  *** DEADLOCK ***
    [   79.660000]
    [   79.660000]  May be due to missing lock nesting notation
    [   79.660000]
    [   79.660000] 1 lock held by swapper/0:
    [   79.660000]  #0:  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
    [   79.660000]
    [   79.660000] stack backtrace:
    [   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48)
    [   79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8)
    [   79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58)
    [   79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
    [   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
    [   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
    [   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
    [   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
    [   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
    [   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
    [   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
    [   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
    [   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
    [   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
    [   79.660000] BUG: spinlock lockup on CPU#0, swapper/0
    [   79.660000]  lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
    [   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144)
    [   79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58)
    [   79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
    [   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
    [   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
    [   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
    [   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
    [   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
    [   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
    [   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
    [   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
    [   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
    [   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)

    Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71f08eb07187bb598e7da95d46458478846efc72
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Mon Aug 20 14:59:25 2012 +0100

    perf_event: Switch to internal refcount, fix race with close()

    commit a6fa941d94b411bbd2b6421ffbde6db3c93e65ab upstream.

    Don't mess with file refcounts (or keep a reference to file, for
    that matter) in perf_event.  Use explicit refcount of its own
    instead.  Deal with the race between the final reference to event
    going away and new children getting created for it by use of
    atomic_long_inc_not_zero() in inherit_event(); just have the
    latter free what it had allocated and return NULL, that works
    out just fine (children of siblings of something doomed are
    created as singletons, same as if the child of leader had been
    created and immediately killed).

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120820135925.GG23464@ZenIV.linux.org.uk
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d982d2f4e90cc354b5428d8d951784e0a3007bf3
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Sep 11 09:40:31 2012 +0200

    USB: option: replace ZTE K5006-Z entry with vendor class rule

    commit ba9edaa468869a8cea242a411066b0f490751798 upstream.

    Fix the ZTE K5006-Z entry so that it actually matches anything

      commit f1b5c997 USB: option: add ZTE K5006-Z

    added a device specific entry assuming that the device would use
    class/subclass/proto == ff/ff/ff like other ZTE devices. It
    turns out that ZTE has started using vendor specific subclass
    and protocol codes:

    T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=1018 Rev= 0.00
    S:  Manufacturer=ZTE,Incorporated
    S:  Product=ZTE LTE Technologies MSM
    S:  SerialNumber=MF821Vxxxxxxx
    C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none)
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none)
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan
    E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

    We do not have any information on how ZTE intend to use these
    codes, but let us assume for now that the 3 sets matching
    serial functions in the K5006-Z always will identify a serial
    function in a ZTE device.

    Cc: Thomas Schäfer <tschaefer@t-online.de>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b004f11dd710379a31fa09ce22843b52e6f78a13
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Fri Aug 31 20:41:30 2012 +0100

    staging: comedi: das08: Correct AO output for das08jr-16-ao

    commit 61ed59ed09e6ad2b8395178ea5ad5f653bba08e3 upstream.

    Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as
    that knobbles the upper three-quarters of the output range for the
    'das08jr-16-ao' board.

    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bdec51f7538d80268f35139bbb29b3ae2cb19e9
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Sep 10 21:22:11 2012 +0200

    staging: r8712u: fix bug in r8712_recv_indicatepkt()

    commit abf02cfc179bb4bd30d05f582d61b3b8f429b813 upstream.

    64bit arches have a buggy r8712u driver, let's fix it.

    skb->tail must be set properly or network stack behavior is undefined.

    Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525
    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Dave Jones <davej@redhat.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef7d68b798f01cb37a7cc2204b94ae139896eaae
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Wed Aug 29 23:08:21 2012 +0100

    staging: vt6656: [BUG] - Failed connection, incorrect endian.

    commit aa209eef3ce8419ff2926c2fa944dfbfb5afbacb upstream.

    Hi,

    This patch fixes a bug with driver failing to negotiate a connection.

    The bug was traced to commit
    203e4615ee9d9fa8d3506b9d0ef30095e4d5bc90
    staging: vt6656: removed custom definitions of Ethernet packet types

    In that patch, definitions in include/linux/if_ether.h replaced ones
    in tether.h which had both big and little endian definitions.

    include/linux/if_ether.h only refers to big endian values, cpu_to_be16
    should be used for the correct endian architectures.

    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 274fca52f11e2a4e911b5868ccc3e1659b403e5e
Author: Christopher Brannon <chris@the-brannons.com>
Date:   Sat Jun 16 16:55:20 2012 -0500

    Staging: speakup: fix an improperly-declared variable.

    commit 4ea418b8b2fa8a70d0fcc8231b65e67b3a72984b upstream.

    A local static variable was declared as a pointer to a string
    constant.  We're assigning to the underlying memory, so it
    needs to be an array instead.

    Signed-off-by: Christopher Brannon <chris@the-brannons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c820f129c9afffb0ecb74312123535a303197875
Author: Matteo Frigo <athena@fftw.org>
Date:   Wed Sep 12 10:12:06 2012 -0400

    ALSA: ice1724: Use linear scale for AK4396 volume control.

    commit 3737e2be505d872bf2b3c1cd4151b2d2b413d7b5 upstream.

    The AK4396 DAC has a linear-scale attentuator, but
    sound/pci/ice1712/prodigy_hifi.c used a log scale instead, which is
    not quite right.  This patch restores the correct scale, borrowing
    from the ak4396 code in sound/pci/oxygen/oxygen.c.

    Signed-off-by: Matteo Frigo <athena@fftw.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3653afefd005d16274c9f16511530de3d511c1a
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Aug 16 15:33:10 2012 -0700

    target: Fix ->data_length re-assignment bug with SCSI overflow

    commit 4c054ba63ad47ef244cfcfa1cea38134620a5bae upstream.

    This patch fixes a long-standing bug with SCSI overflow handling
    where se_cmd->data_length was incorrectly being re-assigned to
    the larger CDB extracted allocation length, resulting in a number
    of fabric level errors that would end up causing a session reset
    in most cases.  So instead now:

     - Only re-assign se_cmd->data_length durining UNDERFLOW (to use the
       smaller value)
     - Use existing se_cmd->data_length for OVERFLOW (to use the smaller
       value)

    This fix has been tested with the following CDB to generate an
    SCSI overflow:

      sg_raw -r512 /dev/sdc 28 0 0 0 0 0 0 0 9 0

    Tested using iscsi-target, tcm_qla2xxx, loopback and tcm_vhost fabric
    ports.  Here is a bit more detail on each case:

     - iscsi-target: Bug with open-iscsi with overflow, sg_raw returns
                     -3584 bytes of data.
     - tcm_qla2xxx: Working as expected, returnins 512 bytes of data
     - loopback: sg_raw returns CHECK_CONDITION, from overflow rejection
                 in transport_generic_map_mem_to_cmd()
     - tcm_vhost: Same as loopback

    Reported-by: Roland Dreier <roland@purestorage.com>
    Cc: Roland Dreier <roland@purestorage.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 047b8d01518246de438ba76a957889b6e661638e
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Thu Sep 13 12:00:56 2012 -0700

    eCryptfs: Copy up attributes of the lower target inode after rename

    commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a upstream.

    After calling into the lower filesystem to do a rename, the lower target
    inode's attributes were not copied up to the eCryptfs target inode. This
    resulted in the eCryptfs target inode staying around, rather than being
    evicted, because i_nlink was not updated for the eCryptfs inode. This
    also meant that eCryptfs didn't do the final iput() on the lower target
    inode so it stayed around, as well. This would result in a failure to
    free up space occupied by the target file in the rename() operation.
    Both target inodes would eventually be evicted when the eCryptfs
    filesystem was unmounted.

    This patch calls fsstack_copy_attr_all() after the lower filesystem
    does its ->rename() so that important inode attributes, such as i_nlink,
    are updated at the eCryptfs layer. ecryptfs_evict_inode() is now called
    and eCryptfs can drop its final reference on the lower inode.

    http://launchpad.net/bugs/561129

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Tested-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0b5cee7c407680ffb2805e47d8c896cdae988b0
Author: Amerigo Wang <amwang@redhat.com>
Date:   Sat Aug 18 07:02:20 2012 +0000

    netconsole: remove a redundant netconsole_target_put()

    commit 72d3eb13b5c0abe7d63efac41f39c5b644c7bbaa upstream.

    This netconsole_target_put() is obviously redundant, and it
    causes a kernel segfault when removing a bridge device which has
    netconsole running on it.

    This is caused by:

    	commit 8d8fc29d02a33e4bd5f4fa47823c1fd386346093
    	Author: Amerigo Wang <amwang@redhat.com>
    	Date:   Thu May 19 21:39:10 2011 +0000

    	    netpoll: disable netpoll when enslave a device

    Signed-off-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b2b69f4e7a4cd7768323f84f17f09ab608e620d
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Mon Sep 17 22:31:38 2012 +0200

    vfs: dcache: use DCACHE_DENTRY_KILLED instead of DCACHE_DISCONNECTED in d_kill()

    commit b161dfa6937ae46d50adce8a7c6b12233e96e7bd upstream.

    IBM reported a soft lockup after applying the fix for the rename_lock
    deadlock.  Commit c83ce989cb5f ("VFS: Fix the nfs sillyrename regression
    in kernel 2.6.38") was found to be the culprit.

    The nfs sillyrename fix used DCACHE_DISCONNECTED to indicate that the
    dentry was killed.  This flag can be set on non-killed dentries too,
    which results in infinite retries when trying to traverse the dentry
    tree.

    This patch introduces a separate flag: DCACHE_DENTRY_KILLED, which is
    only set in d_kill() and makes try_to_ascend() test only this flag.

    IBM reported successful test results with this patch.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c168d49dbb4bc6cbd58b855166e5f98585479307
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 14 14:48:21 2012 -0700

    vfs: make O_PATH file descriptors usable for 'fstat()'

    commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 upstream.

    We already use them for openat() and friends, but fstat() also wants to
    be able to use O_PATH file descriptors.  This should make it more
    directly comparable to the O_SEARCH of Solaris.

    Note that you could already do the same thing with "fstatat()" and an
    empty path, but just doing "fstat()" directly is simpler and faster, so
    there is no reason not to just allow it directly.

    See also commit 332a2e1244bd, which did the same thing for fchdir, for
    the same reasons.

    Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf8d67a69224bc2fbc6bc395cf639a9b0652c8e3
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Fri Sep 14 16:35:10 2012 -0500

    cciss: fix handling of protocol error

    commit 2453f5f992717251cfadab6184fbb3ec2f2e8b40 upstream.

    If a command completes with a status of CMD_PROTOCOL_ERR, this
    information should be conveyed to the SCSI mid layer, not dropped
    on the floor.  Unlike a similar bug in the hpsa driver, this bug
    only affects tape drives and CD and DVD ROM drives in the cciss
    driver, and to induce it, you have to disconnect (or damage) a
    cable, so it is not a very likely scenario (which would explain
    why the bug has gone undetected for the last 10 years.)

    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b1785ad00ad1b809a4a224499ed605f2eb516fa
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Sep 18 14:24:59 2012 -0700

    cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU

    commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9 upstream.

    powernowk8_target() runs off a per-cpu work item and if the
    cpufreq_policy->cpu is different from the current one, it migrates the
    kworker to the target CPU by manipulating current->cpus_allowed.  The
    function migrates the kworker back to the original CPU but this is
    still broken.  Workqueue concurrency management requires the kworkers
    to stay on the same CPU and powernowk8_target() ends up triggerring
    BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
    fidvid_mutex and sleeps.

    It is unclear why this bug is being reported now.  Duncan says it
    appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
    3.5.  Bisection seemed to point to 63d95a91 "workqueue: use @pool
    instead of @gcwq or @cpu where applicable" which is an non-functional
    change.  Given that the reproduce case sometimes took upto days to
    trigger, it's easy to be misled while bisecting.  Maybe something made
    contention on fidvid_mutex more likely?  I don't know.

    This patch fixes the bug by using work_on_cpu() instead if @pol->cpu
    isn't the same as the current one.  The code assumes that
    cpufreq_policy->cpu is kept online by the caller, which Rafael tells
    me is the case.

    stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using
            system_wq") should be applied before this; otherwise, the
            behavior could be horrible.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Duncan <1i5t5.duncan@cox.net>
    Tested-by: Duncan <1i5t5.duncan@cox.net>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d45db6b5158a7f09f8be651577416ef6a4dcbd4
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Sep 18 12:48:43 2012 -0700

    workqueue: reimplement work_on_cpu() using system_wq

    commit ed48ece27cd3d5ee0354c32bbaec0f3e1d4715c3 upstream.

    The existing work_on_cpu() implementation is hugely inefficient.  It
    creates a new kthread, execute that single function and then let the
    kthread die on each invocation.

    Now that system_wq can handle concurrent executions, there's no
    advantage of doing this.  Reimplement work_on_cpu() using system_wq
    which makes it simpler and way more efficient.

    stable: While this isn't a fix in itself, it's needed to fix a
            workqueue related bug in cpufreq/powernow-k8.  AFAICS, this
            shouldn't break other existing users.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Len Brown <lenb@kernel.org>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 896b6af471f67fc60cbab5a503cb8a764a8c47a4
Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date:   Fri Aug 24 07:38:35 2012 +0000

    net: ipv4: ipmr_expire_timer causes crash when removing net namespace

    [ Upstream commit acbb219d5f53821b2d0080d047800410c0420ea1 ]

    When tearing down a net namespace, ipv4 mr_table structures are freed
    without first deactivating their timers. This can result in a crash in
    run_timer_softirq.
    This patch mimics the corresponding behaviour in ipv6.
    Locking and synchronization seem to be adequate.
    We are about to kfree mrt, so existing code should already make sure that
    no other references to mrt are pending or can be created by incoming traffic.
    The functions invoked here do not cause new references to mrt or other
    race conditions to be created.
    Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive.
    Both ipmr_expire_process (whose completion we may have to wait in
    del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock
    or other synchronizations when needed, and they both only modify mrt.

    Tested in Linux 3.4.8.

    Signed-off-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 928863a39f0ee47af97e7e17b909334dcb06cf1e
Author: xeb@mail.ru <xeb@mail.ru>
Date:   Fri Aug 24 01:07:38 2012 +0000

    l2tp: avoid to use synchronize_rcu in tunnel free function

    [ Upstream commit 99469c32f79a32d8481f87be0d3c66dad286f4ec ]

    Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
    atomic.

    Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8df5b8a9dec89726e6bf8a2073c72a533c6d0c5
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Aug 23 02:09:11 2012 +0000

    netlink: fix possible spoofing from non-root processes

    [ Upstream commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef ]

    Non-root user-space processes can send Netlink messages to other
    processes that are well-known for being subscribed to Netlink
    asynchronous notifications. This allows ilegitimate non-root
    process to send forged messages to Netlink subscribers.

    The userspace process usually verifies the legitimate origin in
    two ways:

    a) Socket credentials. If UID != 0, then the message comes from
       some ilegitimate process and the message needs to be dropped.

    b) Netlink portID. In general, portID == 0 means that the origin
       of the messages comes from the kernel. Thus, discarding any
       message not coming from the kernel.

    However, ctnetlink sets the portID in event messages that has
    been triggered by some user-space process, eg. conntrack utility.
    So other processes subscribed to ctnetlink events, eg. conntrackd,
    know that the event was triggered by some user-space action.

    Neither of the two ways to discard ilegitimate messages coming
    from non-root processes can help for ctnetlink.

    This patch adds capability validation in case that dst_pid is set
    in netlink_sendmsg(). This approach is aggressive since existing
    applications using any Netlink bus to deliver messages between
    two user-space processes will break. Note that the exception is
    NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
    userspace communication.

    Still, if anyone wants that his Netlink bus allows netlink-to-netlink
    userspace, then they can set NL_NONROOT_SEND. However, by default,
    I don't think it makes sense to allow to use NETLINK_ROUTE to
    communicate two processes that are sending no matter what information
    that is not related to link/neighbouring/routing. They should be using
    NETLINK_USERSOCK instead for that.

    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a62b446c607d994f82a578bbca5995a0aa0183d
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:57 2012 +0000

    net: fix info leak in compat dev_ifconf()

    [ Upstream commit 43da5f2e0d0c69ded3d51907d9552310a6b545e8 ]

    The implementation of dev_ifconf() for the compat ioctl interface uses
    an intermediate ifc structure allocated in userland for the duration of
    the syscall. Though, it fails to initialize the padding bytes inserted
    for alignment and that for leaks four bytes of kernel stack. Add an
    explicit memset(0) before filling the structure to avoid the info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b56518548aa6e99e80c6c67b5a7d7f2c8c614c74
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:56 2012 +0000

    ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)

    [ Upstream commit 2d8a041b7bfe1097af21441cb77d6af95f4f4680 ]

    If at least one of CONFIG_IP_VS_PROTO_TCP or CONFIG_IP_VS_PROTO_UDP is
    not set, __ip_vs_get_timeouts() does not fully initialize the structure
    that gets copied to userland and that for leaks up to 12 bytes of kernel
    stack. Add an explicit memset(0) before passing the structure to
    __ip_vs_get_timeouts() to avoid the info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Wensong Zhang <wensong@linux-vs.org>
    Cc: Simon Horman <horms@verge.net.au>
    Cc: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 500e5c989e64489413ffde419b3d94789290a4b7
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:55 2012 +0000

    dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)

    [ Upstream commit 7b07f8eb75aa3097cdfd4f6eac3da49db787381d ]

    The CCID3 code fails to initialize the trailing padding bytes of struct
    tfrc_tx_info added for alignment on 64 bit architectures. It that for
    potentially leaks four bytes kernel stack via the getsockopt() syscall.
    Add an explicit memset(0) before filling the structure to avoid the
    info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27fb5ec5224d73f8e05a0ec6a00bf6b07a591470
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:53 2012 +0000

    llc: fix info leak via getsockname()

    [ Upstream commit 3592aaeb80290bda0f2cf0b5456c97bfc638b192 ]

    The LLC code wrongly returns 0, i.e. "success", when the socket is
    zapped. Together with the uninitialized uaddrlen pointer argument from
    sys_getsockname this leads to an arbitrary memory leak of up to 128
    bytes kernel stack via the getsockname() syscall.

    Return an error instead when the socket is zapped to prevent the info
    leak. Also remove the unnecessary memset(0). We don't directly write to
    the memory pointed by uaddr but memcpy() a local structure at the end of
    the function that is properly initialized.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ffb80e739e282d7b9ffa43c2ec2a9766c8099a1
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:51 2012 +0000

    Bluetooth: L2CAP - Fix info leak via getsockname()

    [ Upstream commit 792039c73cf176c8e39a6e8beef2c94ff46522ed ]

    The L2CAP code fails to initialize the l2_bdaddr_type member of struct
    sockaddr_l2 and the padding byte added for alignment. It that for leaks
    two bytes kernel stack via the getsockname() syscall. Add an explicit
    memset(0) before filling the structure to avoid the info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00553f5b9fd16a2c2287e41cc18217bdc7f9d310
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:50 2012 +0000

    Bluetooth: RFCOMM - Fix info leak via getsockname()

    [ Upstream commit 9344a972961d1a6d2c04d9008b13617bcb6ec2ef ]

    The RFCOMM code fails to initialize the trailing padding byte of struct
    sockaddr_rc added for alignment. It that for leaks one byte kernel stack
    via the getsockname() syscall. Add an explicit memset(0) before filling
    the structure to avoid the info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 416a675770e625f4f5ccef3ce70b560abc94757a
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:49 2012 +0000

    Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)

    [ Upstream commit f9432c5ec8b1e9a09b9b0e5569e3c73db8de432a ]

    The RFCOMM code fails to initialize the two padding bytes of struct
    rfcomm_dev_list_req inserted for alignment before copying it to
    userland. Additionally there are two padding bytes in each instance of
    struct rfcomm_dev_info. The ioctl() that for disclosures two bytes plus
    dev_num times two bytes uninitialized kernel heap memory.

    Allocate the memory using kzalloc() to fix this issue.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1c0a71da10bb2b9357b35a80ad315a353340c46
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:47 2012 +0000

    Bluetooth: HCI - Fix info leak via getsockname()

    [ Upstream commit 3f68ba07b1da811bf383b4b701b129bfcb2e4988 ]

    The HCI code fails to initialize the hci_channel member of struct
    sockaddr_hci and that for leaks two bytes kernel stack via the
    getsockname() syscall. Initialize hci_channel with 0 to avoid the
    info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b917a7e47ff3f86bf55cf22d810b97cc053fac8
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:46 2012 +0000

    Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)

    [ Upstream commit e15ca9a0ef9a86f0477530b0f44a725d67f889ee ]

    The HCI code fails to initialize the two padding bytes of struct
    hci_ufilter before copying it to userland -- that for leaking two
    bytes kernel stack. Add an explicit memset(0) before filling the
    structure to avoid the info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5d3ca708a08caa3a55531b6b781edcb0f64724d
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:45 2012 +0000

    atm: fix info leak via getsockname()

    [ Upstream commit 3c0c5cfdcd4d69ffc4b9c0907cec99039f30a50a ]

    The ATM code fails to initialize the two padding bytes of struct
    sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
    before filling the structure to avoid the info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a897ce370b0bbe57961372c67bd0ffc2dd3f7ea
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:44 2012 +0000

    atm: fix info leak in getsockopt(SO_ATMPVC)

    [ Upstream commit e862f1a9b7df4e8196ebec45ac62295138aa3fc2 ]

    The ATM code fails to initialize the two padding bytes of struct
    sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
    before filling the structure to avoid the info leak.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9b6caca04a5444f61c1b08ebf04c6f2c6ff2ec9
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Tue Aug 14 08:54:51 2012 +0000

    ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock

    [ Upstream commit 4acd4945cd1e1f92b20d14e349c6c6a52acbd42d ]

    Cong Wang reports that lockdep detected suspicious RCU usage while
    enabling IPV6 forwarding:

     [ 1123.310275] ===============================
     [ 1123.442202] [ INFO: suspicious RCU usage. ]
     [ 1123.558207] 3.6.0-rc1+ #109 Not tainted
     [ 1123.665204] -------------------------------
     [ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section!
     [ 1123.992320]
     [ 1123.992320] other info that might help us debug this:
     [ 1123.992320]
     [ 1124.307382]
     [ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0
     [ 1124.522220] 2 locks held by sysctl/5710:
     [ 1124.648364]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81768498>] rtnl_trylock+0x15/0x17
     [ 1124.882211]  #1:  (rcu_read_lock){.+.+.+}, at: [<ffffffff81871df8>] rcu_lock_acquire+0x0/0x29
     [ 1125.085209]
     [ 1125.085209] stack backtrace:
     [ 1125.332213] Pid: 5710, comm: sysctl Not tainted 3.6.0-rc1+ #109
     [ 1125.441291] Call Trace:
     [ 1125.545281]  [<ffffffff8109d915>] lockdep_rcu_suspicious+0x109/0x112
     [ 1125.667212]  [<ffffffff8107c240>] rcu_preempt_sleep_check+0x45/0x47
     [ 1125.781838]  [<ffffffff8107c260>] __might_sleep+0x1e/0x19b
    [...]
     [ 1127.445223]  [<ffffffff81757ac5>] call_netdevice_notifiers+0x4a/0x4f
    [...]
     [ 1127.772188]  [<ffffffff8175e125>] dev_disable_lro+0x32/0x6b
     [ 1127.885174]  [<ffffffff81872d26>] dev_forward_change+0x30/0xcb
     [ 1128.013214]  [<ffffffff818738c4>] addrconf_forward_change+0x85/0xc5
    [...]

    addrconf_forward_change() uses RCU iteration over the netdev list,
    which is unnecessary since it already holds the RTNL lock.  We also
    cannot reasonably require netdevice notifier functions not to sleep.

    Reported-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d1244f43868053b12684af2f9fe918c5641d898
Author: danborkmann@iogearbox.net <danborkmann@iogearbox.net>
Date:   Fri Aug 10 22:48:54 2012 +0000

    af_packet: remove BUG statement in tpacket_destruct_skb

    [ Upstream commit 7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 ]

    Here's a quote of the comment about the BUG macro from asm-generic/bug.h:

     Don't use BUG() or BUG_ON() unless there's really no way out; one
     example might be detecting data structure corruption in the middle
     of an operation that can't be backed out of.  If the (sub)system
     can somehow continue operating, perhaps with reduced functionality,
     it's probably not BUG-worthy.

     If you're tempted to BUG(), think again:  is completely giving up
     really the *only* solution?  There are usually better options, where
     users don't need to reboot ASAP and can mostly shut down cleanly.

    In our case, the status flag of a ring buffer slot is managed from both sides,
    the kernel space and the user space. This means that even though the kernel
    side might work as expected, the user space screws up and changes this flag
    right between the send(2) is triggered when the flag is changed to
    TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
    will hit the BUG macro. As David suggested, the best solution is to simply
    remove this statement since it cannot be used for kernel side internal
    consistency checks. I've tested it and the system still behaves /stable/ in
    this case, so in accordance with the above comment, we should rather remove it.

    Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e869e6223d29115d2d8351e5e3f514ddc1099f29
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Wed Aug 8 00:33:25 2012 +0000

    net/core: Fix potential memory leak in dev_set_alias()

    [ Upstream commit 7364e445f62825758fa61195d237a5b8ecdd06ec ]

    Do not leak memory by updating pointer with potentially NULL realloc return value.

    Found by Linux Driver Verification project (linuxtesting.org).

    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5c04e27f19ce463eb61c2d49e20c1b9bac13900
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Thu Aug 2 23:10:01 2012 +0000

    isdnloop: fix and simplify isdnloop_init()

    [ Upstream commit 77f00f6324cb97cf1df6f9c4aaeea6ada23abdb2 ]

    Fix a buffer overflow bug by removing the revision and printk.

    [   22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
    [   22.097508] isdnloop: (loop0) virtual card added
    [   22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
    [   22.174400]
    [   22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
    [   22.624071] Call Trace:
    [   22.720558]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
    [   22.815248]  [<ffffffff8222b623>] panic+0x110/0x329
    [   22.914330]  [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
    [   23.014800]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
    [   23.090763]  [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
    [   23.185748]  [<ffffffff83244972>] isdnloop_init+0xaf/0xb1

    Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5916dedd20a1714a8436f51ba4df13bd4c56474
Author: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date:   Fri Aug 3 19:57:52 2012 +0900

    net_sched: gact: Fix potential panic in tcf_gact().

    [ Upstream commit 696ecdc10622d86541f2e35cc16e15b6b3b1b67e ]

    gact_rand array is accessed by gact->tcfg_ptype whose value
    is assumed to less than MAX_RAND, but any range checks are
    not performed.

    So add a check in tcf_gact_init(). And in tcf_gact(), we can
    reduce a branch.

    Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09c403dc7c8e73a4f9c553e4d84aef68af25ff65
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Mon Jul 30 16:11:42 2012 +0000

    tcp: Apply device TSO segment limit earlier

    [ Upstream commit 1485348d2424e1131ea42efc033cbd9366462b01 ]

    Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
    limit the size of TSO skbs.  This avoids the need to fall back to
    software GSO for local TCP senders.

    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a15a4b44f4f3348db373f70103b25a1175ea25b
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Mon Jul 30 15:57:44 2012 +0000

    sfc: Fix maximum number of TSO segments and minimum TX queue size

    [ Upstream commit 7e6d06f0de3f74ca929441add094518ae332257c ]

    Currently an skb requiring TSO may not fit within a minimum-size TX
    queue.  The TX queue selected for the skb may stall and trigger the TX
    watchdog repeatedly (since the problem skb will be retried after the
    TX reset).  This issue is designated as CVE-2012-3412.

    Set the maximum number of TSO segments for our devices to 100.  This
    should make no difference to behaviour unless the actual MSS is less
    than about 700.  Increase the minimum TX queue size accordingly to
    allow for 2 worst-case skbs, so that there will definitely be space
    to add an skb after we wake a queue.

    To avoid invalidating existing configurations, change
    efx_ethtool_set_ringparam() to fix up values that are too small rather
    than returning -EINVAL.

    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f8742aecd30470b4ae8f9bb6bd0b9b6abb93c9f
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Mon Jul 30 15:57:00 2012 +0000

    net: Allow driver to limit number of GSO segments per skb

    [ Upstream commit 30b678d844af3305cda5953467005cebb5d7b687 ]

    A peer (or local user) may cause TCP to use a nominal MSS of as little
    as 88 (actual MSS of 76 with timestamps).  Given that we have a
    sufficiently prodigious local sender and the peer ACKs quickly enough,
    it is nevertheless possible to grow the window for such a connection
    to the point that we will try to send just under 64K at once.  This
    results in a single skb that expands to 861 segments.

    In some drivers with TSO support, such an skb will require hundreds of
    DMA descriptors; a substantial fraction of a TX ring or even more than
    a full ring.  The TX queue selected for the skb may stall and trigger
    the TX watchdog repeatedly (since the problem skb will be retried
    after the TX reset).  This particularly affects sfc, for which the
    issue is designated as CVE-2012-3412.

    Therefore:
    1. Add the field net_device::gso_max_segs holding the device-specific
       limit.
    2. In netif_skb_features(), if the number of segments is too high then
       mask out GSO features to force fall back to software GSO.

    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>