Linux 3.0.17

commit e9d23be2708477feeaec78e707c80441520c1ef6
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Thu Jan 12 11:54:29 2012 -0800

    Linux 3.0.17

commit 6e474bc4d5c0d94c070a18901e00ff33de0c1be1
Author: Xi Wang <xi.wang@gmail.com>
Date:   Mon Dec 12 21:55:52 2011 +0000

    xfs: fix acl count validation in xfs_acl_from_disk()

    commit 093019cf1b18dd31b2c3b77acce4e000e2cbc9ce upstream.

    Commit fa8b18ed didn't prevent the integer overflow and possible
    memory corruption.  "count" can go negative and bypass the check.

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 68f760945cb704f4a9d0ae7c4abc9e41ca30aa91
Author: Thilo-Alexander Ginkel <thilo@ginkel.com>
Date:   Sat Dec 17 10:55:10 2011 +0100

    usb: cdc-acm: Fix acm_tty_hangup() vs. acm_tty_close() race

    [Not upstream as it was fixed differently for 3.3 with a much more
    "intrusive" rework of the driver - gregkh]

    There is a race condition involving acm_tty_hangup() and acm_tty_close()
    where hangup() would attempt to access tty->driver_data without proper
    locking and NULL checking after close() has potentially already set it
    to NULL.  One possibility to (sporadically) trigger this behavior is to
    perform a suspend/resume cycle with a running WWAN data connection.

    This patch addresses the issue by introducing a NULL check for
    tty->driver_data in acm_tty_hangup() protected by open_mutex and exiting
    gracefully when hangup() is invoked on a device that has already been
    closed.

    Signed-off-by: Thilo-Alexander Ginkel <thilo@ginkel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 18366c3fed0c372f9c123489e7061de11b640965
Author: kashyap.desai@lsi.com <kashyap.desai@lsi.com>
Date:   Thu Aug 4 16:47:50 2011 +0530

    SCSI: mpt2sas: Added missing mpt2sas_base_detach call from scsih_remove context

    commit 9ae89b0296e275d5a556068b40b7c2557a556a85 upstream.

    mpt2sas_base_detach() call was removed from _scsih_remove() while
    doing some code shuffling.  Mainly when we work on adding code for
    scsih_shutdown().  I have added back mpt2sas_base_detach() which will
    get callled from _scsih_remove().

    Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>

commit 4ae84455f98af3b3c3a23f8b6458fcefc9ff62bf
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Thu Nov 3 00:59:25 2011 +0100

    PM / Sleep: Fix race between CPU hotplug and freezer

    commit 79cfbdfa87e84992d509e6c1648a18e1d7e68c20 upstream.

    The CPU hotplug notifications sent out by the _cpu_up() and _cpu_down()
    functions depend on the value of the 'tasks_frozen' argument passed to them
    (which indicates whether tasks have been frozen or not).
    (Examples for such CPU hotplug notifications: CPU_ONLINE, CPU_ONLINE_FROZEN,
    CPU_DEAD, CPU_DEAD_FROZEN).

    Thus, it is essential that while the callbacks for those notifications are
    running, the state of the system with respect to the tasks being frozen or
    not remains unchanged, *throughout that duration*. Hence there is a need for
    synchronizing the CPU hotplug code with the freezer subsystem.

    Since the freezer is involved only in the Suspend/Hibernate call paths, this
    patch hooks the CPU hotplug code to the suspend/hibernate notifiers
    PM_[SUSPEND|HIBERNATE]_PREPARE and PM_POST_[SUSPEND|HIBERNATE] to prevent
    the race between CPU hotplug and freezer, thus ensuring that CPU hotplug
    notifications will always be run with the state of the system really being
    what the notifications indicate, _throughout_ their execution time.

    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 81aaa36dde03db855fb233382c7667f98ac12659
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Sat Dec 31 13:26:46 2011 +0000

    bonding: fix error handling if slave is busy (v2)

    commit f7d9821a6a9c83450ac35e76d3709e32fd38b76f upstream.

    If slave device already has a receive handler registered, then the
    error unwind of bonding device enslave function is broken.

    The following will leave a pointer to freed memory in the slave
    device list, causing a later kernel panic.
    # modprobe dummy
    # ip li add dummy0-1 link dummy0 type macvlan
    # modprobe bonding
    # echo +dummy0 >/sys/class/net/bond0/bonding/slaves

    The fix is to detach the slave (which removes it from the list)
    in the unwind path.

    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2643bcef53a08c09975861ebbed6d687571a2751
Author: Aurelien Jacobs <aurel@gnuage.org>
Date:   Sat Jan 7 12:15:16 2012 -0800

    asix: fix infinite loop in rx_fixup()

    commit 6c15d74defd38e7e7f8805392578b7a1d508097e upstream.

    At this point if skb->len happens to be 2, the subsequant skb_pull(skb, 4)
    call won't work and the skb->len won't be decreased and won't ever reach 0,
    resulting in an infinite loop.

    With an ASIX 88772 under heavy load, without this patch, rx_fixup() reaches
    an infinite loop in less than a minute. With this patch applied,
    no infinite loop even after hours of heavy load.

    Signed-off-by: Aurelien Jacobs <aurel@gnuage.org>
    Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 49ffa26eca87d3518ed88d3e6feebf1b80837a15
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon Jan 9 14:06:46 2012 -0800

    igmp: Avoid zero delay when receiving odd mixture of IGMP queries

    commit a8c1f65c79cbbb2f7da782d4c9d15639a9b94b27 upstream.

    Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP
    behavior on v3 query during v2-compatibility mode') added yet another
    case for query parsing, which can result in max_delay = 0.  Substitute
    a value of 1, as in the usual v3 case.

    Reported-by: Simon McVittie <smcv@debian.org>
    References: http://bugs.debian.org/654876
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 06752b6cc142845a2c21196fa86a0cba7d72d325
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Nov 17 16:41:45 2011 -0500

    OHCI: final fix for NVIDIA problems (I hope)

    commit c61875977458637226ab093a35d200f2d5789787 upstream.

    Problems with NVIDIA's OHCI host controllers persist.  After looking
    carefully through the spec, I finally realized that when a controller
    is reset it then automatically goes into a SUSPEND state in which it
    is completely quiescent (no DMA and no IRQs) and from which it will
    not awaken until the system puts it into the OPERATIONAL state.

    Therefore there's no need to worry about controllers being in the
    RESET state for extended periods, or remaining in the OPERATIONAL
    state during system shutdown.  The proper action for device
    initialization is to put the controller into the RESET state (if it's
    not there already) and then to issue a software reset.  Similarly, the
    proper action for device shutdown is simply to do a software reset.

    This patch (as1499) implements such an approach.  It simplifies
    initialization and shutdown, and allows the NVIDIA shutdown-quirk code
    to be removed.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
    Tested-by: Arno Augustin <Arno.Augustin@web.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9f3657ac7841b871c5d2dc8ab51fb08080ae67b1
Author: Felipe Balbi <balbi@ti.com>
Date:   Mon Jan 2 13:35:41 2012 +0200

    usb: ch9: fix up MaxStreams helper

    commit 18b7ede5f7ee2092aedcb578d3ac30bd5d4fc23c upstream.

    [ removed the dwc3 portion of the patch as it didn't apply to
    older kernels - gregkh]

    According to USB 3.0 Specification Table 9-22, if
    bmAttributes [4:0] are set to zero, it means "no
    streams supported", but the way this helper was
    defined on Linux, we will *always* have one stream
    which might cause several problems.

    For example on DWC3, we would tell the controller
    endpoint has streams enabled and yet start transfers
    with Stream ID set to 0, which would goof up the host
    side.

    While doing that, convert the macro to an inline
    function due to the different checks we now need.

    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@suse.de>

commit 9f1efce9d1265de3888ddb4a91cb6d5b14536ff2
Author: Janne Snabb <snabb@epipe.com>
Date:   Wed Dec 28 19:36:00 2011 +0000

    usb: option: add ZD Incorporated HSPA modem

    commit 3c8c9316710b83e906e425024153bf0929887b59 upstream.

    Add support for Chinese Noname HSPA USB modem which is apparently
    manufactured by a company called ZD Incorporated (based on texts in the
    Windows drivers).

    This product is available at least from Dealextreme (SKU 80032) and
    possibly in India with name Olive V-MW250. It is based on Qualcomm
    MSM6280 chip.

    I needed to also add "options usb-storage quirks=0685:7000:i" in modprobe
    configuration because udevd or the kernel keeps poking the embedded
    fake-cd-rom which fails and causes the device to reset. There might be
    a better way to accomplish the same. usb_modeswitch is not needed with
    this device.

    Signed-off-by: Janne Snabb <snabb@epipe.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit cca4989bac1a29811a3be91c29a5648375016392
Author: VU Tuan Duc <DucVT@viettel.com.vn>
Date:   Tue Nov 15 14:08:00 2011 +0700

    USB: option: add id for 3G dongle Model VT1000 of Viettel

    commit 5b061623355d8f69327a24838b0aa05e435ae5d5 upstream.

    Add VendorID/ProductID for USB 3G dongle Model VT1000 of Viettel.

    Signed-off-by: VU Tuan Duc <ducvt@viettel.com.vn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 35e81320ad9953dbcf3cea06d18828ebee3b0468
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Jan 4 23:29:18 2012 +0100

    xhci: Properly handle COMP_2ND_BW_ERR

    commit 71d85724bdd947a3b42a88d08af79f290a1a767b upstream.

    I encountered a result of COMP_2ND_BW_ERR while improving how the pwc
    webcam driver handles not having the full usb1 bandwidth available to
    itself.

    I created the following test setup, a NEC xhci controller with a
    single TT USB 2 hub plugged into it, with a usb keyboard and a pwc webcam
    plugged into the usb2 hub. This caused the following to show up in dmesg
    when trying to stream from the pwc camera at its highest alt setting:

    xhci_hcd 0000:01:00.0: ERROR: unexpected command completion code 0x23.
    usb 6-2.1: Not enough bandwidth for altsetting 9

    And usb_set_interface returned -EINVAL, which caused my pwc code to not
    do the right thing as it expected -ENOSPC.

    This patch makes the xhci driver properly handle COMP_2ND_BW_ERR and makes
    usb_set_interface return -ENOSPC as expected.

    This should be backported to stable kernels as old as 2.6.32.

    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 766b8a7f7ee006dfd73dbc676addd80f7dbe86ef
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Dec 3 23:41:31 2011 +0100

    usb: fix number of mapped SG DMA entries

    commit bc677d5b64644c399cd3db6a905453e611f402ab upstream.

    Add a new field num_mapped_sgs to struct urb so that we have a place to
    store the number of mapped entries and can also retain the original
    value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
    would overwrite this with the number of mapped entries, which would
    break dma_unmap_sg() because it requires the original number of entries.

    This fixes warnings like the following when using USB storage devices:
     ------------[ cut here ]------------
     WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
     ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
     Modules linked in: ohci_hcd ehci_hcd
     Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
     Call Trace:
      <IRQ>  [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98
      [<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43
      [<ffffffff811fa5ae>] check_unmap+0x4e4/0x695
      [<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf
      [<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50
      [<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117
      [<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188
      [<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22
      [<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0
      [<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd]
      [<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd]
      [<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd]
      ...
     ---[ end trace f29ac88a5a48c580 ]---
     Mapped at:
      [<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139
      [<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478
      [<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa
      [<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de
      [<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161

    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0d5b25f934978301b2a1385c72f3b6abe04db484
Author: Malte Schröder <maltesch@gmx.de>
Date:   Thu Jan 5 20:34:40 2012 +0100

    USB: Add USB-ID for Multiplex RC serial adapter to cp210x.c

    commit 08e87d0d773dc9ca5faf4c3306e238ed0ea129b0 upstream.

    Hi, below patch adds the USB-ID of the serial adapters sold by
    Multiplex RC (www.multiplex-rc.de).

    Signed-off-by: Malte Schröder <maltesch@gmx.de>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 5ccce01507d92e98ca263b35aa263f43e24b272f
Author: Johan Hovold <jhovold@gmail.com>
Date:   Sun Nov 6 19:06:21 2011 +0100

    USB: omninet: fix write_room

    commit 694c6301e515bad574af74b6552134c4d9dcb334 upstream.

    Fix regression introduced by commit 507ca9bc047666 ([PATCH] USB: add
    ability for usb-serial drivers to determine if their write urb is
    currently being used.) which inverted the logic in write_room so that it
    returns zero when the write urb is actually free.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a2cb6c3022494f6e43d284ed9159e15dd71f5937
Author: Felipe Contreras <felipe.contreras@gmail.com>
Date:   Mon Dec 19 22:01:54 2011 +0200

    usb: musb: fix pm_runtime mismatch

    commit 772aed45b604c5ff171f0f12c12392d868333f79 upstream.

    In musb_init_controller() there's a pm_runtime_put(), but there's no
    pm_runtime_get(), which creates a mismatch that causes the driver to
    sleep when it shouldn't.

    This was introduced in 7acc619[1], but it wasn't triggered in my setup
    until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW;
    when PM is working as it was supposed to.

    However, it seems most of the time this is used in a way that keeps the
    counter above 0, so nobody noticed. Also, it seems to depend on the
    configuration used in versions before 3.1, but not later (or in it).

    I found the problem by loading isp1704_charger before any usb gadgets:
    http://article.gmane.org/gmane.linux.kernel/1226122

    All versions after 2.6.39 are affected.

    [1] usb: musb: Idle path retention and offmode support for OMAP3
    [2] OMAP2+: musb: hwmod adaptation for musb registration
    [3] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6

    Cc: Hema HK <hemahk@ti.com>
    Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>

commit d1a86326cb0aaa71ddef4ae5325e2387c1410380
Author: Oliver Neukum <oliver@neukum.org>
Date:   Tue Jan 3 09:58:54 2012 +0100

    USB: add quirk for another camera

    commit 35284b3d2f68a8a3703745e629999469f78386b5 upstream.

    The Guillemot Webcam Hercules Dualpix Exchange camera
    has been reported with a second ID.

    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 702d50dd4360c942a3b888c468843f2540a95e64
Author: Huajun Li <huajun.li.lee@gmail.com>
Date:   Wed Jan 4 19:25:33 2012 +0800

    usb: usb-storage doesn't support dynamic id currently, the patch disables the feature to fix an oops

    commit 1a3a026ba1b6bbfe0b7f79ab38cf991d691e7c9a upstream.

    Echo vendor and product number of a non usb-storage device to
    usb-storage driver's new_id, then plug in the device to host and you
    will find following oops msg, the root cause is usb_stor_probe1()
    refers invalid id entry if giving a dynamic id, so just disable the
    feature.

    [ 3105.018012] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
    [ 3105.018062] CPU 0
    [ 3105.018075] Modules linked in: usb_storage usb_libusual bluetooth
    dm_crypt binfmt_misc snd_hda_codec_analog snd_hda_intel snd_hda_codec
    snd_hwdep hp_wmi ppdev sparse_keymap snd_pcm snd_seq_midi snd_rawmidi
    snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse snd
    serio_raw tpm_infineon soundcore i915 snd_page_alloc tpm_tis
    parport_pc tpm tpm_bios drm_kms_helper drm i2c_algo_bit video lp
    parport usbhid hid sg sr_mod sd_mod ehci_hcd uhci_hcd usbcore e1000e
    usb_common floppy
    [ 3105.018408]
    [ 3105.018419] Pid: 189, comm: khubd Tainted: G          I  3.2.0-rc7+
    #29 Hewlett-Packard HP Compaq dc7800p Convertible Minitower/0AACh
    [ 3105.018481] RIP: 0010:[<ffffffffa045830d>]  [<ffffffffa045830d>]
    usb_stor_probe1+0x2fd/0xc20 [usb_storage]
    [ 3105.018536] RSP: 0018:ffff880056a3d830  EFLAGS: 00010286
    [ 3105.018562] RAX: ffff880065f4e648 RBX: ffff88006bb28000 RCX: 0000000000000000
    [ 3105.018597] RDX: ffff88006f23c7b0 RSI: 0000000000000001 RDI: 0000000000000206
    [ 3105.018632] RBP: ffff880056a3d900 R08: 0000000000000000 R09: ffff880067365000
    [ 3105.018665] R10: 00000000000002ac R11: 0000000000000010 R12: ffff6000b41a7340
    [ 3105.018698] R13: ffff880065f4ef60 R14: ffff88006bb28b88 R15: ffff88006f23d270
    [ 3105.018733] FS:  0000000000000000(0000) GS:ffff88007a200000(0000)
    knlGS:0000000000000000
    [ 3105.018773] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 3105.018801] CR2: 00007fc99c8c4650 CR3: 0000000001e05000 CR4: 00000000000006f0
    [ 3105.018835] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 3105.018870] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 3105.018906] Process khubd (pid: 189, threadinfo ffff880056a3c000,
    task ffff88005677a400)
    [ 3105.018945] Stack:
    [ 3105.018959]  0000000000000000 0000000000000000 ffff880056a3d8d0
    0000000000000002
    [ 3105.019011]  0000000000000000 ffff880056a3d918 ffff880000000000
    0000000000000002
    [ 3105.019058]  ffff880056a3d8d0 0000000000000012 ffff880056a3d8d0
    0000000000000006
    [ 3105.019105] Call Trace:
    [ 3105.019128]  [<ffffffffa0458cd4>] storage_probe+0xa4/0xe0 [usb_storage]
    [ 3105.019173]  [<ffffffffa0097822>] usb_probe_interface+0x172/0x330 [usbcore]
    [ 3105.019211]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
    [ 3105.019243]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
    [ 3105.019272]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
    [ 3105.019303]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
    [ 3105.019334]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
    [ 3105.019364]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
    [ 3105.019396]  [<ffffffff815f98a6>] device_add+0x876/0x990
    [ 3105.019434]  [<ffffffffa0094e42>] usb_set_configuration+0x822/0x9e0 [usbcore]
    [ 3105.019479]  [<ffffffffa00a3492>] generic_probe+0x62/0xf0 [usbcore]
    [ 3105.019518]  [<ffffffffa0097a46>] usb_probe_device+0x66/0xb0 [usbcore]
    [ 3105.019555]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
    [ 3105.019589]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
    [ 3105.019617]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
    [ 3105.019648]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
    [ 3105.019680]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
    [ 3105.019709]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
    [ 3105.021040] usb usb6: usb auto-resume
    [ 3105.021045] usb usb6: wakeup_rh
    [ 3105.024849]  [<ffffffff815f98a6>] device_add+0x876/0x990
    [ 3105.025086]  [<ffffffffa0088987>] usb_new_device+0x1e7/0x2b0 [usbcore]
    [ 3105.025086]  [<ffffffffa008a4d7>] hub_thread+0xb27/0x1ec0 [usbcore]
    [ 3105.025086]  [<ffffffff810d5200>] ? wake_up_bit+0x50/0x50
    [ 3105.025086]  [<ffffffffa00899b0>] ? usb_remote_wakeup+0xa0/0xa0 [usbcore]
    [ 3105.025086]  [<ffffffff810d49b8>] kthread+0xd8/0xf0
    [ 3105.025086]  [<ffffffff81939884>] kernel_thread_helper+0x4/0x10
    [ 3105.025086]  [<ffffffff8192a8c0>] ? _raw_spin_unlock_irq+0x50/0x80
    [ 3105.025086]  [<ffffffff8192b1b4>] ? retint_restore_args+0x13/0x13
    [ 3105.025086]  [<ffffffff810d48e0>] ? __init_kthread_worker+0x80/0x80
    [ 3105.025086]  [<ffffffff81939880>] ? gs_change+0x13/0x13
    [ 3105.025086] Code: 00 48 83 05 cd ad 00 00 01 48 83 05 cd ad 00 00
    01 4c 8b ab 30 0c 00 00 48 8b 50 08 48 83 c0 30 48 89 45 a0 4c 89 a3
    40 0c 00 00 <41> 0f b6 44 24 10 48 89 55 a8 3c ff 0f 84 b8 04 00 00 48
    83 05
    [ 3105.025086] RIP  [<ffffffffa045830d>] usb_stor_probe1+0x2fd/0xc20
    [usb_storage]
    [ 3105.025086]  RSP <ffff880056a3d830>
    [ 3105.060037] hub 6-0:1.0: hub_resume
    [ 3105.062616] usb usb5: usb auto-resume
    [ 3105.064317] ehci_hcd 0000:00:1d.7: resume root hub
    [ 3105.094809] ---[ end trace a7919e7f17c0a727 ]---
    [ 3105.130069] hub 5-0:1.0: hub_resume
    [ 3105.132131] usb usb4: usb auto-resume
    [ 3105.132136] usb usb4: wakeup_rh
    [ 3105.180059] hub 4-0:1.0: hub_resume
    [ 3106.290052] usb usb6: suspend_rh (auto-stop)
    [ 3106.290077] usb usb4: suspend_rh (auto-stop)

    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 41671fca58f3487f4dd4b148a0a3360b2f9ebb2a
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Mon Dec 5 14:02:59 2011 -0800

    USB: isight: fix kernel bug when loading firmware

    commit 59bf5cf94f0fa3b08fb1258b52649077b7d0914d upstream.

    We were sending data on the stack when uploading firmware, which causes
    some machines fits, and is not allowed.  Fix this by using the buffer we
    already had around for this very purpose.

    Reported-by: Wouter M. Koolen <wmkoolen@cwi.nl>
    Tested-by: Wouter M. Koolen <wmkoolen@cwi.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e60f83773e5a5757b765b30776bd1e7fe1188c1b
Author: Julia Lawall <julia@diku.dk>
Date:   Fri Dec 23 14:02:55 2011 +0100

    drivers/usb/class/cdc-acm.c: clear dangling pointer

    commit e7c8e8605d0bafc705ff27f9da98a1668427cc0f upstream.

    On some failures, the country_code field of an acm structure is freed
    without freeing the acm structure itself.  Elsewhere, operations including
    memcpy and kfree are performed on the country_code field.  The patch sets
    the country_code field to NULL when it is freed, and likewise sets the
    country_code_size field to 0.

    Signed-off-by: Julia Lawall <julia@diku.dk>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 608620c3e7c26618bbef00ce070e7d0bbfb9cc37
Author: Jan Kara <jack@suse.cz>
Date:   Sat Dec 10 02:30:48 2011 +0100

    udf: Fix deadlock when converting file from in-ICB one to normal one

    commit d2eb8c359309ec45d6bf5b147303ab8e13be86ea upstream.

    During BKL removal in 2.6.38, conversion of files from in-ICB format to normal
    format got broken. We call ->writepage with i_data_sem held but udf_get_block()
    also acquires i_data_sem thus creating A-A deadlock.

    We fix the problem by dropping i_data_sem before calling ->writepage() which is
    safe since i_mutex still protects us against any changes in the file. Also fix
    pagelock - i_data_sem lock inversion in udf_expand_file_adinicb() by dropping
    i_data_sem before calling find_or_create_page().

    Reported-by: Matthias Matiak <netzpython@mail-on.us>
    Tested-by: Matthias Matiak <netzpython@mail-on.us>
    Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2481cbcad1ba76a928c74c2e8cab67d8c77823ab
Author: Li Zefan <lizf@cn.fujitsu.com>
Date:   Tue Dec 27 14:25:55 2011 +0800

    cgroup: fix to allow mounting a hierarchy by name

    commit 0d19ea866562e46989412a0676412fa0983c9ce7 upstream.

    If we mount a hierarchy with a specified name, the name is unique,
    and we can use it to mount the hierarchy without specifying its
    set of subsystem names. This feature is documented is
    Documentation/cgroups/cgroups.txt section 2.3

    Here's an example:

    	# mount -t cgroup -o cpuset,name=myhier xxx /cgroup1
    	# mount -t cgroup -o name=myhier xxx /cgroup2

    But it was broken by commit 32a8cf235e2f192eb002755076994525cdbaa35a
    (cgroup: make the mount options parsing more accurate)

    This fixes the regression.

    Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 630fe244a944ebb950e8b2076177547266d255cf
Author: Claudio Scordino <claudio@evidence.eu.com>
Date:   Fri Dec 16 15:08:49 2011 +0100

    atmel_serial: fix spinlock lockup in RS485 code

    commit dbf1115d3f8c7052788aa4e6e46abd27f3b3eeba upstream.

    Patch to fix a spinlock lockup in the driver that sometimes happens when the
    tasklet starts.

    Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
    Signed-off-by: Dave Bender <codehero@gmail.com>
    Tested-by: Dave Bender <codehero@gmail.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 90a043b02598d19b6dccc677bbf9bb8e8ec94ab7
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Jan 4 16:36:35 2012 -0500

    USB: update documentation for usbmon

    commit d8cae98cddd286e38db1724dda1b0e7b467f9237 upstream.

    The documentation for usbmon is out of date; the usbfs "devices" file
    now exists in /sys/kernel/debug/usb rather than /proc/bus/usb.  This
    patch (as1505) updates the documentation accordingly, and also
    mentions that the necessary information can be found by running lsusb.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Pete Zaitcev <zaitcev@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 42e857c955b65b25062e5af605c4164e5e32b144
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 22 16:49:05 2011 +0100

    ext3: Don't warn from writepage when readonly inode is spotted after error

    commit 33c104d415e92a51aaf638dc3d93920cfa601e5c upstream.

    WARN_ON_ONCE(IS_RDONLY(inode)) tends to trip when filesystem hits error and is
    remounted read-only. This unnecessarily scares users (well, they should be
    scared because of filesystem error, but the stack trace distracts them from the
    right source of their fear ;-). We could as well just remove the WARN_ON but
    it's not hard to fix it to not trip on filesystem with errors and not use more
    cycles in the common case so that's what we do.

    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d8bbed420a3f1a3c7290a7bb9f3b424fd24c0b04
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Wed Dec 21 21:18:43 2011 +0100

    reiserfs: Force inode evictions before umount to avoid crash

    commit a9e36da655e54545c3289b2a0700b5c443de0edd upstream.

    This patch fixes a crash in reiserfs_delete_xattrs during umount.

    When shrink_dcache_for_umount clears the dcache from
    generic_shutdown_super, delayed evictions are forced to disk. If an
    evicted inode has extended attributes associated with it, it will
    need to walk the xattr tree to locate and remove them.

    But since shrink_dcache_for_umount will BUG if it encounters active
    dentries, the xattr tree must be released before it's called or it will
    crash during every umount.

    This patch forces the evictions to occur before generic_shutdown_super
    by calling shrink_dcache_sb first. The additional evictions caused
    by the removal of each associated xattr file and dir will be automatically
    handled as they're added to the LRU list.

    CC: reiserfs-devel@vger.kernel.org
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dcc4f0ce22c88840b2c490e962dfbd84cb003941
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 21 17:35:34 2011 +0100

    reiserfs: Fix quota mount option parsing

    commit a06d789b424190e9f59da391681f908486db2554 upstream.

    When jqfmt mount option is not specified on remount, we mistakenly clear
    s_jquota_fmt value stored in superblock. Fix the problem.

    CC: reiserfs-devel@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2431496fbdd142ccc83138d94f3f510a36ce9270
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Fri Nov 4 16:32:25 2011 -0400

    perf: Fix parsing of __print_flags() in TP_printk()

    commit 49908a1b25d448d68fd26faca260e1850201575f upstream.

    A update is made to the sched:sched_switch event that adds some
    logic to the first parameter of the __print_flags() that shows the
    state of tasks. This change cause perf to fail parsing the flags.

    A simple fix is needed to have the parser be able to process ops
    within the argument.

    Reported-by: Andrew Vagin <avagin@openvz.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0853141b9eff15c72dde6868ee5351db3f7d12f1
Author: Ram Vepa <ram.vepa@qlogic.com>
Date:   Fri Dec 23 08:01:43 2011 -0500

    IB/qib: Fix a possible data corruption when receiving packets

    commit eddfb675256f49d14e8c5763098afe3eb2c93701 upstream.

    Prevent a receive data corruption by ensuring that the write to update
    the rcvhdrheadn register to generate an interrupt is at the very end
    of the receive processing.

    Signed-off-by: Ramkrishna Vepa <ram.vepa@qlogic.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@qlogic.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e50262ea574d1daf62529e2b282b8551790f7f38
Author: Aurelien Jacobs <aurel@gnuage.org>
Date:   Fri Dec 16 10:49:22 2011 +0000

    asix: new device id

    commit e8303a3b2196272c3eb994d0fd1a189a958a2bdd upstream.

    Adds the device id needed for the USB Ethernet Adapter delivered by
    ASUS with their Zenbook.

    Signed-off-by: Aurelien Jacobs <aurel@gnuage.org>
    Acked-by: Grant Grundler <grundler@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ec0d3233562d591c892841fcfa73edd3700a6ca6
Author: Li Zhong <zhong@linux.vnet.ibm.com>
Date:   Sun Dec 18 16:03:04 2011 +0000

    powerpc: Fix unpaired probe_hcall_entry and probe_hcall_exit

    commit e4f387d8db3ba3c2dae4d8bdfe7bb5f4fe1bcb0d upstream.

    Unpaired calling of probe_hcall_entry and probe_hcall_exit might happen
    as following, which could cause incorrect preempt count.

    __trace_hcall_entry => trace_hcall_entry -> probe_hcall_entry =>
    get_cpu_var => preempt_disable

    __trace_hcall_exit => trace_hcall_exit -> probe_hcall_exit =>
    put_cpu_var => preempt_enable

    where:
    A => B and A -> B means A calls B, but
    => means A will call B through function name, and B will definitely be
    called.
    -> means A will call B through function pointer, so B might not be
    called if the function pointer is not set.

    So error happens when only one of probe_hcall_entry and probe_hcall_exit
    get called during a hcall.

    This patch tries to move the preempt count operations from
    probe_hcall_entry and probe_hcall_exit to its callers.

    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>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit bfaebb8af017d443937022cf3d5735d726e4f711
Author: Anton Blanchard <anton@samba.org>
Date:   Wed Nov 23 20:07:17 2011 +0000

    powerpc/time: Handle wrapping of decrementer

    commit 37fb9a0231ee43d42d069863bdfd567fca2b61af upstream.

    When re-enabling interrupts we have code to handle edge sensitive
    decrementers by resetting the decrementer to 1 whenever it is negative.
    If interrupts were disabled long enough that the decrementer wrapped to
    positive we do nothing. This means interrupts can be delayed for a long
    time until it finally goes negative again.

    While we hope interrupts are never be disabled long enough for the
    decrementer to go positive, we have a very good test team that can
    drive any kernel into the ground. The softlockup data we get back
    from these fails could be seconds in the future, completely missing
    the cause of the lockup.

    We already keep track of the timebase of the next event so use that
    to work out if we should trigger a decrementer exception.

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a7b8c32b67b60fe9e8b53bb86bb7a04631e6e262
Author: Pontus Fuchs <pontus.fuchs@gmail.com>
Date:   Tue Oct 18 09:23:42 2011 +0200

    wl12xx: Check buffer bound when processing nvs data

    commit f6efe96edd9c41c624c8f4ddbc4930c1a2d8f1e1 upstream.

    An nvs with malformed contents could cause the processing of the
    calibration data to read beyond the end of the buffer. Prevent this
    from happening by adding bound checking.

    Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
    Reviewed-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 4b2bb3c98c134fb26332afd5ad54078c53a30c44
Author: Pontus Fuchs <pontus.fuchs@gmail.com>
Date:   Tue Oct 18 09:23:41 2011 +0200

    wl12xx: Validate FEM index from ini file and FW

    commit 2131d3c2f99b081806fdae7662c92fe6acda52af upstream.

    Check for out of bound FEM index to prevent reading beyond ini
    memory end.

    Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
    Reviewed-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 68530d7210025a1e395819b774fcffaf943dd8f3
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Tue Jan 3 12:09:15 2012 +1100

    offb: Fix bug in calculating requested vram size

    commit c055fe0797b7bd8f6f21a13598a55a16d5c13ae7 upstream.

    We used to try to request 8 times more vram than needed, which would
    fail if the card has a too small BAR (observed with qemu & kvm).

    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 51a32a1a373e071aec24ffa765d198d591b3d6dd
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Wed Dec 28 00:10:16 2011 +0000

    offb: Fix setting of the pseudo-palette for >8bpp

    commit 1bb0b7d21584b3f878e2bc880db62351ddee5185 upstream.

    When using a >8bpp framebuffer, offb advertises truecolor, not directcolor,
    and doesn't touch the color map even if it has a corresponding access method
    for the real hardware.

    Thus it needs to set the pseudo-palette with all 3 components of the color,
    like other truecolor framebuffers, not with copies of the color index like
    a directcolor framebuffer would do.

    This went unnoticed for a long time because it's pretty hard to get offb
    to kick in with anything but 8bpp (old BootX under MacOS will do that and
    qemu does it).

    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 081fa89b1a6e7ed3a05459b88ad974a6f3795a90
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Dec 27 12:22:51 2011 -0600

    rt2800usb: Move ID out of unknown

    commit 3f81f8f1524ccca24df1029b0cf825ecef5e5cdc upstream.

    Testing on the openSUSE wireless forum has shown that a Linksys
    WUSB54GC v3 with USB ID 1737:0077 works with rt2800usb when the ID is
    written to /sys/.../new_id. This ID can therefore be moved out of UNKNOWN.

    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Acked-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@suse.de>

commit d4560a886a6ddd150cb5489d2b9491f96349aa7f
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Mon Jan 2 15:31:23 2012 -0500

    firmware: Fix an oops on reading fw_priv->fw in sysfs loading file

    commit eea915bb0d1358755f151eaefb8208a2d5f3e10c upstream.

    This oops was reported recently:
    firmware_loading_store+0xf9/0x17b
    dev_attr_store+0x20/0x22
    sysfs_write_file+0x101/0x134
    vfs_write+0xac/0xf3
    sys_write+0x4a/0x6e
    system_call_fastpath+0x16/0x1b

    The complete backtrace was unfortunately not captured, but details can be found
    here:
    https://bugzilla.redhat.com/show_bug.cgi?id=769920

    The cause is fairly clear.

    Its caused by the fact that firmware_loading_store has a case 0 in its
    switch statement that reads and writes the fw_priv->fw poniter without the
    protection of the fw_lock mutex.  since there is a window between the time that
    _request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs
    file is unregistered, its possible for a user space application to race in, and
    write a zero to the loading file, causing a NULL dereference in
    firmware_loading_store.  Fix it by extending the protection of the fw_lock mutex
    to cover all of the firware_loading_store function.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e559e564fbf46caf1d2c5a531ffe8b745b117c3f
Author: Joe Perches <joe@perches.com>
Date:   Fri Dec 9 14:12:00 2011 -0800

    Documentation: Update stable address

    commit 2eb7f204db51969ea558802a6601d79c2fb273b9 upstream.

    The Japanese/Korean/Chinese versions still need updating.

    Also, the stable kernel 2.6.x.y descriptions are out of date
    and should be updated as well.

    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0a356c00cd87453a7c45ab0b2e49410b17802d71
Author: Joe Perches <joe@perches.com>
Date:   Fri Dec 9 13:54:34 2011 -0800

    MAINTAINERS: stable: Update address

    commit bc7a2f3abc636d7cab84258a48e77b08fb5fd3d6 upstream.

    The old address hasn't worked since the great intrusion of August 2011.

    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linux 3.0.18

commit 235eae6e5e402f5f723203e4444f10c16c7c3be3
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Wed Jan 25 17:26:46 2012 -0800

    Linux 3.0.18

commit 20ef6312522d42407e8030bb17f25c4fde724a37
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Wed Jan 11 15:13:27 2012 +0200

    UBIFS: make debugging messages light again

    commit 1f5d78dc4823a85f112aaa2d0f17624f8c2a6c52 upstream.

    We switch to dynamic debugging in commit
    56e46742e846e4de167dde0e1e1071ace1c882a5 but did not take into account that
    now we do not control anymore whether a specific message is enabled or not.
    So now we lock the "dbg_lock" and release it in every debugging macro, which
    make them not so light-weight.

    This commit removes the "dbg_lock" protection from the debugging macros to
    fix the issue.

    The downside is that now our DBGKEY() stuff is broken, but this is not
    critical at all and will be fixed later.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e4ae34bbc7386489a0c8253f246e7a5d316f249a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Dec 23 08:13:50 2011 +0100

    iwlegacy: 3945: fix hw passive scan on radar channels

    commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream.

    Patch fix firmware error on "iw dev wlan0 scan passive" for
    hardware scanning (with disable_hw_scan=0 module parameter).

     iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
     iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9
     iwl3945 0000:03:00.0: Start IWL Error Log Dump:
     iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
     iwl3945 0000:03:00.0: Desc       Time       asrtPC blink2 ilink1  nmiPC   Line
     iwl3945 0000:03:00.0: SYSASSERT     (0x5) 0041263900 0x13756 0x0031C 0x00000 764
     iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
     iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
     iwl3945 0000:03:00.0: Can't stop Rx DMA.

    We have disable ability to change passive scanning to active on
    particular channel when traffic is detected on that channel. Otherwise
    firmware will report error, when we try to do passive scan on radar
    channels.

    Reported-and-debugged-by: Pedro Francisco <pedrogfrancisco@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dd558f1e43567fd51a258f61081809e60735f9f4
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Thu Nov 10 06:55:04 2011 -0800

    iwlagn: check for SMPS mode

    commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream.

    Check and report WARN only when its invalid

    Resolves:
    https://bugzilla.kernel.org/show_bug.cgi?id=42621
    https://bugzilla.redhat.com/show_bug.cgi?id=766071

    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit bcbef18db94dfb991bd3025069b3413cbc52f8b6
Author: Michal Hocko <mhocko@suse.cz>
Date:   Fri Jan 20 14:33:55 2012 -0800

    mm: fix NULL ptr dereference in __count_immobile_pages

    commit 687875fb7de4a95223af20ee024282fa9099f860 upstream.

    Fix the following NULL ptr dereference caused by

      cat /sys/devices/system/memory/memory0/removable

    Pid: 13979, comm: sed Not tainted 3.0.13-0.5-default #1 IBM BladeCenter LS21 -[7971PAM]-/Server Blade
    RIP: __count_immobile_pages+0x4/0x100
    Process sed (pid: 13979, threadinfo ffff880221c36000, task ffff88022e788480)
    Call Trace:
      is_pageblock_removable_nolock+0x34/0x40
      is_mem_section_removable+0x74/0xf0
      show_mem_removable+0x41/0x70
      sysfs_read_file+0xfe/0x1c0
      vfs_read+0xc7/0x130
      sys_read+0x53/0xa0
      system_call_fastpath+0x16/0x1b

    We are crashing because we are trying to dereference NULL zone which
    came from pfn=0 (struct page ffffea0000000000). According to the boot
    log this page is marked reserved:
    e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

    and early_node_map confirms that:
    early_node_map[3] active PFN ranges
        1: 0x00000010 -> 0x0000009c
        1: 0x00000100 -> 0x000bffa3
        1: 0x00100000 -> 0x00240000

    The problem is that memory_present works in PAGE_SECTION_MASK aligned
    blocks so the reserved range sneaks into the the section as well.  This
    also means that free_area_init_node will not take care of those reserved
    pages and they stay uninitialized.

    When we try to read the removable status we walk through all available
    sections and hope that the zone is valid for all pages in the section.
    But this is not true in this case as the zone and nid are not initialized.

    We have only one node in this particular case and it is marked as node=1
    (rather than 0) and that made the problem visible because page_to_nid will
    return 0 and there are no zones on the node.

    Let's check that the zone is valid and that the given pfn falls into its
    boundaries and mark the section not removable.  This might cause some
    false positives, probably, but we do not have any sane way to find out
    whether the page is reserved by the platform or it is just not used for
    whatever other reasons.

    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c2c9f543718e15227a4aa0135e793480b94c4d97
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jan 20 14:34:09 2012 -0800

    proc: clear_refs: do not clear reserved pages

    commit 85e72aa5384b1a614563ad63257ded0e91d1a620 upstream.

    /proc/pid/clear_refs is used to clear the Referenced and YOUNG bits for
    pages and corresponding page table entries of the task with PID pid, which
    includes any special mappings inserted into the page tables in order to
    provide things like vDSOs and user helper functions.

    On ARM this causes a problem because the vectors page is mapped as a
    global mapping and since ec706dab ("ARM: add a vma entry for the user
    accessible vector page"), a VMA is also inserted into each task for this
    page to aid unwinding through signals and syscall restarts.  Since the
    vectors page is required for handling faults, clearing the YOUNG bit (and
    subsequently writing a faulting pte) means that we lose the vectors page
    *globally* and cannot fault it back in.  This results in a system deadlock
    on the next exception.

    To see this problem in action, just run:

    	$ echo 1 > /proc/self/clear_refs

    on an ARM platform (as any user) and watch your system hang.  I think this
    has been the case since 2.6.37

    This patch avoids clearing the aforementioned bits for reserved pages,
    therefore leaving the vectors page intact on ARM.  Since reserved pages
    are not candidates for swap, this change should not have any impact on the
    usefulness of clear_refs.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Reported-by: Moussa Ba <moussaba@micron.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Cc: Matt Mackall <mpm@selenic.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@suse.de>

commit b8f256956a063ebc60a674ec5795c7ca5aaa79c6
Author: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Date:   Fri Jan 20 14:34:04 2012 -0800

    kprobes: initialize before using a hlist

    commit d496aab567e7e52b3e974c9192a5de6e77dce32c upstream.

    Commit ef53d9c5e ("kprobes: improve kretprobe scalability with hashed
    locking") introduced a bug where we can potentially leak
    kretprobe_instances since we initialize a hlist head after having used
    it.

    Initialize the hlist head before using it.

    Reported by: Jim Keniston <jkenisto@us.ibm.com>
    Acked-by: Jim Keniston <jkenisto@us.ibm.com>
    Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
    Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Srinivasa D S <srinivasa@in.ibm.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@suse.de>

commit 72a82010500dea88b2d786a76b063a871e2a4603
Author: Dan Rosenberg <drosenberg@vsecurity.com>
Date:   Fri Jan 20 14:34:27 2012 -0800

    score: fix off-by-one index into syscall table

    commit c25a785d6647984505fa165b5cd84cfc9a95970b upstream.

    If the provided system call number is equal to __NR_syscalls, the
    current check will pass and a function pointer just after the system
    call table may be called, since sys_call_table is an array with total
    size __NR_syscalls.

    Whether or not this is a security bug depends on what the compiler puts
    immediately after the system call table.  It's likely that this won't do
    anything bad because there is an additional NULL check on the syscall
    entry, but if there happens to be a non-NULL value immediately after the
    system call table, this may result in local privilege escalation.

    Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
    Cc: Chen Liqin <liqin.chen@sunplusct.com>
    Cc: Lennox Wu <lennox.wu@gmail.com>
    Cc: Eugene Teo <eugeneteo@kernel.sg>
    Cc: Arnd Bergmann <arnd@arndb.de>
    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@suse.de>

commit a6007c036e0a0e10c0b4dbd533576d201b822a90
Author: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Date:   Mon Sep 26 16:16:23 2011 +0900

    i2c-eg20t: modified the setting of transfer rate.

    commit ff35e8b18984ad2a82cbd259fc07f0be4b34b1aa upstream.

    This patch modified the setting value of
    I2C Bus Transfer Rate Setting Counter regisrer.

    Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
    Signed-off-by: Ben Dooks <ben-linux@fluff.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d7531928ae349a5d59a6820bc3a5e46c9907f5ad
Author: Dirk Eibach <eibach@gdsys.de>
Date:   Tue Oct 18 03:04:11 2011 +0000

    net: Fix driver name for mdio-gpio.c

    commit f42af6c486aa5ca6ee62800cb45c5b252020509d upstream.

    Since commit
    "7488876... dt/net: Eliminate users of of_platform_{,un}register_driver"
    there are two platform drivers named "mdio-gpio" registered.
    I renamed the of variant to "mdio-ofgpio".

    Signed-off-by: Dirk Eibach <eibach@gdsys.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 5e383255dab2f12e7e111e23c057a30955de8cf3
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Fri Jan 6 09:31:20 2012 +0200

    pnfs-obj: Must return layout on IO error

    commit fe0fe83585f88346557868a803a479dfaaa0688a upstream.

    As mandated by the standard. In case of an IO error, a pNFS
    objects layout driver must return it's layout. This is because
    all device errors are reported to the server as part of the
    layout return buffer.

    This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR
    is done, through a bit flag on the pnfs_layoutdriver_type->flags
    member. The flag is set by the layout driver that wants a
    layout_return preformed at pnfs_ld_{write,read}_done in case
    of an error.
    (Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr
     because this code is never called outside of pnfs.c and pnfs IO
     paths)

    Without this patch 3.[0-2] Kernels leak memory and have an annoying
    WARN_ON after every IO error utilizing the pnfs-obj driver.

    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8edf7c13515fa2dee528ab348919058b14454457
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Fri Jan 6 09:28:12 2012 +0200

    pnfs-obj: pNFS errors are communicated on iodata->pnfs_error

    commit 5c0b4129c07b902b27d3f3ebc087757f534a3abd upstream.

    Some time along the way pNFS IO errors were switched to
    communicate with a special iodata->pnfs_error member instead
    of the regular RPC members. But objlayout was not switched
    over.

    Fix that!
    Without this fix any IO error is hanged, because IO is not
    switched to MDS and pages are never cleared or read.

    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ac631973a9ad6bba3d666f687288ebeb819c0df0
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Jan 13 12:59:32 2012 +0100

    rt2800pci: fix spurious interrupts generation

    commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream.

    Same devices can generate interrupt without properly setting bit in
    INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
    will be disabled by interrupts controller driver.

    We discovered that clearing INT_MASK_CSR stops such behaviour. We
    previously first read that register, and then clear all know interrupt
    sources bits and do not touch reserved bits. After this patch, we write
    to all register content (I believe writing to reserved bits on that
    register will not cause any problems, I tested that on my rt2800pci
    device).

    This fix very bad performance problem, practically making device
    unusable (since worked without interrupts), reported in:
    https://bugzilla.redhat.com/show_bug.cgi?id=658451

    We previously tried to workaround that issue in commit
    4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
    interrupts", but it was reverted in commit
    82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
    as thing, that will prevent to detect real spurious interrupts.

    Reported-and-tested-by: Amir Hedayaty <hedayaty@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 415b95df641c998a7cf15c916047f338ab2ce87b
Author: Cliff Wickman <cpw@sgi.com>
Date:   Mon Jan 16 15:18:48 2012 -0600

    x86/UV2: Fix BAU destination timeout initialization

    commit d059f9fa84a30e04279c6ff615e9e2cf3b260191 upstream.

    Move the call to enable_timeouts() forward so that
    BAU_MISC_CONTROL is initialized before using it in
    calculate_destination_timeout().

    Fix the calculation of a BAU destination timeout
    for UV2 (in calculate_destination_timeout()).

    Signed-off-by: Cliff Wickman <cpw@sgi.com>
    Link: http://lkml.kernel.org/r/20120116211848.GB5767@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 6c8e76e158a9bc849ec946ab030595e06ad89210
Author: Alexander Aring <a.aring@phytec.de>
Date:   Thu Dec 8 15:43:53 2011 +0100

    I2C: OMAP: correct SYSC register offset for OMAP4

    commit 2727b1753934e154931d6b3bdf20c9b2398457a2 upstream.

    Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
    Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset.

    Signed-off-by: Alexander Aring <a.aring@phytec.de>
    [khilman@ti.com: minor changelog edits]
    Signed-off-by: Kevin Hilman <khilman@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 06a23648ebbb532745eb85c1a381b83dd90e94af
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Dec 13 14:55:33 2011 -0800

    target: Set additional sense length field in sense data

    commit 895f3022523361e9b383cf48f51feb1f7d5e7e53 upstream.

    The target code was not setting the additional sense length field in the
    sense data it returned, which meant that at least the Linux stack
    ignored the ASC/ASCQ fields.  For example, without this patch, on a
    tcm_loop device:

        # sg_raw -v /dev/sda 2 0 0 0 0 0

    gives

            cdb to send: 02 00 00 00 00 00
        SCSI Status: Check Condition

        Sense Information:
         Fixed format, current;  Sense key: Illegal Request
          Raw sense data (in hex):
                70 00 05 00 00 00 00 00

    while after the patch we correctly get the following (which matches what
    a regular disk returns):

            cdb to send: 02 00 00 00 00 00
        SCSI Status: Check Condition

        Sense Information:
         Fixed format, current;  Sense key: Illegal Request
         Additional sense: Invalid command operation code
         Raw sense data (in hex):
                70 00 05 00 00 00 00 0a  00 00 00 00 20 00 00 00
                00 00

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 640bb6ec4ff89b0349d1c7cb42aa25db191b4f63
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Dec 6 10:02:09 2011 -0800

    target: Set response format in INQUIRY response

    commit ce136176fea522fc8f4c16dcae7e8ed1d890ca39 upstream.

    Current SCSI specs say that the "response format" field in the standard
    INQUIRY response should be set to 2, and all the real SCSI devices I
    have do put 2 here.  So let's do that too.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 7b3e8a2073d9875dbdcdfec5d40ff54c8e8c418c
Author: Stratos Psomadakis <psomas@gentoo.org>
Date:   Sun Dec 4 02:23:54 2011 +0200

    sym53c8xx: Fix NULL pointer dereference in slave_destroy

    commit cced5041ed5a2d1352186510944b0ddfbdbe4c0b upstream.

    sym53c8xx_slave_destroy unconditionally assumes that sym53c8xx_slave_alloc has
    succesesfully allocated a sym_lcb. This can lead to a NULL pointer dereference
    (exposed by commit 4e6c82b).

    Signed-off-by: Stratos Psomadakis <psomas@gentoo.org>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 68e6689b9b35c8a2fa73e00947238d2c5cb0387c
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Tue Dec 13 09:36:03 2011 +0800

    ACPI: processor: fix acpi_get_cpuid for UP processor

    commit d640113fe80e45ebd4a5b420b220d3f6bf37f682 upstream.

    For UP processor, it is likely that no _MAT method or MADT table defined.
    So currently acpi_get_cpuid(...) always return -1 for UP processor.
    This is wrong. It should return valid value for CPU0.

    In the other hand, BIOS may define multiple CPU handles even for UP
    processor, for example

            Scope (_PR)
            {
                Processor (CPU0, 0x00, 0x00000410, 0x06) {}
                Processor (CPU1, 0x01, 0x00000410, 0x06) {}
                Processor (CPU2, 0x02, 0x00000410, 0x06) {}
                Processor (CPU3, 0x03, 0x00000410, 0x06) {}
            }

    We should only return valid value for CPU0's acpi handle.
    And return invalid value for others.

    http://marc.info/?t=132329819900003&r=1&w=2

    Reported-and-tested-by: wallak@free.fr
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 55bd02eb4c6e40c2870aee19c5e36d1a85713be8
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Tue Nov 29 22:13:35 2011 +0800

    ACPICA: Put back the call to acpi_os_validate_address

    commit da4d8b287abe783d30e968155614531a0937d090 upstream.

    The call to acpi_os_validate_address in acpi_ds_get_region_arguments was
    removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and
    dsload.c files).

    Put it back.

    Reported-and-bisected-by: Luca Tettamanti <kronos.it@gmail.com>
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0076d42a31bac7853d3c77c3858d2685f6fe8f2d
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Jan 17 04:21:49 2012 -0500

    ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)

    commit 9f10f6a520deb3639fac78d81151a3ade88b4e7f upstream.

    In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
    32bits for these. The new fields were reserved before.
    According to the ACPI spec, the OS must disregrard reserved fields.

    ia64 did handle the PXM fields almost consistently, but depending on
    sgi's sn2 platform. This patch leaves the sn2 logic in, but does also
    use 16/32 bits for PXM if the SRAT has rev 2 or higher.

    The patch also adds __init to the two pxm accessor functions, as they
    access __initdata now and are called from an __init function only anyway.

    Note that the code only uses 16 bits for the PXM field in the processor
    proximity field; the patch does not address this as 16 bits are more than
    enough.

    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ef9a04d5b336853aeb3f3975c4e52b07c1c4d3ec
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Jan 17 04:20:31 2012 -0500

    ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)

    commit cd298f60a2451a16e0f077404bf69b62ec868733 upstream.

    In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
    32bits for these. The new fields were reserved before.
    According to the ACPI spec, the OS must disregrard reserved fields.

    x86/x86-64 was rather inconsistent prior to this patch; it used 8 bits
    for the pxm field in cpu_affinity, but 32 bits in mem_affinity.
    This patch makes it consistent: Either use 8 bits consistently (SRAT
    rev 1 or lower) or 32 bits (SRAT rev 2 or higher).

    cc: x86@kernel.org
    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 643147c50fde7eb0456953f468cc277d621f629e
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Jan 17 04:18:02 2012 -0500

    ACPI: Store SRAT table revision

    commit 8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 upstream.

    In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
    32bits for these. The new fields were reserved before.
    According to the ACPI spec, the OS must disregrard reserved fields.
    In order to know whether or not, we must know what version the SRAT
    table has.

    This patch stores the SRAT table revision for later consumption
    by arch specific __init functions.

    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e26a6033d0d0183e613a1ae5eafefd3baf7f3e6c
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Tue Jan 10 15:48:19 2012 -0800

    intel_idle: fix API misuse

    commit 39a74fdedd1c1461d6fb6d330b5266886513c98f upstream.

    smp_call_function() only lets all other CPUs execute a specific function,
    while we expect all CPUs do in intel_idle.  Without the fix, we could have
    one cpu which has auto_demotion enabled or has no broadcast timer setup.
    Usually we don't see impact because auto demotion just harms power and the
    intel_idle init is called in CPU 0, where boradcast timer delivers
    interrupt, but this still could be a problem.

    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 57700d3c569071c4c43f220de637461850d027a1
Author: Thomas Renninger <trenn@suse.de>
Date:   Sun Dec 4 22:17:29 2011 +0100

    intel idle: Make idle driver more robust

    commit 5c2a9f06a9cd7194f884cdc88144866235dec07d upstream.

    kvm -cpu host passes the original cpuid info to the guest.

    Latest kvm version seem to return true for mwait_leaf cpuid
    function on recent Intel CPUs. But it does not return mwait
    C-states (mwait_substates), instead zero is returned.

    While real CPUs seem to always return non-zero values, the intel
    idle driver should not get active in kvm (mwait_substates == 0)
    case and bail out.
    Otherwise a Null pointer exception will happen later when the
    cpuidle subsystem tries to get active:
    [0.984807] BUG: unable to handle kernel NULL pointer dereference at (null)
    [0.984807] IP: [<(null)>] (null)
    ...
    [0.984807][<ffffffff8143cf34>] ? cpuidle_idle_call+0xb4/0x340
    [0.984807][<ffffffff8159e7bc>] ? __atomic_notifier_call_chain+0x4c/0x70
    [0.984807][<ffffffff81001198>] ? cpu_idle+0x78/0xd0

    Reference:
    https://bugzilla.novell.com/show_bug.cgi?id=726296

    Signed-off-by: Thomas Renninger <trenn@suse.de>
    CC: Bruno Friedmann <bruno@ioda-net.ch>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit db52a757b355ec71670b4b0f85cd2d6f28306a79
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Jan 16 10:52:20 2012 +0100

    ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645

    commit ffe535edb9a9c5b4d5fe03dfa3d89a1495580f1b upstream.

    More than one user reports that changing the model from "both" to
    "dmic" makes their Internal Mic work.

    Tested-by: Martin Ling <martin-launchpad@earth.li>
    BugLink: https://bugs.launchpad.net/bugs/795823
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit cb86f0a0920b63b179d2fa653c6c851db27d069a
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Jan 14 16:42:24 2012 +0100

    ALSA: virtuoso: Xonar DS: fix polarity of front output

    commit f0e48b6bd4e407459715240cd241ddb6b89bdf81 upstream.

    The two DACs for the front output and the surround/center/LFE/back
    outputs are wired up out of phase, so when channels are duplicated,
    their sound can cancel out each other and result in a weaker bass
    response.  To fix this, reverse the polarity of the neutron flow to
    the front output.

    Reported-any-tested-by: Daniel Hill <daniel@enemyplanet.geek.nz>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c8fec258e5d1c35712795641350cc78da4334629
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Jan 17 15:21:19 2012 -0800

    proc: clean up and fix /proc/<pid>/mem handling

    commit e268337dfe26dfc7efd422a804dbb27977a3cccc upstream.

    Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
    robust, and it also doesn't match the permission checking of any of the
    other related files.

    This changes it to do the permission checks at open time, and instead of
    tracking the process, it tracks the VM at the time of the open.  That
    simplifies the code a lot, but does mean that if you hold the file
    descriptor open over an execve(), you'll continue to read from the _old_
    VM.

    That is different from our previous behavior, but much simpler.  If
    somebody actually finds a load where this matters, we'll need to revert
    this commit.

    I suspect that nobody will ever notice - because the process mapping
    addresses will also have changed as part of the execve.  So you cannot
    actually usefully access the fd across a VM change simply because all
    the offsets for IO would have changed too.

    Reported-by: Jüri Aedla <asd@ut.ee>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 12c3b3ac1e8004616b30aec6acee1bb91badeb99
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 12 16:01:29 2012 +0100

    dm: do not forward ioctls from logical volumes to the underlying device

    commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.

    A logical volume can map to just part of underlying physical volume.
    In this case, it must be treated like a partition.

    Based on a patch from Alasdair G Kergon.

    Cc: Alasdair G Kergon <agk@redhat.com>
    Cc: dm-devel@redhat.com
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8bd8442fec18284924e17a0fa8ef89d98b0a6d71
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 12 16:01:28 2012 +0100

    block: fail SCSI passthrough ioctls on partition devices

    commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

    [ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
      and -ENOIOCTLCMD from sd_compat_ioctl. ]

    Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
    will pass the command to the underlying block device.  This is
    well-known, but it is also a large security problem when (via Unix
    permissions, ACLs, SELinux or a combination thereof) a program or user
    needs to be granted access only to part of the disk.

    This patch lets partitions forward a small set of harmless ioctls;
    others are logged with printk so that we can see which ioctls are
    actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
    Of course it was being sent to a (partition on a) hard disk, so it would
    have failed with ENOTTY and the patch isn't changing anything in
    practice.  Still, I'm treating it specially to avoid spamming the logs.

    In principle, this restriction should include programs running with
    CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
    /dev/sdb, it still should not be able to read/write outside the
    boundaries of /dev/sda2 independent of the capabilities.  However, for
    now programs with CAP_SYS_RAWIO will still be allowed to send the
    ioctls.  Their actions will still be logged.

    This patch does not affect the non-libata IDE driver.  That driver
    however already tests for bd != bd->bd_contains before issuing some
    ioctl; it could be restricted further to forbid these ioctls even for
    programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

    Cc: linux-scsi@vger.kernel.org
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: James Bottomley <JBottomley@parallels.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [ Make it also print the command name when warning - Linus ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3b8373b85c761b2a12bdaf9fcee4c7a3eefa8459
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 12 16:01:27 2012 +0100

    block: add and use scsi_blk_cmd_ioctl

    commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream.

    Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

    The function will then be enhanced to detect partition block devices
    and, in that case, subject the ioctls to whitelisting.

    Cc: linux-scsi@vger.kernel.org
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: James Bottomley <JBottomley@parallels.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 3ec3f83aee534f732fd7012ff6c04776952e47fd
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Thu Dec 15 14:56:10 2011 +0100

    fix cputime overflow in uptime_proc_show

    commit c3e0ef9a298e028a82ada28101ccd5cf64d209ee upstream.

    For 32-bit architectures using standard jiffies the idletime calculation
    in uptime_proc_show will quickly overflow. It takes (2^32 / HZ) seconds
    of idle-time, or e.g. 12.45 days with no load on a quad-core with HZ=1000.
    Switch to 64-bit calculations.

    Cc: Michael Abbott <michael.abbott@diamond.ac.uk>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 277a05f83af8c82291cf5f2ad0c2dd1aa6f29de7
Author: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Date:   Fri Dec 23 15:41:00 2011 +0100

    HID: multitouch: add support for 3M 32"

    commit c4fad877cd0efb51d8180ae2eaa791c99c92051c upstream.

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Acked-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1628de01ac388c9104ddc2816491ff591dfe28a8
Author: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Date:   Wed Nov 23 10:54:33 2011 +0100

    HID: multitouch: add support for the MSI Windpad 110W

    commit 66f06127f34ad6e8a1b24a2c03144b694d19f99f upstream.

    Just another eGalax device.
    Please note that adding this device to have_special_driver
    in hid-core.c is not required anymore.

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a92035b63540e2d47326540dc38625283143b770
Author: Marek Vasut <marek.vasut@gmail.com>
Date:   Wed Nov 23 10:54:32 2011 +0100

    HID: multitouch: Add egalax ID for Acer Iconia W500

    commit bb9ff21072043634f147c05ac65dbf8185d4af6d upstream.

    This patch adds USB ID for the touchpanel in Acer Iconia W500. The panel
    supports up to five fingers, therefore the need for a new addition of panel
    types.

    Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 369f7532bcaa78eb3919306e1ff997aa14bbfbbb
Author: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Date:   Wed Nov 23 10:54:31 2011 +0100

    HID: multitouch: cleanup with eGalax PID definitions

    commit e36f690b37945e0a9bb1554e1546eeec93f7d1f6 upstream.

    This is just a renaming of USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH{N}
    to USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_{PID} to handle more eGalax
    devices.

    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 242d5138b1a8f4a2519518027fff884fce3eeba4
Author: Chris Bagwell <chris@cnpbagwell.com>
Date:   Wed Nov 23 10:54:27 2011 +0100

    HID: hid-multitouch - add another eGalax id

    commit 1fd8f047490dd0ec4e4db710fcbc1bd4798d944c upstream.

    This allows ASUS Eee Slate touchscreens to work.

    Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c0ab420c6822529fa5aba05668e1e983b065460f
Author: Nick Bowler <nbowler@elliptictech.com>
Date:   Tue Nov 8 12:12:45 2011 +0000

    ah: Read nexthdr value before overwriting it in ahash input callback.

    commit b7ea81a58adc123a4e980cb0eff9eb5c144b5dc7 upstream.

    The AH4/6 ahash input callbacks read out the nexthdr field from the AH
    header *after* they overwrite that header.  This is obviously not going
    to end well.  Fix it up.

    Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d253520a7b2c2223fb4f704f06d10f2c547bdeef
Author: Nick Bowler <nbowler@elliptictech.com>
Date:   Tue Nov 8 12:12:44 2011 +0000

    ah: Correctly pass error codes in ahash output callback.

    commit 069294e813ed5f27f82613b027609bcda5f1b914 upstream.

    The AH4/6 ahash output callbacks pass nexthdr to xfrm_output_resume
    instead of the error code.  This appears to be a copy+paste error from
    the input case, where nexthdr is expected.  This causes the driver to
    continuously add AH headers to the datagram until either an allocation
    fails and the packet is dropped or the ahash driver hits a synchronous
    fallback and the resulting monstrosity is transmitted.

    Correct this issue by simply passing the error code unadulterated.

    Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8039a47e67451b8efd6100c4a7f27829fc2d8edd
Author: Miklos Szeredi <miklos@szeredi.hu>
Date:   Tue Jan 10 18:22:25 2012 +0100

    fix shrink_dcache_parent() livelock

    commit eaf5f9073533cde21c7121c136f1c3f072d9cf59 upstream.

    Two (or more) concurrent calls of shrink_dcache_parent() on the same dentry may
    cause shrink_dcache_parent() to loop forever.

    Here's what appears to happen:

    1 - CPU0: select_parent(P) finds C and puts it on dispose list, returns 1

    2 - CPU1: select_parent(P) locks P->d_lock

    3 - CPU0: shrink_dentry_list() locks C->d_lock
       dentry_kill(C) tries to lock P->d_lock but fails, unlocks C->d_lock

    4 - CPU1: select_parent(P) locks C->d_lock,
             moves C from dispose list being processed on CPU0 to the new
    dispose list, returns 1

    5 - CPU0: shrink_dentry_list() finds dispose list empty, returns

    6 - Goto 2 with CPU0 and CPU1 switched

    Basically select_parent() steals the dentry from shrink_dentry_list() and thinks
    it found a new one, causing shrink_dentry_list() to think it's making progress
    and loop over and over.

    One way to trigger this is to make udev calls stat() on the sysfs file while it
    is going away.

    Having a file in /lib/udev/rules.d/ with only this one rule seems to the trick:

    ATTR{vendor}=="0x8086", ATTR{device}=="0x10ca", ENV{PCI_SLOT_NAME}="%k", ENV{MATCHADDR}="$attr{address}", RUN+="/bin/true"

    Then execute the following loop:

    while true; do
            echo -bond0 > /sys/class/net/bonding_masters
            echo +bond0 > /sys/class/net/bonding_masters
            echo -bond1 > /sys/class/net/bonding_masters
            echo +bond1 > /sys/class/net/bonding_masters
    done

    One fix would be to check all callers and prevent concurrent calls to
    shrink_dcache_parent().  But I think a better solution is to stop the
    stealing behavior.

    This patch adds a new dentry flag that is set when the dentry is added to the
    dispose list.  The flag is cleared in dentry_lru_del() in case the dentry gets a
    new reference just before being pruned.

    If the dentry has this flag, select_parent() will skip it and let
    shrink_dentry_list() retry pruning it.  With select_parent() skipping those
    dentries there will not be the appearance of progress (new dentries found) when
    there is none, hence shrink_dcache_parent() will not loop forever.

    Set the flag is also set in prune_dcache_sb() for consistency as suggested by
    Linus.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 087bc746ef05511c3e416846a8eae4588756462c
Author: Haogang Chen <haogangchen@gmail.com>
Date:   Tue Nov 29 18:32:25 2011 -0300

    uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map()

    commit 806e23e95f94a27ee445022d724060b9b45cb64a upstream.

    There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
    large xmap->menu_count is passed from the userspace, the subsequent call
    to kmalloc() will allocate a buffer smaller than expected.
    map->menu_count and map->menu_info would later be used in a loop (e.g.
    in uvc_query_v4l2_ctrl), which leads to out-of-bound access.

    The patch checks the ioctl argument and returns -EINVAL for zero or too
    large values in xmap->menu_count.

    Signed-off-by: Haogang Chen <haogangchen@gmail.com>
    [laurent.pinchart@ideasonboard.com Prevent excessive memory consumption]
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9d3f99878bf33d36739bd772c7dafcb1f71387fb
Author: David Daney <david.daney@cavium.com>
Date:   Mon Dec 19 17:42:42 2011 -0800

    recordmcount: Fix handling of elf64 big-endian objects.

    commit 2e885057b7f75035f0b85e02f737891482815a81 upstream.

    In ELF64, the sh_flags field is 64-bits wide.  recordmcount was
    erroneously treating it as a 32-bit wide field.  For little endian
    objects this works because the flags of interest (SHF_EXECINSTR)
    reside in the lower 32 bits of the word, and you get the same result
    with either a 32-bit or 64-bit read.  Big endian objects on the
    other hand do not work at all with this error.

    The fix:  Correctly treat sh_flags as 64-bits wide in elf64 objects.

    The symptom I observed was that my
    __start_mcount_loc..__stop_mcount_loc was empty even though ftrace
    function tracing was enabled.

    Link: http://lkml.kernel.org/r/1324345362-12230-1-git-send-email-ddaney.cavm@gmail.com

    Signed-off-by: David Daney <david.daney@cavium.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 15274414badc6ef0a893454e7102f3753f2c1ccd
Author: Jack Steiner <steiner@sgi.com>
Date:   Fri Jan 6 13:19:00 2012 -0600

    x86, UV: Update Boot messages for SGI UV2 platform

    commit da517a08ac5913cd80ce3507cddd00f2a091b13c upstream.

    SGI UV systems print a message during boot:

    	UV: Found <num> blades

    Due to packaging changes, the blade count is not accurate for
    on the next generation of the platform. This patch corrects the
    count.

    Signed-off-by: Jack Steiner <steiner@sgi.com>
    Link: http://lkml.kernel.org/r/20120106191900.GA19772@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a9680ece8e3874382fb2db1b8e247452c306b735
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Thu Jan 12 17:59:46 2012 +0100

    fsnotify: don't BUG in fsnotify_destroy_mark()

    commit fed474857efbed79cd390d0aee224231ca718f63 upstream.

    Removing the parent of a watched file results in "kernel BUG at
    fs/notify/mark.c:139".

    To reproduce

      add "-w /tmp/audit/dir/watched_file" to audit.rules
      rm -rf /tmp/audit/dir

    This is caused by fsnotify_destroy_mark() being called without an
    extra reference taken by the caller.

    Reported by Francesco Cosoleto here:

      https://bugzilla.novell.com/show_bug.cgi?id=689860

    Fix by removing the BUG_ON and adding a comment about not accessing mark after
    the iput.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 46a5392ffcb492b8042776ce44b5cc1c07be1b23
Author: Sasha Levin <levinsasha928@gmail.com>
Date:   Fri Nov 18 12:14:49 2011 +0200

    nfsd: Fix oops when parsing a 0 length export

    commit b2ea70afade7080360ac55c4e64ff7a5fafdb67b upstream.

    expkey_parse() oopses when handling a 0 length export. This is easily
    triggerable from usermode by writing 0 bytes into
    '/proc/[proc id]/net/rpc/nfsd.fh/channel'.

    Below is the log:

    [ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff
    [ 1402.287632] IP: [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
    [ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160
    [ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    [ 1402.287632] CPU 1
    [ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6
    [ 1402.287632] RIP: 0010:[<ffffffff812b4b99>]  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
    [ 1402.287632] RSP: 0018:ffff880077f0fd68  EFLAGS: 00010292
    [ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400
    [ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0
    [ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000
    [ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000
    [ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0
    [ 1402.287632] FS:  00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
    [ 1402.287632] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0
    [ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0)
    [ 1402.287632] Stack:
    [ 1402.287632]  ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e
    [ 1402.287632]  ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0
    [ 1402.287632]  0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63
    [ 1402.287632] Call Trace:
    [ 1402.287632]  [<ffffffff810b411e>] ? lock_release+0x1af/0x1bc
    [ 1402.287632]  [<ffffffff81111f63>] ? might_fault+0x97/0x9e
    [ 1402.287632]  [<ffffffff81111f1a>] ? might_fault+0x4e/0x9e
    [ 1402.287632]  [<ffffffff81a8bcf2>] cache_do_downcall+0x3e/0x4f
    [ 1402.287632]  [<ffffffff81a8c950>] cache_write.clone.16+0xbb/0x130
    [ 1402.287632]  [<ffffffff81a8c9df>] ? cache_write_pipefs+0x1a/0x1a
    [ 1402.287632]  [<ffffffff81a8c9f8>] cache_write_procfs+0x19/0x1b
    [ 1402.287632]  [<ffffffff8118dc54>] proc_reg_write+0x8e/0xad
    [ 1402.287632]  [<ffffffff8113fe81>] vfs_write+0xaa/0xfd
    [ 1402.287632]  [<ffffffff8114142d>] ? fget_light+0x35/0x9e
    [ 1402.287632]  [<ffffffff8113ff8b>] sys_write+0x48/0x6f
    [ 1402.287632]  [<ffffffff81bbdb92>] system_call_fastpath+0x16/0x1b
    [ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff
    [ 1402.287632]  38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85
    [ 1402.287632] RIP  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
    [ 1402.287632]  RSP <ffff880077f0fd68>
    [ 1402.287632] CR2: ffff880077c49fff
    [ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]---

    Cc: "J. Bruce Fields" <bfields@fieldses.org>
    Cc: Neil Brown <neilb@suse.de>
    Cc: linux-nfs@vger.kernel.org
    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a141a5eb3ab45131cb168e7a561d662722b43ec3
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Nov 29 17:00:26 2011 -0500

    svcrpc: avoid memory-corruption on pool shutdown

    commit b4f36f88b3ee7cf26bf0be84e6c7fc15f84dcb71 upstream.

    Socket callbacks use svc_xprt_enqueue() to add an xprt to a
    pool->sp_sockets list.  In normal operation a server thread will later
    come along and take the xprt off that list.  On shutdown, after all the
    threads have exited, we instead manually walk the sv_tempsocks and
    sv_permsocks lists to find all the xprt's and delete them.

    So the sp_sockets lists don't really matter any more.  As a result,
    we've mostly just ignored them and hoped they would go away.

    Which has gotten us into trouble; witness for example ebc63e531cc6
    "svcrpc: fix list-corrupting race on nfsd shutdown", the result of Ben
    Greear noticing that a still-running svc_xprt_enqueue() could re-add an
    xprt to an sp_sockets list just before it was deleted.  The fix was to
    remove it from the list at the end of svc_delete_xprt().  But that only
    made corruption less likely--I can see nothing that prevents a
    svc_xprt_enqueue() from adding another xprt to the list at the same
    moment that we're removing this xprt from the list.  In fact, despite
    the earlier xpo_detach(), I don't even see what guarantees that
    svc_xprt_enqueue() couldn't still be running on this xprt.

    So, instead, note that svc_xprt_enqueue() essentially does:
    	lock sp_lock
    		if XPT_BUSY unset
    			add to sp_sockets
    	unlock sp_lock

    So, if we do:

    	set XPT_BUSY on every xprt.
    	Empty every sp_sockets list, under the sp_socks locks.

    Then we're left knowing that the sp_sockets lists are all empty and will
    stay that way, since any svc_xprt_enqueue() will check XPT_BUSY under
    the sp_lock and see it set.

    And *then* we can continue deleting the xprt's.

    (Thanks to Jeff Layton for being correctly suspicious of this code....)

    Cc: Ben Greear <greearb@candelatech.com>
    Cc: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 7df22768c0af8769d805f6db21144d71d91fe13d
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Nov 29 11:35:35 2011 -0500

    svcrpc: destroy server sockets all at once

    commit 2fefb8a09e7ed251ae8996e0c69066e74c5aa560 upstream.

    There's no reason I can see that we need to call sv_shutdown between
    closing the two lists of sockets.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b09577ca6680033a4315e2f5cb3a95ebbb8dea79
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Dec 22 18:22:49 2011 -0700

    svcrpc: fix double-free on shutdown of nfsd after changing pool mode

    commit 61c8504c428edcebf23b97775a129c5b393a302b upstream.

    The pool_to and to_pool fields of the global svc_pool_map are freed on
    shutdown, but are initialized in nfsd startup only in the
    SVC_POOL_PERCPU and SVC_POOL_PERNODE cases.

    They *are* initialized to zero on kernel startup.  So as long as you use
    only SVC_POOL_GLOBAL (the default), this will never be a problem.

    You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE.

    However, the following sequence events leads to a double-free:

    	1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE
    	2. start nfsd: both fields are initialized.
    	3. shutdown nfsd: both fields are freed.
    	4. set SVC_POOL_GLOBAL
    	5. start nfsd: the fields are left untouched.
    	6. shutdown nfsd: now we try to free them again.

    Step 4 is actually unnecessary, since (for some bizarre reason), nfsd
    automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit adc0186cfa38e2736048a638681db511e65e51fd
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Fri Jan 13 17:53:40 2012 -0500

    kconfig/streamline-config.pl: Fix parsing Makefile with variables

    commit 364212fddaaa60c5a64f67a0f5624ad996ecc8a0 upstream.

    Thomas Lange reported that when he did a 'make localmodconfig', his
    config was missing the brcmsmac driver, even though he had the module
    loaded.

    Looking into this, I found the file:
    drivers/net/wireless/brcm80211/brcmsmac/Makefile
    had the following in the Makefile:

    MODULEPFX := brcmsmac

    obj-$(CONFIG_BRCMSMAC)  += $(MODULEPFX).o

    The way streamline-config.pl works, is parsing all the
     obj-$(CONFIG_FOO) += foo.o
    lines to find that CONFIG_FOO belongs to the module foo.ko.

    But in this case, the brcmsmac.o was not used, but a variable in its place.

    By changing streamline-config.pl to remember defined variables in Makefiles
    and substituting them when they are used in the obj-X lines, allows
    Thomas (and others) to have their brcmsmac module stay configured
    when it is loaded and running "make localmodconfig".

    Reported-by: Thomas Lange <thomas-lange2@gmx.de>
    Tested-by: Thomas Lange <thomas-lange2@gmx.de>
    Cc: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit e5303c25bfacd745f6c6b99a2604ef4e11926c34
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Fri Jan 13 17:50:39 2012 -0500

    kconfig/streamline-config.pl: Simplify backslash line concatination

    commit d060d963e88f3e990cec2fe5214de49de9a49eca upstream.

    Simplify the way lines ending with backslashes (continuation) in Makefiles
    is parsed. This is needed to implement a necessary fix.

    Tested-by: Thomas Lange <thomas-lange2@gmx.de>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 065449fd56d2f75cc943a6d501b292f6b0e40325
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 5 02:27:57 2012 -0300

    V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()

    commit 6c06108be53ca5e94d8b0e93883d534dd9079646 upstream.

    If ctrls->count is too high the multiplication could overflow and
    array_size would be lower than expected.  Mauro and Hans Verkuil
    suggested that we cap it at 1024.  That comes from the maximum
    number of controls with lots of room for expantion.

    $ grep V4L2_CID include/linux/videodev2.h | wc -l
    211

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b1830247c9927d7d2ca17c9f84908fc130051792
Author: Alexander Elbs <alex@segv.de>
Date:   Tue Jan 3 23:26:53 2012 -0500

    mmc: sd: Fix SDR12 timing regression

    commit dd8df17fe83483d7ea06ff229895e35a42071599 upstream.

    This patch fixes a failure to recognize SD cards reported on a Dell
    Vostro with O2 Micro SD card reader.  Patch 49c468f ("mmc: sd: add
    support for uhs bus speed mode selection") caused the problem, by
    setting the SDHCI_CTRL_HISPD flag even for legacy timings.

    Signed-off-by: Alexander Elbs <alex@segv.de>
    Acked-by: Philip Rakity <prakity@marvell.com>
    Acked-by: Arindam Nath <arindam.nath@amd.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 62a0e438f7275e845bfbcccd6e641e07d4b89182
Author: Aaron Lu <aaron.lu@amd.com>
Date:   Wed Dec 28 11:11:12 2011 +0800

    mmc: sdhci: Fix tuning timer incorrect setting when suspending host

    commit c6ced0db08010ed75df221a2946c5228454b38d5 upstream.

    When suspending host, the tuning timer shoule be deactivated.
    And the HOST_NEEDS_TUNING flag should be set after tuning timer is
    deactivated.

    Signed-off-by: Philip Rakity <prakity@marvell.com>
    Signed-off-by: Aaron Lu <aaron.lu@amd.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 1cfbbb9ba574157c9f2312d3267762fdde0bfc59
Author: Girish K S <girish.shivananjappa@linaro.org>
Date:   Thu Dec 15 17:27:42 2011 +0530

    mmc: core: Fix voltage select in DDR mode

    commit 913047e9e5787a90696533a9f109552b7694ecc9 upstream.

    This patch fixes the wrong comparison before setting the interface
    voltage in DDR mode.

    The assignment to the variable ddr before comaprison is either
    ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the comparison
    is done with the extended csd value if ddr == EXT_CSD_CARD_TYPE_DDR_1_2V.

    Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
    Acked-by: Subhash Jadavani <subhashj@codeaurora.org>
    Acked-by: Philip Rakity <prakity@marvell.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit fcf53a1ed4225c1f23997ef02f2770a39e73c515
Author: Jean Delvare <khali@linux-fr.org>
Date:   Thu Jan 12 20:32:03 2012 +0100

    i2c: Fix error value returned by several bus drivers

    commit 7c1f59c9d5caf3a84f35549b5d58f3c055a68da5 upstream.

    When adding checks for ACPI resource conflicts to many bus drivers,
    not enough attention was paid to the error paths, and for several
    drivers this causes 0 to be returned on error in some cases. Fix this
    by properly returning a non-zero value on every error.

    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 8aee2e296d19910d8ad4c676970f0055abc5b5e5
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Tue Jan 10 19:32:30 2012 +0200

    UBIFS: fix debugging messages

    commit d34315da9146253351146140ea4b277193ee5e5f upstream.

    Patch 56e46742e846e4de167dde0e1e1071ace1c882a5 broke UBIFS debugging messages:
    before that commit when UBIFS debugging was enabled, users saw few useful
    debugging messages after mount. However, that patch turned 'dbg_msg()' into
    'pr_debug()', so to enable the debugging messages users have to enable them
    first via /sys/kernel/debug/dynamic_debug/control, which is very impractical.

    This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just
    as it was before the breakage.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit d8ece1b43acdec47c0823aa306910239754ef9e9
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Tue Jan 10 19:32:30 2012 +0200

    UBI: fix debugging messages

    commit 72f0d453d81d35087b1d3ad7c8285628c2be6e1d upstream.

    Patch ab50ff684707031ed4bad2fdd313208ae392e5bb broke UBI debugging messages:
    before that commit when UBI debugging was enabled, users saw few useful
    debugging messages after attaching an MTD device. However, that patch turned
    'dbg_msg()' into 'pr_debug()', so to enable the debugging messages users have
    to enable them first via /sys/kernel/debug/dynamic_debug/control, which is
    very impractical.

    This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just
    as it was before the breakage.

    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 028bb43eac25b7423198b7e22cfea9bd3e870e24
Author: Richard Weinberger <richard@nod.at>
Date:   Fri Jan 13 15:07:40 2012 +0100

    UBI: fix nameless volumes handling

    commit 4a59c797a18917a5cf3ff7ade296b46134d91e6a upstream.

    Currently it's possible to create a volume without a name. E.g:
    ubimkvol -n 32 -s 2MiB -t static /dev/ubi0 -N ""

    After that vtbl_check() will always fail because it does not permit
    empty strings.

    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 59c43b2c3ef410e585646825ea552507cd51ccb1
Author: Ludwig Nussel <ludwig.nussel@suse.de>
Date:   Tue Nov 15 14:46:46 2011 -0800

    x86: Fix mmap random address range

    commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream.

    On x86_32 casting the unsigned int result of get_random_int() to
    long may result in a negative value.  On x86_32 the range of
    mmap_rnd() therefore was -255 to 255.  The 32bit mode on x86_64
    used 0 to 255 as intended.

    The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
    in January 2008.

    Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: harvey.harrison@gmail.com
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Harvey Harrison <harvey.harrison@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ea1c62778121f6ece5e0120250716b45e204cb13
Author: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Date:   Thu Jan 12 17:17:44 2012 -0800

    memcg: add mem_cgroup_replace_page_cache() to fix LRU issue

    commit ab936cbcd02072a34b60d268f94440fd5cf1970b upstream.

    Commit ef6a3c6311 ("mm: add replace_page_cache_page() function") added a
    function replace_page_cache_page().  This function replaces a page in the
    radix-tree with a new page.  WHen doing this, memory cgroup needs to fix
    up the accounting information.  memcg need to check PCG_USED bit etc.

    In some(many?) cases, 'newpage' is on LRU before calling
    replace_page_cache().  So, memcg's LRU accounting information should be
    fixed, too.

    This patch adds mem_cgroup_replace_page_cache() and removes the old hooks.
     In that function, old pages will be unaccounted without touching
    res_counter and new page will be accounted to the memcg (of old page).
    WHen overwriting pc->mem_cgroup of newpage, take zone->lru_lock and avoid
    races with LRU handling.

    Background:
      replace_page_cache_page() is called by FUSE code in its splice() handling.
      Here, 'newpage' is replacing oldpage but this newpage is not a newly allocated
      page and may be on LRU. LRU mis-accounting will be critical for memory cgroup
      because rmdir() checks the whole LRU is empty and there is no account leak.
      If a page is on the other LRU than it should be, rmdir() will fail.

    This bug was added in March 2011, but no bug report yet.  I guess there
    are not many people who use memcg and FUSE at the same time with upstream
    kernels.

    The result of this bug is that admin cannot destroy a memcg because of
    account leak.  So, no panic, no deadlock.  And, even if an active cgroup
    exist, umount can succseed.  So no problem at shutdown.

    Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b9e11747e1227d7ad67c5b80be4b206e4059687e
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Jan 11 09:26:54 2012 +0100

    mac80211: fix rx->key NULL pointer dereference in promiscuous mode

    commit 1140afa862842ac3e56678693050760edc4ecde9 upstream.

    Since:

    commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
    Author: Christian Lamparter <chunkeey@googlemail.com>
    Date:   Sat Apr 30 15:24:30 2011 +0200

        mac80211: consolidate MIC failure report handling

    is possible to that we dereference rx->key == NULL when driver set
    RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
    promiscuous mode. This happen with rt73usb and rt61pci at least.

    Before the commit we always check rx->key against NULL, so I assume
    fix should be done in mac80211 (also mic_fail path has similar check).

    References:
    https://bugzilla.redhat.com/show_bug.cgi?id=769766
    http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html

    Reported-by: Stuart D Gathman <stuart@gathman.org>
    Reported-by: Kai Wohlfahrt <kai.scorpio@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 93d150e945fdaceb9e8fe18c7b9014569123195d
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Jan 4 20:50:47 2012 -0600

    rtl8192se: Fix BUG caused by failure to check skb allocation

    commit d90db4b12bc1b9b8a787ef28550fdb767ee25a49 upstream.

    When downloading firmware into the device, the driver fails to check the
    return when allocating an skb. When the allocation fails, a BUG can be
    generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656.

    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 982e49a7cbcca1347b701e2098431153d83c3dd2
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 5 14:27:24 2012 -0700

    PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB

    commit eb31aae8cb5eb54e234ed2d857ddac868195d911 upstream.

    Some Dell BIOSes have MCFG tables that don't report the entire
    MMCONFIG area claimed by the chipset.  If we move PCI devices into
    that claimed-but-unreported area, they don't work.

    This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as
    needed to cover the entire area.

    Example problem scenario:

      BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved)
      Fam 10h mmconf [d0000000, dfffffff]
      PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000)
      pnp 00:0c: [mem 0xd0000000-0xd3ffffff]
      pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff]
      pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff]
      pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff]

    Reported-by: Lisa Salimbas <lisa.salimbas@canonical.com>
    Reported-by: <thuban@singularity.fr>
    Tested-by: dann frazier <dann.frazier@canonical.com>
    References: https://bugzilla.kernel.org/show_bug.cgi?id=31602
    References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043
    References: https://bugzilla.redhat.com/show_bug.cgi?id=770308
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ffdfcb4347b7f5082e6e191175d46d74c235c2c7
Author: Roberto Sassu <roberto.sassu@polito.it>
Date:   Mon Dec 19 15:57:28 2011 +0100

    ima: fix invalid memory reference

    commit 7b7e5916aa2f46e57f8bd8cb89c34620ebfda5da upstream.

    Don't free a valid measurement entry on TPM PCR extend failure.

    Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
    Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 808f398267e920a772c1ae07781adfb0d4d1c48a
Author: Roberto Sassu <roberto.sassu@polito.it>
Date:   Mon Dec 19 15:57:27 2011 +0100

    ima: free duplicate measurement memory

    commit 45fae7493970d7c45626ccd96d4a74f5f1eea5a9 upstream.

    Info about new measurements are cached in the iint for performance.  When
    the inode is flushed from cache, the associated iint is flushed as well.
    Subsequent access to the inode will cause the inode to be re-measured and
    will attempt to add a duplicate entry to the measurement list.

    This patch frees the duplicate measurement memory, fixing a memory leak.

    Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
    Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 9919fe804d613e513ef13f5eedc9e583c4429d38
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Jan 4 09:34:49 2012 +0000

    xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.

    commit 9e7860cee18241633eddb36a4c34c7b61d8cecbc upstream.

    Haogang Chen found out that:

     There is a potential integer overflow in process_msg() that could result
     in cross-domain attack.

     	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);

     When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
     call to xb_read() would write to a zero-length buffer.

     The other end of this connection is always the xenstore backend daemon
     so there is no guest (malicious or otherwise) which can do this. The
     xenstore daemon is a trusted component in the system.

     However this seem like a reasonable robustness improvement so we should
     have it.

    And Ian when read the API docs found that:
            The payload length (len field of the header) is limited to 4096
            (XENSTORE_PAYLOAD_MAX) in both directions.  If a client exceeds the
            limit, its xenstored connection will be immediately killed by
            xenstored, which is usually catastrophic from the client's point of
            view.  Clients (particularly domains, which cannot just reconnect)
            should avoid this.

    so this patch checks against that instead.

    This also avoids a potential integer overflow pointed out by Haogang Chen.

    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Cc: Haogang Chen <haogangchen@gmail.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 73669debb5f508962ffcc8b632ffb2971c606e5c
Author: nagalakshmi.nandigama@lsi.com <nagalakshmi.nandigama@lsi.com>
Date:   Thu Dec 1 07:53:08 2011 +0530

    SCSI: mpt2sas : Fix for memory allocation error for large host credits

    commit aff132d95ffe14eca96cab90597cdd010b457af7 upstream.

    The amount of memory required for tracking chain buffers is rather
    large, and when the host credit count is big, memory allocation
    failure occurs inside __get_free_pages.

    The fix is to limit the number of chains to 100,000.  In addition,
    the number of host credits is limited to 30,000 IOs. However this
    limitation can be overridden this using the command line option
    max_queue_depth.  The algorithm for calculating the
    reply_post_queue_depth is changed so that it is equal to
    (reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2).

    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit de3f88ba084473ce5365632f0209c3e95aeb55e9
Author: nagalakshmi.nandigama@lsi.com <nagalakshmi.nandigama@lsi.com>
Date:   Thu Dec 1 07:52:56 2011 +0530

    SCSI: mpt2sas: Release spinlock for the raid device list before blocking it

    commit 30c43282f3d347f47f9e05199d2b14f56f3f2837 upstream.

    Added code to release the spinlock that is used to protect the
    raid device list before calling a function that can block. The
    blocking was causing a reschedule, and subsequently it is tried
    to acquire the same lock, resulting in a panic (NMI Watchdog
    detecting a CPU lockup).

    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 72ce943013baaba4af7afec76c3556b16b9f6de4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 12 08:01:40 2012 -0700

    x86/PCI: build amd_bus.o only when CONFIG_AMD_NB=y

    commit 5cf9a4e69c1ff0ccdd1d2b7404f95c0531355274 upstream.

    We only need amd_bus.o for AMD systems with PCI.  arch/x86/pci/Makefile
    already depends on CONFIG_PCI=y, so this patch just adds the dependency
    on CONFIG_AMD_NB.

    Cc: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 45e7e24360e799f7753f37ca5642a0d6e29b9c62
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Jan 5 14:27:19 2012 -0700

    x86/PCI: amd: factor out MMCONFIG discovery

    commit 24d25dbfa63c376323096660bfa9ad45a08870ce upstream.

    This factors out the AMD native MMCONFIG discovery so we can use it
    outside amd_bus.c.

    amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the
    PCI resources.  We may also need the MMCONFIG information to work
    around BIOS defects in the ACPI MCFG table.

    Cc: Borislav Petkov <borislav.petkov@amd.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0a4179971477550df61b9218e664eb9128abf2e3
Author: Gary Hade <garyhade@us.ibm.com>
Date:   Mon Nov 14 15:42:16 2011 -0800

    x86/PCI: Ignore CPU non-addressable _CRS reserved memory resources

    commit ae5cd86455381282ece162966183d3f208c6fad7 upstream.

    This assures that a _CRS reserved host bridge window or window region is
    not used if it is not addressable by the CPU.  The new code either trims
    the window to exclude the non-addressable portion or totally ignores the
    window if the entire window is non-addressable.

    The current code has been shown to be problematic with 32-bit non-PAE
    kernels on systems where _CRS reserves resources above 4GB.

    Signed-off-by: Gary Hade <garyhade@us.ibm.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Thomas Renninger <trenn@novell.com>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 65d61b46700e059210b4c9f63355d57dc0e1a18e
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Oct 17 11:46:06 2011 -0700

    PCI: msi: Disable msi interrupts when we initialize a pci device

    commit a776c491ca5e38c26d9f66923ff574d041e747f4 upstream.

    I traced a nasty kexec on panic boot failure to the fact that we had
    screaming msi interrupts and we were not disabling the msi messages at
    kernel startup.  The booting kernel had not enabled those interupts so
    was not prepared to handle them.

    I can see no reason why we would ever want to leave the msi interrupts
    enabled at boot if something else has enabled those interrupts.  The pci
    spec specifies that msi interrupts should be off by default.  Drivers
    are expected to enable the msi interrupts if they want to use them.  Our
    interrupt handling code reprograms the interrupt handlers at boot and
    will not be be able to do anything useful with an unexpected interrupt.

    This patch applies cleanly all of the way back to 2.6.32 where I noticed
    the problem.

    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 58f98e86f9138e283b98766541727af91a58e849
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Wed Nov 16 09:24:16 2011 -0700

    PCI: Fix PCI_EXP_TYPE_RC_EC value

    commit 1830ea91c20b06608f7cdb2455ce05ba834b3214 upstream.

    Spec shows this as 1010b = 0xa

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit c16686fc0c9c8f6fa46741e50c6ab621ab507cf9
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Thu Jan 5 10:47:18 2012 +0200

    UBI: fix use-after-free on error path

    commit e57e0d8e818512047fe379157c3f77f1b9fabffb upstream.

    When we fail to erase a PEB, we free the corresponding erase entry object,
    but then re-schedule this object if the error code was something like -EAGAIN.
    Obviously, it is a bug to use the object after we have freed it.

    Reported-by: Emese Revfy <re.emese@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 75947f78d026b6eb2c4f16c54042325f97e3288a
Author: Bhavesh Parekh <bparekh@nvidia.com>
Date:   Wed Nov 30 17:43:42 2011 +0530

    UBI: fix missing scrub when there is a bit-flip

    commit e801e128b2200c40a0ec236cf2330b2586b6e05a upstream.

    Under some cases, when scrubbing the PEB if we did not get the lock on
    the PEB it fails to scrub. Add that PEB again to the scrub list

    Artem: minor amendments.

    Signed-off-by: Bhavesh Parekh <bparekh@nvidia.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 729a9768761809079d07c9716f656da20a14eb2f
Author: Chase Douglas <chase.douglas@canonical.com>
Date:   Mon Nov 7 11:08:05 2011 -0800

    HID: bump maximum global item tag report size to 96 bytes

    commit e46e927b9b7e8d95526e69322855243882b7e1a3 upstream.

    This allows the latest N-Trig devices to function properly.

    BugLink: https://bugs.launchpad.net/bugs/724831

    Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dbbef3cbdef5e2363caeb343efa68650f20d7bfc
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Dec 20 06:57:45 2011 -0500

    nfs: fix regression in handling of context= option in NFSv4

    commit 8a0d551a59ac92d8ff048d6cb29d3a02073e81e8 upstream.

    Setting the security context of a NFSv4 mount via the context= mount
    option is currently broken. The NFSv4 codepath allocates a parsed
    options struct, and then parses the mount options to fill it. It
    eventually calls nfs4_remote_mount which calls security_init_mnt_opts.
    That clobbers the lsm_opts struct that was populated earlier. This bug
    also looks like it causes a small memory leak on each v4 mount where
    context= is used.

    Fix this by moving the initialization of the lsm_opts into
    nfs_alloc_parsed_mount_data. Also, add a destructor for
    nfs_parsed_mount_data to make it easier to free all of the allocations
    hanging off of it, and to ensure that the security_free_mnt_opts is
    called whenever security_init_mnt_opts is.

    I believe this regression was introduced quite some time ago, probably
    by commit c02d7adf.

    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 58a902db8896b6bb4c779a223f6e8e7b289cdcc9
Author: Andy Adamson <andros@netapp.com>
Date:   Wed Nov 9 13:58:20 2011 -0500

    NFSv4.1: fix backchannel slotid off-by-one bug

    commit 61f2e5106582d02f30b6807e3f9c07463c572ccb upstream.

    Signed-off-by: Andy Adamson <andros@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 2dda99b3d5f3f6be05f0c9cc7cf0b05740e6e9f5
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Dec 5 15:40:30 2011 -0500

    NFS: Retry mounting NFSROOT

    commit 43717c7daebf10b43f12e68512484b3095bb1ba5 upstream.

    Lukas Razik <linux@razik.name> reports that on his SPARC system,
    booting with an NFS root file system stopped working after commit
    56463e50 "NFS: Use super.c for NFSROOT mount option parsing."

    We found that the network switch to which Lukas' client was attached
    was delaying access to the LAN after the client's NIC driver reported
    that its link was up.  The delay was longer than the timeouts used in
    the NFS client during mounting.

    NFSROOT worked for Lukas before commit 56463e50 because in those
    kernels, the client's first operation was an rpcbind request to
    determine which port the NFS server was listening on.  When that
    request failed after a long timeout, the client simply selected the
    default NFS port (2049).  By that time the switch was allowing access
    to the LAN, and the mount succeeded.

    Neither of these client behaviors is desirable, so reverting 56463e50
    is really not a choice.  Instead, introduce a mechanism that retries
    the NFSROOT mount request several times.  This is the same tactic that
    normal user space NFS mounts employ to overcome server and network
    delays.

    Signed-off-by: Lukas Razik <linux@razik.name>
    [ cel: match kernel coding style, add proper patch description ]
    [ cel: add exponential back-off ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: Lukas Razik <linux@razik.name>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit be2ef85142e6f00c7f6c8842d903701bdf88cb5c
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Jan 5 18:42:17 2012 +0100

    radeon: Fix disabling PCI bus mastering on big endian hosts.

    commit 3df96909b75835d487a9178761622b0cbd7310d4 upstream.

    It would previously write basically random bits to PCI configuration space...
    Not very surprising that the GPU tended to stop responding completely. The
    resulting MCE even froze the whole machine sometimes.

    Now resetting the GPU after a lockup has at least a fighting chance of
    succeeding.

    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit a674b8b3e345496a96aec389446650455b2fdfa1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jan 3 09:48:38 2012 -0500

    drm/radeon/kms: disable writeback on pre-R300 asics

    commit 28eebb703e28bc455ba704adb1026f76649b768c upstream.

    We often end up missing fences on older asics with
    writeback enabled which leads to delays in the userspace
    accel code, so just disable it by default on those asics.

    Reported-by: Helge Deller <deller@gmx.de>
    Reported-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit b48620dfff7a12774bb83348a88eddb5921dcdd2
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Fri Dec 23 20:32:18 2011 +0100

    drm/radeon/kms: workaround invalid AVI infoframe checksum issue

    commit 92db7f6c860b8190571a9dc1fcbc16d003422fe8 upstream.

    This change was verified to fix both issues with no video I've
    investigated. I've also checked checksum calculation with fglrx on:
    RV620, HD54xx, HD5450, HD6310, HD6320.

    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 24973a17310bd933969d79cf4080049df85aff2c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jan 10 12:41:22 2012 +0100

    ALSA: hda - Return the error from get_wcaps_type() for invalid NIDs

    commit 3a90274de3548ebb2aabfbf488cea8e275a73dc6 upstream.

    When an invalid NID is given, get_wcaps() returns zero as the error,
    but get_wcaps_type() takes it as the normal value and returns a bogus
    AC_WID_AUD_OUT value.  This confuses the parser.

    With this patch, get_wcaps_type() returns -1 when value 0 is given,
    i.e. an invalid NID is passed to get_wcaps().

    Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 35cdd5ea88762e22c9d21c5c826cbd7ef1edd7db
Author: Pavel Hofman <pavel.hofman@ivitera.com>
Date:   Thu Jan 5 23:05:18 2012 +0100

    ALSA: ice1724 - Check for ac97 to avoid kernel oops

    commit e7848163aa2a649d9065f230fadff80dc3519775 upstream.

    Cards with identical PCI ids but no AC97 config in EEPROM do not have
    the ac97 field initialized. We must check for this case to avoid kernel oops.

    Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 730580b66c412cd8fbe9c7077ce42c55a85e6281
Author: Karsten Wiese <fzu@wemgehoertderstaat.de>
Date:   Fri Dec 30 01:42:01 2011 +0100

    ALSA: snd-usb-us122l: Delete calls to preempt_disable

    commit d0f3a2eb9062560bebca8b923424f3ca02a331ba upstream.

    They are not needed here.

    Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0146b288f47cc3ef3f0791b3023643ccdeeeb339
Author: Xi Wang <xi.wang@gmail.com>
Date:   Tue Jan 10 11:51:10 2012 -0500

    ext4: fix undefined behavior in ext4_fill_flex_info()

    commit d50f2ab6f050311dbf7b8f5501b25f0bf64a439b upstream.

    Commit 503358ae01b70ce6909d19dd01287093f6b6271c ("ext4: avoid divide by
    zero when trying to mount a corrupted file system") fixes CVE-2009-4307
    by performing a sanity check on s_log_groups_per_flex, since it can be
    set to a bogus value by an attacker.

    	sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex;
    	groups_per_flex = 1 << sbi->s_log_groups_per_flex;

    	if (groups_per_flex < 2) { ... }

    This patch fixes two potential issues in the previous commit.

    1) The sanity check might only work on architectures like PowerPC.
    On x86, 5 bits are used for the shifting amount.  That means, given a
    large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36
    is essentially 1 << 4 = 16, rather than 0.  This will bypass the check,
    leaving s_log_groups_per_flex and groups_per_flex inconsistent.

    2) The sanity check relies on undefined behavior, i.e., oversized shift.
    A standard-confirming C compiler could rewrite the check in unexpected
    ways.  Consider the following equivalent form, assuming groups_per_flex
    is unsigned for simplicity.

    	groups_per_flex = 1 << sbi->s_log_groups_per_flex;
    	if (groups_per_flex == 0 || groups_per_flex == 1) {

    We compile the code snippet using Clang 3.0 and GCC 4.6.  Clang will
    completely optimize away the check groups_per_flex == 0, leaving the
    patched code as vulnerable as the original.  GCC keeps the check, but
    there is no guarantee that future versions will do the same.

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 922d41ed4740408d2719a8c99d9f80138e562c03
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Jan 10 15:11:02 2012 -0800

    drivers/rtc/interface.c: fix alarm rollover when day or month is out-of-range

    commit e74a8f2edb92cb690b467cea0ab652c509e9f624 upstream.

    Commit f44f7f96a20a ("RTC: Initialize kernel state from RTC") introduced a
    potential infinite loop.  If an alarm time contains a wildcard month and
    an invalid day (> 31), or a wildcard year and an invalid month (>= 12),
    the loop searching for the next matching date will never terminate.  Treat
    the invalid values as wildcards.

    Fixes <http://bugs.debian.org/646429>, <http://bugs.debian.org/653331>

    Reported-by: leo weppelman <leoweppelman@googlemail.com>
    Reported-by: "P. van Gaans" <mailme667@yahoo.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Cc: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Acked-by: Alessandro Zummo <a.zummo@towertech.it>
    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@suse.de>

commit f3a6e79c583423a55f7068ccdad732a5f4a0faad
Author: Wolfram Sang <w.sang@pengutronix.de>
Date:   Tue Nov 29 15:34:08 2011 +0100

    mtd: tests: stresstest: bail out if device has not enough eraseblocks

    commit 2f4478ccff7df845dc9c0f8996a96373122c4417 upstream.

    stresstest needs at least two eraseblocks. Bail out gracefully if that
    condition is not met. Fixes the following 'division by zero' OOPS:

    [  619.100000] mtd_stresstest: MTD device size 131072, eraseblock size 131072, page size 2048, count of eraseblocks 1, pages per eraseblock 64, OOB size 64
    [  619.120000] mtd_stresstest: scanning for bad eraseblocks
    [  619.120000] mtd_stresstest: scanned 1 eraseblocks, 0 are bad
    [  619.130000] mtd_stresstest: doing operations
    [  619.130000] mtd_stresstest: 0 operations done
    [  619.140000] Division by zero in kernel.
    ...

    caused by

            /* Read or write up 2 eraseblocks at a time - hence 'ebcnt - 1' */
            eb %= (ebcnt - 1);

    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 488e572df737befdfc783503642d70ea18b3a001
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Mon Nov 7 15:51:05 2011 -0800

    mtd: mtd_blkdevs: don't increase 'open' count on error path

    commit 342ff28f5a2e5aa3236617bd2bddf6c749677ef2 upstream.

    Some error paths in mtd_blkdevs were fixed in the following commit:

        commit 94735ec4044a6d318b83ad3c5794e931ed168d10
        mtd: mtd_blkdevs: fix error path in blktrans_open

    But on these error paths, the block device's `dev->open' count is
    already incremented before we check for errors. This meant that, while
    the error path was handled correctly on the first time through
    blktrans_open(), the device is erroneously considered already open on
    the second time through.

    This problem can be seen, for instance, when a UBI volume is
    simultaneously mounted as a UBIFS partition and read through its
    corresponding gluebi mtdblockX device. This results in blktrans_open()
    passing its error checks (with `dev->open > 0') without actually having
    a handle on the device. Here's a summarized log of the actions and
    results with nandsim:

        # modprobe nandsim
        # modprobe mtdblock
        # modprobe gluebi
        # modprobe ubifs
        # ubiattach /dev/ubi_ctrl -m 0
        ...
        # ubimkvol /dev/ubi0 -N test -s 16MiB
        ...
        # mount -t ubifs ubi0:test /mnt
        # ls /dev/mtdblock*
        /dev/mtdblock0  /dev/mtdblock1
        # cat /dev/mtdblock1 > /dev/null
        cat: can't open '/dev/mtdblock4': Device or resource busy
        # cat /dev/mtdblock1 > /dev/null

        CPU 0 Unable to handle kernel paging request at virtual address
        fffffff0, epc == 8031536c, ra == 8031f280
        Oops[#1]:
        ...
        Call Trace:
        [<8031536c>] ubi_leb_read+0x14/0x164
        [<8031f280>] gluebi_read+0xf0/0x148
        [<802edba8>] mtdblock_readsect+0x64/0x198
        [<802ecfe4>] mtd_blktrans_thread+0x330/0x3f4
        [<8005be98>] kthread+0x88/0x90
        [<8000bc04>] kernel_thread_helper+0x10/0x18

    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 13205eedda9d80daf129ddad54bd6ffe5df92dff
Author: Roman Tereshonkov <roman.tereshonkov@nokia.com>
Date:   Fri Dec 2 15:07:17 2011 +0200

    mtd: mtdoops: skip reading initially bad blocks

    commit 3538c56329936c78f7d356889908790006d0124c upstream.

    Use block_isbad to check and skip the bad blocks reading.
    This will allow to get rid of the read errors if bad blocks
    are present initially.

    Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 63f0d35a610b2ef1139b5d763ee74cab5257a8c8
Author: Roman Tereshonkov <roman.tereshonkov@nokia.com>
Date:   Tue Nov 29 12:49:18 2011 +0200

    mtdoops: fix the oops_page_used array size

    commit 556f063580db2953a7e53cd46b47724246320f60 upstream.

    The array of unsigned long pointed by oops_page_used is allocated
    by vmalloc which requires the size to be in bytes.

    BITS_PER_LONG is equal to 32.
    If we want to allocate memory for 32 pages with one bit per page then
    32 / BITS_PER_LONG  is equal to 1 byte that is 8 bits.
    To fix it we need to multiply the result by sizeof(unsigned long) equal to 4.

    Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linux 3.0.19

commit 5d14e472c60de8791259a0dbb8ba5252d0862a63
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 3 09:19:48 2012 -0800

    Linux 3.0.19

commit 614a5aed26447b940748514f77b5487cdba2c5d6
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:53 2012 +0100

    USB: cp210x: allow more baud rates above 1Mbaud

    commit d1620ca9e7bb0030068c3b45b653defde8839dac upstream.

    Allow more baud rates to be set in [1M,2M] baud.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 872a9a09233a2ff601bf3449cdd2be9e9b2c0ac2
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:52 2012 +0100

    USB: cp210x: initialise baud rate at open

    commit cdc32fd6f7b2b2580d7f1b74563f888e4dd9eb8a upstream.

    The newer cp2104 devices require the baud rate to be initialised after
    power on. Make sure it is set when port is opened.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9dbd22994fae588903b99c328f81870e09795b8
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:51 2012 +0100

    USB: cp210x: clean up, refactor and document speed handling

    commit e5990874e511d5bbca23b3396419480cb2ca0ee7 upstream.

    Clean up and refactor speed handling.
    Document baud rate handling for CP210{1,2,4,5,10}.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 193aec6a3db750e58f5aac26e68dbb124b7328e9
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:49 2012 +0100

    USB: cp210x: fix up set_termios variables

    commit 34b76fcaee574017862ea3fa0efdcd77a9d0e57d upstream.

    [Based on a patch from Johan, mangled by gregkh to keep things in line]

    Fix up the variable usage in the set_termios call.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb04bab862c91d0bd75e5c5339039e5444973d16
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:50 2012 +0100

    USB: cp210x: do not map baud rates to B0

    commit be125d9c8d59560e7cc2d6e2b65c8fd233498ab7 upstream.

    We do not implement B0 hangup yet so map low baudrates to 300bps.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Cc: Preston Fick <preston.fick@silabs.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e23f5bd613d19b6ad224bd8e4768a1963a42330c
Author: Preston Fick <preston.fick@silabs.com>
Date:   Mon Jan 16 18:14:09 2012 -0600

    USB: cp210x: fix CP2104 baudrate usage

    commit 7f482fc88ac47662228d6b1f05759797c8936a30 upstream.

    This fix changes the way baudrates are set on the CP210x devices from
    Silicon Labs. The CP2101/2/3 will respond to both a GET/SET_BAUDDIV
    command, and GET/SET_BAUDRATE command, while CP2104 and higher devices
    only respond to GET/SET_BAUDRATE. The current cp210x.ko driver in
    kernel version 3.2.0 only implements the GET/SET_BAUDDIV command.

    This patch implements the two new codes for the GET/SET_BAUDRATE
    commands. Then there is a change in the way that the baudrate is
    assigned or retrieved. This is done according to the CP210x USB
    specification in AN571. This document can be found here:
    http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/AN571.pdf&src=DocumentationWebPart

    Sections 5.3/5.4 describe the USB packets for the old baudrate method.
    Sections 5.5/5.6 describe the USB packets for the new method. This
    patch also implements the new request scheme, and eliminates the
    unnecessary baudrate calculations since it uses the "actual baudrate"
    method.

    This patch solves the problem reported for the CP2104 in bug 42586,
    and also keeps support for all other devices (CP2101/2/3).

    This patchfile is also attached to the bug report on
    bugzilla.kernel.org. This patch has been developed and test on the
    3.2.0 mainline kernel version under Ubuntu 10.11.

    Signed-off-by: Preston Fick <preston.fick@silabs.com>
    [duplicate patch also sent by Johan - gregkh]
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea453b01d323ab09758a56c06e808420b63b5a1a
Author: Johan Hovold <jhovold@gmail.com>
Date:   Mon Jan 16 00:36:48 2012 +0100

    USB: cp210x: call generic open last in open

    commit 55b2afbb92ad92e9f6b0aa4354eb1c94589280c3 upstream.

    Make sure port is fully initialised before calling generic open.

    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4148500eefcc1b84a1985e9f8835a330d25f051
Author: Renato Caldas <rmsc@fe.up.pt>
Date:   Fri Jan 6 15:20:51 2012 +0000

    USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19

    commit 791b7d7cf69de11275e4dccec2f538eec02cbff6 upstream.

    This device is a Oscilloscope/Logic Analizer/Pattern Generator/TDR,
    using a Silabs CP2103 USB to UART Bridge.

    Signed-off-by: Renato Caldas <rmsc@fe.up.pt>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81ecd154d0b07bd5dab6e4f09336cb068b70bcb9
Author: shawnlu <shawn.lu@ericsson.com>
Date:   Fri Jan 20 12:22:04 2012 +0000

    tcp: md5: using remote adress for md5 lookup in rst packet

    [ Upstream commit 8a622e71f58ec9f092fc99eacae0e6cf14f6e742 ]

    md5 key is added in socket through remote address.
    remote address should be used in finding md5 key when
    sending out reset packet.

    Signed-off-by: shawnlu <shawn.lu@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b4bb350e120fe0b32a0b1b8d227e65af03e3993
Author: Neal Cardwell <ncardwell@google.com>
Date:   Sat Jan 28 17:29:46 2012 +0000

    tcp: fix tcp_trim_head() to adjust segment count with skb MSS

    [ Upstream commit 5b35e1e6e9ca651e6b291c96d1106043c9af314a ]

    This commit fixes tcp_trim_head() to recalculate the number of
    segments in the skb with the skb's existing MSS, so trimming the head
    causes the skb segment count to be monotonically non-increasing - it
    should stay the same or go down, but not increase.

    Previously tcp_trim_head() used the current MSS of the connection. But
    if there was a decrease in MSS between original transmission and ACK
    (e.g. due to PMTUD), this could cause tcp_trim_head() to
    counter-intuitively increase the segment count when trimming bytes off
    the head of an skb. This violated assumptions in tcp_tso_acked() that
    tcp_trim_head() only decreases the packet count, so that packets_acked
    in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
    pass u32 pkts_acked values as large as 0xffffffff to
    ca_ops->pkts_acked().

    As an aside, if tcp_trim_head() had really wanted the skb to reflect
    the current MSS, it should have called tcp_set_skb_tso_segs()
    unconditionally, since a decrease in MSS would mean that a
    single-packet skb should now be sliced into multiple segments.

    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Nandita Dukkipati <nanditad@google.com>
    Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f217c4711d71aa6811b6e71d219b9efafa5d55a6
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Jan 24 17:03:44 2012 -0500

    rds: Make rds_sock_lock BH rather than IRQ safe.

    [ Upstream commit efc3dbc37412c027e363736b4f4c74ee5e8ecffc ]

    rds_sock_info() triggers locking warnings because we try to perform a
    local_bh_enable() (via sock_i_ino()) while hardware interrupts are
    disabled (via taking rds_sock_lock).

    There is no reason for rds_sock_lock to be a hardware IRQ disabling
    lock, none of these access paths run in hardware interrupt context.

    Therefore making it a BH disabling lock is safe and sufficient to
    fix this bug.

    Reported-by: Kumar Sanghvi <kumaras@chelsio.com>
    Reported-by: Josh Boyer <jwboyer@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d020b1d3d3379d183d0649cdc2f6de9131268419
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed Jan 18 07:21:42 2012 +0000

    net: bpf_jit: fix divide by 0 generation

    [ Upstream commit d00a9dd21bdf7908b70866794c8313ee8a5abd5c ]

    Several problems fixed in this patch :

    1) Target of the conditional jump in case a divide by 0 is performed
       by a bpf is wrong.

    2) Must 'generate' the full function prologue/epilogue at pass=0,
       or else we can stop too early in pass=1 if the proglen doesnt change.
       (if the increase of prologue/epilogue equals decrease of all
        instructions length because some jumps are converted to near jumps)

    3) Change the wrong length detection at the end of code generation to
       issue a more explicit message, no need for a full stack trace.

    Reported-by: Phil Oester <kernel@linuxace.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1334533665277ccc5568c5104cd2358788a02e02
Author: James Chapman <jchapman@katalix.com>
Date:   Wed Jan 25 02:39:05 2012 +0000

    l2tp: l2tp_ip - fix possible oops on packet receive

    [ Upstream commit 68315801dbf3ab2001679fd2074c9dc5dcf87dfa ]

    When a packet is received on an L2TP IP socket (L2TPv3 IP link
    encapsulation), the l2tpip socket's backlog_rcv function calls
    xfrm4_policy_check(). This is not necessary, since it was called
    before the skb was added to the backlog. With CONFIG_NET_NS enabled,
    xfrm4_policy_check() will oops if skb->dev is null, so this trivial
    patch removes the call.

    This bug has always been present, but only when CONFIG_NET_NS is
    enabled does it cause problems. Most users are probably using UDP
    encapsulation for L2TP, hence the problem has only recently
    surfaced.

    EIP: 0060:[<c12bb62b>] EFLAGS: 00210246 CPU: 0
    EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
    EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
    ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Call Trace:
     [<c1218568>] sock_common_recvmsg+0x31/0x46
     [<c1215c92>] __sock_recvmsg_nosec+0x45/0x4d
     [<c12163a1>] __sock_recvmsg+0x31/0x3b
     [<c1216828>] sock_recvmsg+0x96/0xab
     [<c10b2693>] ? might_fault+0x47/0x81
     [<c10b2693>] ? might_fault+0x47/0x81
     [<c1167fd0>] ? _copy_from_user+0x31/0x115
     [<c121e8c8>] ? copy_from_user+0x8/0xa
     [<c121ebd6>] ? verify_iovec+0x3e/0x78
     [<c1216604>] __sys_recvmsg+0x10a/0x1aa
     [<c1216792>] ? sock_recvmsg+0x0/0xab
     [<c105a99b>] ? __lock_acquire+0xbdf/0xbee
     [<c12d5a99>] ? do_page_fault+0x193/0x375
     [<c10d1200>] ? fcheck_files+0x9b/0xca
     [<c10d1259>] ? fget_light+0x2a/0x9c
     [<c1216bbb>] sys_recvmsg+0x2b/0x43
     [<c1218145>] sys_socketcall+0x16d/0x1a5
     [<c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10
     [<c100305f>] sysenter_do_call+0x12/0x38
    Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c

    Signed-off-by: James Chapman <jchapman@katalix.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03024e3d2d6705443980f956abb56d4453319e95
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Wed Jan 18 12:24:54 2012 +0000

    bonding: fix enslaving in alb mode when link down

    [ Upstream commit b924551bed09f61b64f21bffe241afc5526b091a ]

    bond_alb_init_slave() is called from bond_enslave() and sets the slave's MAC
    address. This is done differently for TLB and ALB modes.
    bond->alb_info.rlb_enabled is used to discriminate between the two modes but
    this flag may be uninitialized if the slave is being enslaved prior to calling
    bond_open() -> bond_alb_initialize() on the master.

    It turns out all the callers of alb_set_slave_mac_addr() pass
    bond->alb_info.rlb_enabled as the hw parameter.

    This patch cleans up the unnecessary parameter of alb_set_slave_mac_addr() and
    makes the function decide based on the bonding mode instead, which fixes the
    above problem.

    Reported-by: Narendra K <Narendra_K@Dell.com>
    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62252cba2867cec7cc484ebb2d3ec705c41d9684
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Jan 26 14:04:53 2012 +0000

    net caif: Register properly as a pernet subsystem.

    [ Upstream commit 8a8ee9aff6c3077dd9c2c7a77478e8ed362b96c6 ]

    caif is a subsystem and as such it needs to register with
    register_pernet_subsys instead of register_pernet_device.

    Among other problems using register_pernet_device was resulting in
    net_generic being called before the caif_net structure was allocated.
    Which has been causing net_generic to fail with either BUG_ON's or by
    return NULL pointers.

    A more ugly problem that could be caused is packets in flight why the
    subsystem is shutting down.

    To remove confusion also remove the cruft cause by inappropriately
    trying to fix this bug.

    With the aid of the previous patch I have tested this patch and
    confirmed that using register_pernet_subsys makes the failure go away as
    it should.

    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc1be3611bae365c2399f5208732ddd0969cf46d
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Jan 26 14:02:55 2012 +0000

    netns: Fail conspicously if someone uses net_generic at an inappropriate time.

    [ Upstream commit 5ee4433efe99b9f39f6eff5052a177bbcfe72cea ]

    By definition net_generic should never be called when it can return
    NULL.  Fail conspicously with a BUG_ON to make it clear when people mess
    up that a NULL return should never happen.

    Recently there was a bug in the CAIF subsystem where it was registered
    with register_pernet_device instead of register_pernet_subsys.  It was
    erroneously concluded that net_generic could validly return NULL and
    that net_assign_generic was buggy (when it was just inefficient).
    Hopefully this BUG_ON will prevent people to coming to similar erroneous
    conclusions in the futrue.

    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 561331eae0a03d0c4cf60f3cf485aa3e8aa5ab48
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Thu Jan 26 00:41:38 2012 +0000

    netns: fix net_alloc_generic()

    [ Upstream commit 073862ba5d249c20bd5c49fc6d904ff0e1f6a672 ]

    When a new net namespace is created, we should attach to it a "struct
    net_generic" with enough slots (even empty), or we can hit the following
    BUG_ON() :

    [  200.752016] kernel BUG at include/net/netns/generic.h:40!
    ...
    [  200.752016]  [<ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180
    [  200.752016]  [<ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20
    [  200.752016]  [<ffffffff825c41be>] caif_device_notify+0x2e/0x530
    [  200.752016]  [<ffffffff810d61b7>] notifier_call_chain+0x67/0x110
    [  200.752016]  [<ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20
    [  200.752016]  [<ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60
    [  200.752016]  [<ffffffff821c2b26>] register_netdevice+0x196/0x300
    [  200.752016]  [<ffffffff821c2ca9>] register_netdev+0x19/0x30
    [  200.752016]  [<ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0
    [  200.752016]  [<ffffffff821b5e62>] ops_init+0x42/0x180
    [  200.752016]  [<ffffffff821b600b>] setup_net+0x6b/0x100
    [  200.752016]  [<ffffffff821b6466>] copy_net_ns+0x86/0x110
    [  200.752016]  [<ffffffff810d5789>] create_new_namespaces+0xd9/0x190

    net_alloc_generic() should take into account the maximum index into the
    ptr array, as a subsystem might use net_generic() anytime.

    This also reduces number of reallocations in net_assign_generic()

    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4df9c291640da8992e146076f57a8e563c449e31
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Jan 20 01:49:57 2012 +0100

    USB: cdc-wdm: Avoid hanging on interface with no USB_CDC_DMM_TYPE

    commit 15699e6fafc3a90e5fdc2ef30555a04dee62286f upstream.

    The probe does not strictly require the USB_CDC_DMM_TYPE
    descriptor, which is a good thing as it makes the driver
    usable on non-conforming interfaces.  A user could e.g.
    bind to it to a CDC ECM interface by using the new_id and
    bind sysfs files.  But this would fail with a 0 buffer length
    due to the missing descriptor.

    Fix by defining a reasonable fallback size: The minimum
    device receive buffer size required by the CDC WMC standard,
    revision 1.1

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5256ca41663c848ac24783a5161a97730a21696c
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 15:11:59 2012 +0100

    USB: cdc-wdm: better allocate a buffer that is at least as big as we tell the USB core

    commit 655e247daf52b202a6c2d0f8a06dd2051e756ce4 upstream.

    As it turns out, there was a mismatch between the allocated inbuf size
    (desc->bMaxPacketSize0, typically something like 64) and the length we
    specified in the URB (desc->wMaxCommand, typically something like 2048)

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1abac982c49f35615f47ff1f94a8ca5ba962bd8
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 15:11:57 2012 +0100

    USB: cdc-wdm: call wake_up_all to allow driver to shutdown on device removal

    commit 62aaf24dc125d7c55c93e313d15611f152b030c7 upstream.

    wdm_disconnect() waits for the mutex held by wdm_read() before
    calling wake_up_all().  This causes a deadlock, preventing device removal
    to complete.  Do the wake_up_all() before we start waiting for the locks.

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Oliver Neukum <oliver@neukum.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b4e97269313969faf20f4c341af10d734d6d00d
Author: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date:   Thu Jan 26 15:59:00 2012 -0500

    hwmon: (sht15) fix bad error code

    commit 6edf3c30af01854c416f8654d3d5d2652470afd4 upstream.

    When no platform data was supplied, returned error code was 0.

    Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70c3e9e41475dd3d7dbd816130ff8c21e6e1f745
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Jan 27 17:56:06 2012 -0800

    hwmon: (w83627ehf) Disable setting DC mode for pwm2, pwm3 on NCT6776F

    commit ad77c3e1808f07fa70f707b1c92a683b7c7d3f85 upstream.

    NCT6776F only supports pwm mode for pwm2 and pwm3. Return error if an attempt
    is made to set those pwm channels to DC mode.

    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c39714f1da06b21e4d4250d030448099912ae79f
Author: Jean Delvare <khali@linux-fr.org>
Date:   Fri Jan 20 10:09:23 2012 -0500

    hwmon: (f71805f) Fix clamping of temperature limits

    commit 86b2bbfdbd1fcc4a3aa62ccd3f245c40c5ad5b85 upstream.

    Properly clamp temperature limits set by the user. Without this fix,
    attempts to write temperature limits above the maximum supported by
    the chip (255 degrees Celsius) would arbitrarily and unexpectedly
    result in the limit being set to 0 degree Celsius.

    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd5a1b14d8c2f6ca3692aa4d829aa4afb1319f0e
Author: Andiry Xu <andiry.xu@amd.com>
Date:   Wed Jan 18 17:47:12 2012 +0800

    xHCI: Cleanup isoc transfer ring when TD length mismatch found

    commit cf840551a884360841bd3d3ce1ad0868ff0b759a upstream.

    When a TD length mismatch is found during isoc TRB enqueue, it directly
    returns -EINVAL. However, isoc transfer is partially enqueued at this time,
    and the ring should be cleared.

    This should be backported to kernels as old as 2.6.36, which contain the
    commit 522989a27c7badb608155b1f1dea3487ed431f74 "xhci: Fix failed
    enqueue in the middle of isoch TD."

    Signed-off-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5c55d20f4251bcc22ce82ff82add9839027e818
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Nov 14 17:51:39 2011 -0800

    xhci: Fix USB 3.0 device restart on resume.

    commit d0cd5d482b8a6dc92c6c69a5387baf72ea84f23a upstream.

    The xHCI hub port code gets passed a zero-based port number by the USB
    core.  It then adds one to in order to find a device slot by port number
    and device speed by calling xhci_find_slot_id_by_port.  That function
    clearly states it requires a one-based port number.  The xHCI port
    status change event handler was using a zero-based port number that it
    got from find_faked_portnum_from_hw_portnum, not a one-based port
    number.  This lead to the doorbells never being rung for a device after
    a resume, or worse, a different device with the same speed having its
    doorbell rung (which could lead to bad power management in the xHCI host
    controller).

    This patch should be backported to kernels as old as 2.6.39.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Acked-by: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a1d0b0af0dcb47bab73e4aa95b4b6afaee4a75c
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Thu Jan 12 10:55:13 2012 +0100

    drivers/usb/host/ehci-fsl.c: add missing iounmap

    commit 2492c6e6454ff3edb11e273b071a6ea80a199c71 upstream.

    Add missing iounmap in error handling code, in a case where the function
    already preforms iounmap on some other execution path.

    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)

    // <smpl>
    @@
    expression e;
    statement S,S1;
    int ret;
    @@
    e = \(ioremap\|ioremap_nocache\)(...)
    ... when != iounmap(e)
    if (<+...e...+>) S
    ... when any
        when != iounmap(e)
    *if (...)
       { ... when != iounmap(e)
         return ...; }
    ... when any
    iounmap(e);
    // </smpl>

    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a607902f65e6d425f8d115ac891a3c89f3b36d33
Author: Harrison Metzger <harrisonmetz@gmail.com>
Date:   Sun Jan 15 08:43:24 2012 -0600

    USB: usbsevseg: fix max length

    commit 1097ccebe630170080c41df0edcf88e0626e9c75 upstream.

    This changes the max length for the usb seven segment delcom device to 8
    from 6. Delcom has both 6 and 8 variants and having 8 works fine with
    devices which are only 6.

    Signed-off-by: Harrison Metzger <harrisonmetz@gmail.com>
    Signed-off-by: Stuart Pook <stuart@acm.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fc6b6671559d947f3f9a6d8829d3481a17934f4
Author: Ryan Mallon <rmallon@gmail.com>
Date:   Sat Jan 28 08:51:40 2012 +1100

    vmwgfx: Fix assignment in vmw_framebuffer_create_handle

    commit bf9c05d5b6d19b3e4c9fe21047694e94f48db89b upstream.

    The assignment of handle in vmw_framebuffer_create_handle doesn't actually do anything useful and is incorrectly assigning an integer value to a pointer argument. It appears that this is a typo and should be dereferencing handle rather than assigning to it directly. This fixes a bug where an undefined handle value is potentially returned to user-space.

    Signed-off-by: Ryan Mallon <rmallon@gmail.com>
    Reviewed-by: Jakob Bornecrantz<jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5f0416d678ccf6e903002637c3bd9ce82ddb30f
Author: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Date:   Mon Jan 9 10:58:06 2012 -0200

    jsm: Fixed EEH recovery error

    commit 26aa38cafae0dbef3b2fe75ea487c83313c36d45 upstream.

    There was an error on the jsm driver that would cause it to be unable to
    recover after a second error is detected.

    At the first error, the device recovers properly:

    [72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
    [72521.485695] EEH: This PCI device has failed 1 times in the last hour:
    ...
    [72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
    [72532.105689] jsm: Port 3 added

    However, at the second error, it cascades until EEH disables the device:

    [72631.229549] Call Trace:
    ...
    [72641.725687] jsm: Port 3 added
    [72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
    [72641.725698] EEH: This PCI device has failed 3 times in the last hour:

    It was caused because the PCI state was not being saved after the first
    restore. Therefore, at the second recovery the PCI state would not be
    restored.

    Signed-off-by: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
    Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
    Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0661faa597be0c7fb7612e8968c2f508e168adf
Author: Rabin Vincent <rabin.vincent@stericsson.com>
Date:   Tue Jan 17 11:52:28 2012 +0100

    serial: amba-pl011: lock console writes against interrupts

    commit ef605fdb33883d687cff5ba75095a91b313b4966 upstream.

    Protect against pl011_console_write() and the interrupt for
    the console UART running concurrently on different CPUs.

    Otherwise the console_write could spin for a long time
    waiting for the UART to become not busy, while the other
    CPU continuously services UART interrupts and keeps the
    UART busy.

    The checks for sysrq and oops_in_progress are taken
    from 8250.c.

    Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
    Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Reviewed-by: Bibek Basu <bibek.basu@stericsson.com>
    Reviewed-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47f7a05bd076caf9bc2d60555a1282517c6eca31
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Jan 12 22:55:15 2012 +0100

    TTY: fix UV serial console regression

    commit 0eee50af5b13e00b3fb7a5fe8480419a71b8235d upstream.

    Commit 74c2107759d (serial: Use block_til_ready helper) and its fixup
    3f582b8c110 (serial: fix termios settings in open) introduced a
    regression on UV systems. The serial eventually freezes while being
    used. It's completely unpredictable and sometimes needs a heap of
    traffic to happen first.

    To reproduce this, yast installation was used as it turned out to be
    pretty reliable in reproducing. Especially during installation process
    where one doesn't have an SSH daemon running. And no monitor as the HW
    is completely headless. So this was fun to find. Given the machine
    doesn't boot on vanilla before 2.6.36 final. (And the commits above
    are older.)

    Unless there is some bad race in the code, the hardware seems to be
    pretty broken. Otherwise pure MSR read should not cause such a bug,
    or?

    So to prevent the bug, revert to the old behavior. I.e. read modem
    status only if we really have to -- for non-CLOCAL set serials.
    Non-CLOCAL works on this hardware OK, I tried. See? I don't.

    And document that shit.

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    References: https://lkml.org/lkml/2011/12/6/573
    References: https://bugzilla.novell.com/show_bug.cgi?id=718518
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74a6015d2ba393187bbfddcc910afb9e239a3e35
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Jan 13 21:32:06 2012 -0800

    usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.

    commit 6d443d8499e4e59ffb949759cdded32730f8d2f6 upstream.

    Calling edge_remove_sysfs_attrs from edge_disconnect is too late
    as the device has already been removed from sysfs.

    Do the simple and obvious thing and make edge_remove_sysfs_attrs
    the port_remove method.

    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Reported-by: Wolfgang Frisch <wfpub@roembden.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06434d3275a9d6ae3ca39f114523f015e003d8ea
Author: Dan Williams <dcbw@redhat.com>
Date:   Tue Jan 24 17:16:54 2012 -0600

    qcaux: add more Pantech UML190 and UML290 ports

    commit 074cc73506f529f39fef32ad1c9e1d4cdd8acf6c upstream.

    More ports we now know how to talk to.

    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c40c07af28b365175593f69a7391a3b6cfd8ac12
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 12:41:48 2012 +0100

    USB: cdc-wdm: use two mutexes to allow simultaneous read and write

    commit e8537bd2c4f325a4796da33564ddcef9489b7feb upstream.

    using a separate read and write mutex for locking is sufficient to make the
    driver accept simultaneous read and write. This improves useability a lot.

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 906e114c35cd8f98be1f672a2f32c0cf9800296b
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Jan 16 12:41:47 2012 +0100

    USB: cdc-wdm: updating desc->length must be protected by spin_lock

    commit c428b70c1e115c5649707a602742e34130d19428 upstream.

    wdm_in_callback() will also touch this field, so we cannot change it without locking

    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b09a4eb286bdc9dbc4c9620faa562c8470b2366
Author: Alan Cox <alan@linux.intel.com>
Date:   Thu Jan 26 17:41:34 2012 +0000

    USB: ftdi_sio: Add more identifiers

    commit 2353f806c97020d4c7709f15eebb49b591f7306d upstream.

    0x04d8, 0x000a: Hornby Elite

    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f43828eb93fe27108df3e81090bcf0cdbfe882e3
Author: Peter Naulls <peter@chocky.org>
Date:   Tue Jan 17 18:27:09 2012 -0800

    USB: serial: ftdi additional IDs

    commit fc216ec363f4d174932df90bbf35c77d0540e561 upstream.

    I tested this against 2.6.39 in the Ubuntu kernel, however I see the IDs
    are not in latest 3.2 git.

    This adds IDs for the FTDI controller in the Rainforest Automation
    Zigbee dongle.

    Signed-off-by: Peter Naulls <peter@chocky.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab9ef74e2580b4909bd9fb0c381027f54cb6d3de
Author: Peter Korsgaard <jacmet@sunsite.dk>
Date:   Wed Jan 18 23:43:45 2012 +0100

    USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3

    commit 55f13aeae0346f0c89bfface91ad9a97653dc433 upstream.

    Port A for JTAG, port B for serial.

    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b89a3229080c1464ab892cc413cc806b06d4ffa3
Author: Johan Hovold <jhovold@gmail.com>
Date:   Wed Jan 18 01:46:00 2012 +0100

    USB: ftdi_sio: fix initial baud rate

    commit 108e02b12921078a59dcacd048079ece48a4a983 upstream.

    Fix regression introduced by commit b1ffb4c851f1 ("USB: Fix Corruption
    issue in USB ftdi driver ftdi_sio.c") which caused the termios settings
    to no longer be initialised at open. Consequently it was no longer
    possible to set the port to the default speed of 9600 baud without first
    changing to another baud rate and back again.

    Reported-by: Roland Ramthun <mail@roland-ramthun.de>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Tested-by: Roland Ramthun <mail@roland-ramthun.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38a464d3f7a94a7bd3cac9d8cd18474385e27633
Author: Johan Hovold <jhovold@gmail.com>
Date:   Tue Jan 10 23:33:37 2012 +0100

    USB: ftdi_sio: fix TIOCSSERIAL baud_base handling

    commit eb833a9e0972f60beb4ab8104ad7ef6bf30f02fc upstream.

    Return EINVAL if new baud_base does not match the current one.

    The baud_base is device specific and can not be changed. This restores
    the old (pre-2005) behaviour which was changed due to a
    misunderstanding regarding this fact (see
    https://lkml.org/lkml/2005/1/20/84).

    Reported-by: Torbjörn Lofterud <torbjorn@pi.nxs.se>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 163071a2a0d661eb3b8abe14d892a88e6dedc77f
Author: Kentaro Matsuyama <kentaro.matsuyama@gmail.com>
Date:   Thu Jan 12 23:07:51 2012 +0900

    USB: option: Add LG docomo L-02C

    commit e423d7401fd0717cb56a6cf51dd8341cc3e800d2 upstream.

    Add vendor and product ID for USB 3G/LTE modem of docomo L-02C

    Signed-off-by: Kentaro Matsuyama <kentaro.matsuyama@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95086de856ca703588967f63cc54b8059db55888
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jan 20 12:10:18 2012 +0100

    ARM: 7296/1: proc-v7.S: remove HARVARD_CACHE preprocessor guards

    commit 612539e81f655f6ac73c7af1da8701c1ee618aee upstream.

    On v7, we use the same cache maintenance instructions for data lines
    as for unified lines. This was not the case for v6, where HARVARD_CACHE
    was defined to indicate the L1 cache topology.

    This patch removes the erroneous compile-time check for HARVARD_CACHE in
    proc-v7.S, ensuring that we perform I-side invalidation at boot.

    Reported-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>

    Acked-by: Catalin Marinas <Catalin.Marinas@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 4e29fa93520b401b81a719fe053f06c6937d5b66
Author: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
Date:   Thu Jan 12 11:07:43 2012 +0530

    mach-ux500: enable ARM errata 764369

    commit d65015f7c5c5be9fd3f5e567889c844ba81bdc9c upstream.

    This applies ARM errata 764369 for all ux500 platforms.

    Signed-off-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e21ed1cebed09df11b4bf7809fd6d69b25457127
Author: Jonathan Nieder <jrnieder@gmail.com>
Date:   Mon Aug 8 06:22:43 2011 +0200

    cap_syslog: don't use WARN_ONCE for CAP_SYS_ADMIN deprecation warning

    commit f2c0d0266cc5eb36a4aa44944b4096ec121490aa upstream.

    syslog-ng versions before 3.3.0beta1 (2011-05-12) assume that
    CAP_SYS_ADMIN is sufficient to access syslog, so ever since CAP_SYSLOG
    was introduced (2010-11-25) they have triggered a warning.

    Commit ee24aebffb75 ("cap_syslog: accept CAP_SYS_ADMIN for now")
    improved matters a little by making syslog-ng work again, just keeping
    the WARN_ONCE().  But still, this is a warning that writes a stack trace
    we don't care about to syslog, sets a taint flag, and alarms sysadmins
    when nothing worse has happened than use of an old userspace with a
    recent kernel.

    Convert the WARN_ONCE to a printk_once to avoid that while continuing to
    give userspace developers a hint that this is an unwanted
    backward-compatibility feature and won't be around forever.

    Reported-by: Ralf Hildebrandt <ralf.hildebrandt@charite.de>
    Reported-by: Niels <zorglub_olsen@hotmail.com>
    Reported-by: Paweł Sikora <pluto@agmk.net>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Liked-by: Gergely Nagy <algernon@madhouse-project.org>
    Acked-by: Serge Hallyn <serge@hallyn.com>
    Acked-by: James Morris <jmorris@namei.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e2d7afcbacf7683c72e98980c6a9284a5a2a01c
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Jan 6 19:45:34 2012 -0200

    drm/i915/sdvo: always set positive sync polarity

    commit ba68e086223a5f149f37bf8692c8cdbf1b0ba3ef upstream.

    This is a revert of 81a14b46846fea0741902e8d8dfcc6c6c78154c8.

    We already set the mode polarity using the SDVO commands with struct
    intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch.
    The documentation, despite not clear, can also be interpreted in a way
    that suggests this patch is needed.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80f1aff93c34feff6ad229ff2a1307e82cb5b132
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jan 26 15:56:16 2012 +0100

    ALSA: hda - Fix silent output on Haier W18 laptop

    commit b3a81520bd37a28f77cb0f7002086fb14061824d upstream.

    The very same problem is seen on Haier W18 laptop with ALC861 as seen
    on ASUS A6Rp, which was fixed by the commit 3b25eb69.
    Now we just need to add a new SSID entry pointing to the same fixup.

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

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

commit 2fd55451aab99558e8b3ccefd88a1c14ed888c75
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 25 09:55:46 2012 +0100

    ALSA: hda - Fix silent output on ASUS A6Rp

    commit 3b25eb690e8c7424eecffe1458c02b87b32aa001 upstream.

    The refactoring of Realtek codec driver in 3.2 kernel caused a
    regression for ASUS A6Rp laptop; it doesn't give any output.
    The reason was that this machine has a secret master mute (or EAPD)
    control via NID 0x0f VREF.  Setting VREF50 on this node makes the
    sound working again.

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

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

commit 231f0496129d5d41ae77cc2410e3cea97540cd7b
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Fri Jan 20 17:44:12 2012 +0100

    x86/microcode_amd: Add support for CPU family specific container files

    commit 5b68edc91cdc972c46f76f85eded7ffddc3ff5c2 upstream.

    We've decided to provide CPU family specific container files
    (starting with CPU family 15h). E.g. for family 15h we have to
    load microcode_amd_fam15h.bin instead of microcode_amd.bin

    Rationale is that starting with family 15h patch size is larger
    than 2KB which was hard coded as maximum patch size in various
    microcode loaders (not just Linux).

    Container files which include patches larger than 2KB cause
    different kinds of trouble with such old patch loaders. Thus we
    have to ensure that the default container file provides only
    patches with size less than 2KB.

    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Cc: Borislav Petkov <borislav.petkov@amd.com>
    Cc: <stable@kernel.org>
    Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com
    [ documented the naming convention and tidied the code a bit. ]
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c6f009ebfcdae4196be7e456c99ad44eb013420
Author: Russ Anderson <rja@sgi.com>
Date:   Wed Jan 18 20:07:54 2012 -0600

    x86/uv: Fix uv_gpa_to_soc_phys_ram() shift

    commit 5a51467b146ab7948d2f6812892eac120a30529c upstream.

    uv_gpa_to_soc_phys_ram() was inadvertently ignoring the
    shift values.  This fix takes the shift into account.

    Signed-off-by: Russ Anderson <rja@sgi.com>
    Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 810b80a70cd24a682239d82370725cc3b847bab8
Author: Dave Chinner <dchinner@redhat.com>
Date:   Thu Jan 26 13:47:42 2012 -0600

    xfs: fix endian conversion issue in discard code

    commit b1c770c273a4787069306fc82aab245e9ac72e9d upstream

    When finding the longest extent in an AG, we read the value directly
    out of the AGF buffer without endian conversion. This will give an
    incorrect length, resulting in FITRIM operations potentially not
    trimming everything that it should.

    Note, for 3.0-stable this has been modified to apply to
    fs/xfs/linux-2.6/xfs_discard.c instead of fs/xfs/xfs_discard.c.  -bpm

    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffee9a18f29a0645c2d117083e025f557c738018
Author: Nick Bowler <nbowler@elliptictech.com>
Date:   Thu Nov 10 09:01:27 2011 +0000

    ah: Don't return NET_XMIT_DROP on input.

    commit 4b90a603a1b21d63cf743cc833680cb195a729f6 upstream.

    When the ahash driver returns -EBUSY, AH4/6 input functions return
    NET_XMIT_DROP, presumably copied from the output code path.  But
    returning transmit codes on input doesn't make a lot of sense.
    Since NET_XMIT_DROP is a positive int, this gets interpreted as
    the next header type (i.e., success).  As that can only end badly,
    remove the check.

    Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da8ae089a79cdc37589cab581a2ca9cf48f98904
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Mon Dec 5 18:22:48 2011 +0100

    ftrace: Fix unregister ftrace_ops accounting

    commit 30fb6aa74011dcf595f306ca2727254d708b786e upstream.

    Multiple users of the function tracer can register their functions
    with the ftrace_ops structure. The accounting within ftrace will
    update the counter on each function record that is being traced.
    When the ftrace_ops filtering adds or removes functions, the
    function records will be updated accordingly if the ftrace_ops is
    still registered.

    When a ftrace_ops is removed, the counter of the function records,
    that the ftrace_ops traces, are decremented. When they reach zero
    the functions that they represent are modified to stop calling the
    mcount code.

    When changes are made, the code is updated via stop_machine() with
    a command passed to the function to tell it what to do. There is an
    ENABLE and DISABLE command that tells the called function to enable
    or disable the functions. But the ENABLE is really a misnomer as it
    should just update the records, as records that have been enabled
    and now have a count of zero should be disabled.

    The DISABLE command is used to disable all functions regardless of
    their counter values. This is the big off switch and is not the
    complement of the ENABLE command.

    To make matters worse, when a ftrace_ops is unregistered and there
    is another ftrace_ops registered, neither the DISABLE nor the
    ENABLE command are set when calling into the stop_machine() function
    and the records will not be updated to match their counter. A command
    is passed to that function that will update the mcount code to call
    the registered callback directly if it is the only one left. This
    means that the ftrace_ops that is still registered will have its callback
    called by all functions that have been set for it as well as the ftrace_ops
    that was just unregistered.

    Here's a way to trigger this bug. Compile the kernel with
    CONFIG_FUNCTION_PROFILER set and with CONFIG_FUNCTION_GRAPH not set:

     CONFIG_FUNCTION_PROFILER=y
     # CONFIG_FUNCTION_GRAPH is not set

    This will force the function profiler to use the function tracer instead
    of the function graph tracer.

      # cd /sys/kernel/debug/tracing
      # echo schedule > set_ftrace_filter
      # echo function > current_tracer
      # cat set_ftrace_filter
     schedule
      # cat trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 692/68108025   #P:4
     #
     #                              _-----=> irqs-off
     #                             / _----=> need-resched
     #                            | / _---=> hardirq/softirq
     #                            || / _--=> preempt-depth
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
          kworker/0:2-909   [000] ....   531.235574: schedule <-worker_thread
               <idle>-0     [001] .N..   531.235575: schedule <-cpu_idle
          kworker/0:2-909   [000] ....   531.235597: schedule <-worker_thread
                 sshd-2563  [001] ....   531.235647: schedule <-schedule_hrtimeout_range_clock

      # echo 1 > function_profile_enabled
      # echo 0 > function_porfile_enabled
      # cat set_ftrace_filter
     schedule
      # cat trace
     # tracer: function
     #
     # entries-in-buffer/entries-written: 159701/118821262   #P:4
     #
     #                              _-----=> irqs-off
     #                             / _----=> need-resched
     #                            | / _---=> hardirq/softirq
     #                            || / _--=> preempt-depth
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
               <idle>-0     [002] ...1   604.870655: local_touch_nmi <-cpu_idle
               <idle>-0     [002] d..1   604.870655: enter_idle <-cpu_idle
               <idle>-0     [002] d..1   604.870656: atomic_notifier_call_chain <-enter_idle
               <idle>-0     [002] d..1   604.870656: __atomic_notifier_call_chain <-atomic_notifier_call_chain

    The same problem could have happened with the trace_probe_ops,
    but they are modified with the set_frace_filter file which does the
    update at closure of the file.

    The simple solution is to change ENABLE to UPDATE and call it every
    time an ftrace_ops is unregistered.

    Link: http://lkml.kernel.org/r/1323105776-26961-3-git-send-email-jolsa@redhat.com

    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ffe3ccf80eba0ac9ca71c41e7357d92f1c08fc3
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Wed Jul 13 15:08:31 2011 -0400

    ftrace: Update filter when tracing enabled in set_ftrace_filter()

    commit 072126f4529196f71a97960248bca54fd4554c2d upstream.

    Currently, if set_ftrace_filter() is called when the ftrace_ops is
    active, the function filters will not be updated. They will only be updated
    when tracing is disabled and re-enabled.

    Update the functions immediately during set_ftrace_filter().

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f935e6192f9e068da8f8395f032ff4b721fe8510
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Wed Jul 13 15:03:44 2011 -0400

    ftrace: Balance records when updating the hash

    commit 41fb61c2d08107ce96a5dcb3a6289b2afd3e135c upstream.

    Whenever the hash of the ftrace_ops is updated, the record counts
    must be balance. This requires disabling the records that are set
    in the original hash, and then enabling the records that are set
    in the updated hash.

    Moving the update into ftrace_hash_move() removes the bug where the
    hash was updated but the records were not, which results in ftrace
    triggering a warning and disabling itself because the ftrace_ops filter
    is updated while the ftrace_ops was registered, and then the failure
    happens when the ftrace_ops is unregistered.

    The current code will not trigger this bug, but new code will.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ce5564096c4444197e6f7dc83a9dbc63392b084
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sat Jan 14 21:40:57 2012 +0300

    crypto: sha512 - reduce stack usage to safe number

    commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.

    For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
    Consequently, keeping all W[80] array on stack is unnecessary,
    only 16 values are really needed.

    Using W[16] instead of W[80] greatly reduces stack usage
    (~750 bytes to ~340 bytes on x86_64).

    Line by line explanation:
    * BLEND_OP
      array is "circular" now, all indexes have to be modulo 16.
      Round number is positive, so remainder operation should be
      without surprises.

    * initial full message scheduling is trimmed to first 16 values which
      come from data block, the rest is calculated before it's needed.

    * original loop body is unrolled version of new SHA512_0_15 and
      SHA512_16_79 macros, unrolling was done to not do explicit variable
      renaming. Otherwise it's the very same code after preprocessing.
      See sha1_transform() code which does the same trick.

    Patch survives in-tree crypto test and original bugreport test
    (ping flood with hmac(sha512).

    See FIPS 180-2 for SHA-512 definition
    http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ca6029f1a492528e65bc676113eeb1acf3779e4
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sat Jan 14 21:27:37 2012 +0300

    crypto: sha512 - make it work, undo percpu message schedule

    commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.

    commit f9e2bca6c22d75a289a349f869701214d63b5060
    aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
    created global message schedule area.

    If sha512_update will ever be entered twice, hash will be silently
    calculated incorrectly.

    Probably the easiest way to notice incorrect hashes being calculated is
    to run 2 ping floods over AH with hmac(sha512):

    	#!/usr/sbin/setkey -f
    	flush;
    	spdflush;
    	add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
    	add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
    	spdadd IP1 IP2 any -P out ipsec ah/transport//require;
    	spdadd IP2 IP1 any -P in  ipsec ah/transport//require;

    XfrmInStateProtoError will start ticking with -EBADMSG being returned
    from ah_input(). This never happens with, say, hmac(sha1).

    With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
    with multiple bidirectional ping flood streams like it doesn't tick
    with SHA-1.

    After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
    This is OK for simple loads, for something more heavy, stack reduction will be done
    separatedly.

    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fbe11fed22ed2751aaf4b4926f27730aaac5470
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jan 11 18:52:10 2012 +0000

    xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()

    commit 9b025eb3a89e041bab6698e3858706be2385d692 upstream.

    Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted
    symplink and bailed out. Fix it by jumping to 'out' instead of doing return.

    CC: Carlos Maiolino <cmaiolino@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Alex Elder <elder@kernel.org>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90af660bec3b2d47e17cb3caae742810656e2d4f
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue Jan 24 18:54:21 2012 +0100

    drm: Fix authentication kernel crash

    commit 598781d71119827b454fd75d46f84755bca6f0c6 upstream.

    If the master tries to authenticate a client using drm_authmagic and
    that client has already closed its drm file descriptor,
    either wilfully or because it was terminated, the
    call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
    and corrupt it.

    Typically this results in a hard system hang.

    This patch fixes that problem by removing any authentication tokens
    (struct drm_magic_entry) open for a file descriptor when that file
    descriptor is closed.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c196878589eb5f88e244a557a55b229a3c285b3b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Sun Jan 15 08:51:12 2012 -0500

    drm/radeon/kms: Add an MSI quirk for Dell RS690

    commit 44517c44496062180a6376cc704b33129441ce60 upstream.

    Interrupts only work with MSIs.
    https://bugs.freedesktop.org/show_bug.cgi?id=37679

    Reported-by: Dmitry Podgorny <pasis.uax@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df29ca6c2b93813c987b35972b215d9b2a0a9159
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Jan 24 10:02:22 2012 -0600

    eCryptfs: Fix oops when printing debug info in extent crypto functions

    commit 58ded24f0fcb85bddb665baba75892f6ad0f4b8a upstream.

    If pages passed to the eCryptfs extent-based crypto functions are not
    mapped and the module parameter ecryptfs_verbosity=1 was specified at
    loading time, a NULL pointer dereference will occur.

    Note that this wouldn't happen on a production system, as you wouldn't
    pass ecryptfs_verbosity=1 on a production system. It leaks private
    information to the system logs and is for debugging only.

    The debugging info printed in these messages is no longer very useful
    and rather than doing a kmap() in these debugging paths, it will be
    better to simply remove the debugging paths completely.

    https://launchpad.net/bugs/913651

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 714ca4ef28276f142b00ff2e1893f472cc30b07b
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Thu Jan 19 20:33:44 2012 -0600

    eCryptfs: Check inode changes in setattr

    commit a261a03904849c3df50bd0300efb7fb3f865137d upstream.

    Most filesystems call inode_change_ok() very early in ->setattr(), but
    eCryptfs didn't call it at all. It allowed the lower filesystem to make
    the call in its ->setattr() function. Then, eCryptfs would copy the
    appropriate inode attributes from the lower inode to the eCryptfs inode.

    This patch changes that and actually calls inode_change_ok() on the
    eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
    would happen earlier in ecryptfs_setattr(), but there are some possible
    inode initialization steps that must happen first.

    Since the call was already being made on the lower inode, the change in
    functionality should be minimal, except for the case of a file extending
    truncate call. In that case, inode_newsize_ok() was never being
    called on the eCryptfs inode. Rather than inode_newsize_ok() catching
    maximum file size errors early on, eCryptfs would encrypt zeroed pages
    and write them to the lower filesystem until the lower filesystem's
    write path caught the error in generic_write_checks(). This patch
    introduces a new function, called ecryptfs_inode_newsize_ok(), which
    checks if the new lower file size is within the appropriate limits when
    the truncate operation will be growing the lower file.

    In summary this change prevents eCryptfs truncate operations (and the
    resulting page encryptions), which would exceed the lower filesystem
    limits or FSIZE rlimits, from ever starting.

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Li Wang <liwang@nudt.edu.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8d66a0b58b353d47b05891fd20b3bdc4c8a8015
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Wed Jan 18 18:30:04 2012 -0600

    eCryptfs: Make truncate path killable

    commit 5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream.

    ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
    page, zeroes out the appropriate portions, and then encrypts the page
    before writing it to the lower filesystem. It was unkillable and due to
    the lack of sparse file support could result in tying up a large portion
    of system resources, while encrypting pages of zeros, with no way for
    the truncate operation to be stopped from userspace.

    This patch adds the ability for ecryptfs_write() to detect a pending
    fatal signal and return as gracefully as possible. The intent is to
    leave the lower file in a useable state, while still allowing a user to
    break out of the encryption loop. If a pending fatal signal is detected,
    the eCryptfs inode size is updated to reflect the modified inode size
    and then -EINTR is returned.

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b9f40e785724a265fb6027216fb2bd1e97894f7
Author: Tim Gardner <tim.gardner@canonical.com>
Date:   Thu Jan 12 16:31:55 2012 +0100

    ecryptfs: Improve metadata read failure logging

    commit 30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream.

    Print inode on metadata read failure. The only real
    way of dealing with metadata read failures is to delete
    the underlying file system file. Having the inode
    allows one to 'find . -inum INODE`.

    [tyhicks@canonical.com: Removed some minor not-for-stable parts]
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdce30003c234575bbcfddb0980adc04b82408c7
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Thu Jan 12 11:30:44 2012 +0100

    eCryptfs: Sanitize write counts of /dev/ecryptfs

    commit db10e556518eb9d21ee92ff944530d84349684f4 upstream.

    A malicious count value specified when writing to /dev/ecryptfs may
    result in a a very large kernel memory allocation.

    This patch peeks at the specified packet payload size, adds that to the
    size of the packet headers and compares the result with the write count
    value. The resulting maximum memory allocation size is approximately 532
    bytes.

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3c9ccb3e13812e13be045a97ab309a4e23d9ac4
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 23 18:23:36 2012 +0100

    ALSA: hda - Fix silent outputs from docking-station jacks of Dell laptops

    commit b4ead019afc201f71c39cd0dfcaafed4a97b3dd2 upstream.

    The recent change of the power-widget handling for IDT codecs caused
    the silent output from the docking-station line-out jack.  This was
    partially fixed by the commit f2cbba7602383cd9cdd21f0a5d0b8bd1aad47b33
    "ALSA: hda - Fix the lost power-setup of seconary pins after PM resume".
    But the line-out on the docking-station is still silent when booted
    with the jack plugged even by this fix.

    The remainig bug is that the power-widget is set off in stac92xx_init()
    because the pins in cfg->line_out_pins[] aren't checked there properly
    but only hp_pins[] are checked in is_nid_hp_pin().

    This patch fixes the problem by checking both HP and line-out pins
    and leaving the power-map correctly.

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

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.20

commit bcac798f6c44e21a6bdb2c5f8b056b364e246a35
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 6 09:31:45 2012 -0800

    Linux 3.0.20

commit 6cac12dfab9c57a4f76821412224b226a9b08dff
Author: Matthew Garrett <mjg@redhat.com>
Date:   Thu Nov 10 16:38:33 2011 -0500

    PCI: Rework ASPM disable code

    commit 3c076351c4027a56d5005a39a0b518a4ba393ce2 upstream.

    Right now we forcibly clear ASPM state on all devices if the BIOS indicates
    that the feature isn't supported. Based on the Microsoft presentation
    "PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
    that this may be an error. The implication is that unless the platform
    grants full control via _OSC, Windows will not touch any PCIe features -
    including ASPM. In that case clearing ASPM state would be an error unless
    the platform has granted us that control.

    This patch reworks the ASPM disabling code such that the actual clearing
    of state is triggered by a successful handoff of PCIe control to the OS.
    The general ASPM code undergoes some changes in order to ensure that the
    ability to clear the bits isn't overridden by ASPM having already been
    disabled. Further, this theoretically now allows for situations where
    only a subset of PCIe roots hand over control, leaving the others in the
    BIOS state.

    It's difficult to know for sure that this is the right thing to do -
    there's zero public documentation on the interaction between all of these
    components. But enough vendors enable ASPM on platforms and then set this
    bit that it seems likely that they're expecting the OS to leave them alone.

    Measured to save around 5W on an idle Thinkpad X220.

    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.21

commit 1d05f993784973189395051cc711fdd6dd5eb389
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 13 11:15:52 2012 -0800

    Linux 3.0.21

commit 8a533666d1591cf4ea596c6bd710e2fe682cb56a
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Thu Feb 9 16:13:19 2012 -0500

    net: fix NULL dereferences in check_peer_redir()

    [ Upstream commit d3aaeb38c40e5a6c08dd31a1b64da65c4352be36, along
      with dependent backports of commits:
         69cce1d1404968f78b177a0314f5822d5afdbbfb
         9de79c127cccecb11ae6a21ab1499e87aa222880
         218fa90f072e4aeff9003d57e390857f4f35513e
         580da35a31f91a594f3090b7a2c39b85cb051a12
         f7e57044eeb1841847c24aa06766c8290c202583
         e049f28883126c689cf95859480d9ee4ab23b7fa ]

    Gergely Kalman reported crashes in check_peer_redir().

    It appears commit f39925dbde778 (ipv4: Cache learned redirect
    information in inetpeer.) added a race, leading to possible NULL ptr
    dereference.

    Since we can now change dst neighbour, we should make sure a reader can
    safely use a neighbour.

    Add RCU protection to dst neighbour, and make sure check_peer_redir()
    can be called safely by different cpus in parallel.

    As neighbours are already freed after one RCU grace period, this patch
    should not add typical RCU penalty (cache cold effects)

    Many thanks to Gergely for providing a pretty report pointing to the
    bug.

    Reported-by: Gergely Kalman <synapse@hippy.csoma.elte.hu>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 323a479328cbc2fb5cf647790f7414ca570a577b
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Fri Jan 6 15:57:55 2012 +0100

    powernow-k8: Fix indexing issue

    commit a8eb28480e9b637cc78b9aa5e08612ba97e1317a upstream.

    The driver uses the pstate number from the status register as index in
    its table of ACPI pstates (powernow_table). This is wrong as this is
    not a 1-to-1 mapping.

    For example we can have _PSS information to just utilize Pstate 0 and
    Pstate 4, ie.

      powernow-k8: Core Performance Boosting: on.
      powernow-k8:    0 : pstate 0 (2200 MHz)
      powernow-k8:    1 : pstate 4 (1400 MHz)

    In this example the driver's powernow_table has just 2 entries. Using
    the pstate number (4) as index into this table is just plain wrong.

    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d8a3a209b35f8301c86e7962f636a372a0d7cad
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Date:   Fri Jan 6 15:56:31 2012 +0100

    powernow-k8: Avoid Pstate MSR accesses on systems supporting CPB

    commit 201bf0f129e1715a33568d1563d9a75b840ab4d3 upstream.

    Due to CPB we can't directly map SW Pstates to Pstate MSRs. Get rid of
    the paranoia check. (assuming that the ACPI Pstate information is
    correct.)

    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebc5010892742064d7436a1c1ff91b3189c4b8c7
Author: Axel Lin <axel.lin@gmail.com>
Date:   Wed Feb 1 12:31:47 2012 +0800

    mmc: cb710 core: Add missing spin_lock_init for irq_lock of struct cb710_chip

    commit b5266ea675c5a041e2852c7ccec4cf2d4f5e0cf4 upstream.

    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Acked-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27939dafb1bd1053fda96d69d4b693f29f2389b6
Author: Rui li <li.rui27@zte.com.cn>
Date:   Tue Jan 31 15:27:33 2012 +0800

    USB: add new zte 3g-dongle's pid to option.c

    commit 1608ea5f4b5d6262cd6e808839491cfb2a67405a upstream.

    As ZTE have and will use more pid for new products this year,
    so we need to add some new zte 3g-dongle's pid on option.c ,
    and delete one pid 0x0154 because it use for mass-storage port.

    Signed-off-by: Rui li <li.rui27@zte.com.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71f1a6a81350c7bf75141e183c1d5e310f264622
Author: Milan Kocian <milon@wq.cz>
Date:   Fri Feb 3 14:28:00 2012 +0100

    USB: usbserial: add new PID number (0xa951) to the ftdi driver

    commit 90451e6973a5da155c6f315a409ca0a8d3ce6b76 upstream.

    Signed-off-by: Milan Kocian <milon@wq.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20ef4883ff2c65f96da1617446ebc58c0a707970
Author: Jayachandran C <jayachandranc@netlogicmicro.com>
Date:   Fri Jan 27 20:27:32 2012 +0530

    usb: Skip PCI USB quirk handling for Netlogic XLP

    commit e4436a7c17ac2b5e138f93f83a541cba9b311685 upstream.

    The Netlogic XLP SoC's on-chip USB controller appears as a PCI
    USB device, but does not need the EHCI/OHCI handoff done in
    usb/host/pci-quirks.c.

    The pci-quirks.c is enabled for all vendors and devices, and is
    enabled if USB and PCI are configured.

    If we do not skip the qurik handling on XLP, the readb() call in
    ehci_bios_handoff() will cause a crash since byte access is not
    supported for EHCI registers in XLP.

    Signed-off-by: Jayachandran C <jayachandranc@netlogicmicro.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6adb709398ee159ab2ef26d51760041ca5e8262
Author: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Date:   Sun Jan 29 16:12:13 2012 +0200

    usb: gadget: zero: fix bug in loopback autoresume handling

    commit 683da59d7b8ae04891636d4b59893cd4e9b0b7e5 upstream.

    ab943a2e125b (USB: gadget: gadget zero uses new suspend/resume hooks)
    introduced a copy-paste error where f_loopback.c writes to a variable
    declared in f_sourcesink.c. This prevents one from creating gadgets
    that only have a loopback function.

    Signed-off-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc2286972bd426b03fe64d79d39d9ff9ac1c4cc3
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sat Jan 7 10:07:03 2012 -0600

    staging: r8712u: Add new Sitecom UsB ID

    commit 1793bf1deddc8ce25dc41925d5dbe64536c841b6 upstream.

    Add USB ID for SITECOM WLA-1000 V1 001 WLAN

    Reported-and-tested-by: Roland Gruber <post@rolandgruber.de>
    Reported-and-tested-by: Dario Lucia <dario.lucia@gmail.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 946972e6ab9c59142f5cb51f31ea36a090f2ce16
Author: Pekka Paalanen <pq@iki.fi>
Date:   Sun Jan 22 16:33:47 2012 +0200

    Staging: asus_oled: fix NULL-ptr crash on unloading

    commit 3589e74595a4332ebf77b5ed006f3c6686071ecd upstream.

    Asus_oled triggers the following bug on module unloading:

     usbcore: deregistering interface driver asus-oled
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
     IP: [<ffffffff8111292b>] sysfs_delete_link+0x30/0x66

     Call Trace:
      [<ffffffff81225373>] device_remove_class_symlinks+0x6b/0x70
      [<ffffffff812256a8>] device_del+0x9f/0x1ab
      [<ffffffff812257c5>] device_unregister+0x11/0x1e
      [<ffffffffa000cb82>] asus_oled_disconnect+0x4f/0x9e [asus_oled]
      [<ffffffff81277430>] usb_unbind_interface+0x54/0x103
      [<ffffffff812276c4>] __device_release_driver+0xa2/0xeb
      [<ffffffff81227794>] driver_detach+0x87/0xad
      [<ffffffff812269e9>] bus_remove_driver+0x91/0xc1
      [<ffffffff81227fb4>] driver_unregister+0x66/0x6e
      [<ffffffff812771ed>] usb_deregister+0xbb/0xc4
      [<ffffffffa000ce87>] asus_oled_exit+0x2f/0x31 [asus_oled]
      [<ffffffff81068365>] sys_delete_module+0x1b8/0x21b
      [<ffffffff810ae3de>] ? do_munmap+0x2ef/0x313
      [<ffffffff813699bb>] system_call_fastpath+0x16/0x1b

    This is due to an incorrect destruction sequence in asus_oled_exit().

    Fix the order, fixes the bug. Tested on an Asus G50V laptop only.

    Cc: Jakub Schmidtke <sjakub@gmail.com>
    Signed-off-by: Pekka Paalanen <pq@iki.fi>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f64466ca0f04dc2b138a3c1e348a7e15b91ebba
Author: Pekka Paalanen <pq@iki.fi>
Date:   Sun Jan 22 16:33:46 2012 +0200

    Staging: asus_oled: fix image processing

    commit 635032cb397b396241372fa0ff36ae758e658b23 upstream.

    Programming an image was broken, because odev->buf_offs was not advanced
    for val == 0 in append_values(). This regression was introduced in:

     commit 1ff12a4aa354bed093a0240d5e6347b1e27601bc
     Author: Kevin A. Granade <kevin.granade@gmail.com>
     Date:   Sat Sep 5 01:03:39 2009 -0500

         Staging: asus_oled: Cleaned up checkpatch issues.

    Fix the image processing by special-casing val == 0.

    I have tested this change on an Asus G50V laptop only.

    Cc: Jakub Schmidtke <sjakub@gmail.com>
    Cc: Kevin A. Granade <kevin.granade@gmail.com>
    Signed-off-by: Pekka Paalanen <pq@iki.fi>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 967a6f42d195569b596f9af39cd878803a0d1f8b
Author: Roland Dreier <roland@purestorage.com>
Date:   Mon Jan 9 17:54:00 2012 -0800

    target: Correct sense key for INVALID FIELD IN {PARAMETER LIST,CDB}

    commit 9fbc8909876a2160044e71d376848973b9bfdc3f upstream.

    According to SPC-4, the sense key for commands that are failed with
    INVALID FIELD IN PARAMETER LIST and INVALID FIELD IN CDB should be
    ILLEGAL REQUEST (5h) rather than ABORTED COMMAND (Bh).  Without this
    patch, a tcm_loop LUN incorrectly gives:

        # sg_raw -r 1 -v /dev/sda 3 1 0 0 ff 0
        Sense Information:
         Fixed format, current;  Sense key: Aborted Command
         Additional sense: Invalid field in cdb
         Raw sense data (in hex):
                70 00 0b 00 00 00 00 0a  00 00 00 00 24 00 00 00
                00 00

    While a real SCSI disk gives:

        Sense Information:
         Fixed format, current;  Sense key: Illegal Request
         Additional sense: Invalid field in cdb
         Raw sense data (in hex):
                70 00 05 00 00 00 00 18  00 00 00 00 24 00 00 00
                00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

    with the main point being that the real disk gives a sense key of
    ILLEGAL REQUEST (5h).

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a8c4aa9e22c2de7af17ea48b7cc868f5bc79ad
Author: Marco Sanvido <marco@purestorage.com>
Date:   Tue Jan 3 17:12:58 2012 -0800

    target: Allow PERSISTENT RESERVE IN for non-reservation holder

    commit 6816966a8418b980481b4dced7eddd1796b145e8 upstream.

    Initiators that aren't the active reservation holder should be able to
    do a PERSISTENT RESERVE IN command in all cases, so add it to the list
    of allowed CDBs in core_scsi3_pr_seq_non_holder().

    Signed-off-by: Marco Sanvido <marco@purestorage.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b96473a25fa375b08c9bf0c1c0dbf47ca826eaec
Author: Marco Sanvido <marco@purestorage.com>
Date:   Tue Jan 3 17:12:57 2012 -0800

    target: Use correct preempted registration sense code

    commit 9e08e34e3735ae057eb3834da3570995811b7eb9 upstream.

    The comments quote the right parts of the spec:

       * d) Establish a unit attention condition for the
       *    initiator port associated with every I_T nexus
       *    that lost its registration other than the I_T
       *    nexus on which the PERSISTENT RESERVE OUT command
       *    was received, with the additional sense code set
       *    to REGISTRATIONS PREEMPTED.

    and

       * e) Establish a unit attention condition for the initiator
       *    port associated with every I_T nexus that lost its
       *    persistent reservation and/or registration, with the
       *    additional sense code set to REGISTRATIONS PREEMPTED;

    but the actual code accidentally uses ASCQ_2AH_RESERVATIONS_PREEMPTED
    instead of ASCQ_2AH_REGISTRATIONS_PREEMPTED.  Fix this.

    Signed-off-by: Marco Sanvido <marco@purestorage.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91b08ca08c8f5fbad289950086d6fb7ab0642d63
Author: Hugh Dickins <hughd@google.com>
Date:   Wed Feb 8 17:13:40 2012 -0800

    mm: fix UP THP spin_is_locked BUGs

    commit b9980cdcf2524c5fe15d8cbae9c97b3ed6385563 upstream.

    Fix CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_SMP=n CONFIG_DEBUG_VM=y
    CONFIG_DEBUG_SPINLOCK=n kernel: spin_is_locked() is then always false,
    and so triggers some BUGs in Transparent HugePage codepaths.

    asm-generic/bug.h mentions this problem, and provides a WARN_ON_SMP(x);
    but being too lazy to add VM_BUG_ON_SMP, BUG_ON_SMP, WARN_ON_SMP_ONCE,
    VM_WARN_ON_SMP_ONCE, just test NR_CPUS != 1 in the existing VM_BUG_ONs.

    Signed-off-by: Hugh Dickins <hughd@google.com>
    Cc: Andrea Arcangeli <aarcange@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 b9134812300fd0e3c242c50af5c563065d2f1b1e
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Feb 8 17:13:38 2012 -0800

    mm: compaction: check for overlapping nodes during isolation for migration

    commit dc9086004b3d5db75997a645b3fe08d9138b7ad0 upstream.

    When isolating pages for migration, migration starts at the start of a
    zone while the free scanner starts at the end of the zone.  Migration
    avoids entering a new zone by never going beyond the free scanned.

    Unfortunately, in very rare cases nodes can overlap.  When this happens,
    migration isolates pages without the LRU lock held, corrupting lists
    which will trigger errors in reclaim or during page free such as in the
    following oops

      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: [<ffffffff810f795c>] free_pcppages_bulk+0xcc/0x450
      PGD 1dda554067 PUD 1e1cb58067 PMD 0
      Oops: 0000 [#1] SMP
      CPU 37
      Pid: 17088, comm: memcg_process_s Tainted: G            X
      RIP: free_pcppages_bulk+0xcc/0x450
      Process memcg_process_s (pid: 17088, threadinfo ffff881c2926e000, task ffff881c2926c0c0)
      Call Trace:
        free_hot_cold_page+0x17e/0x1f0
        __pagevec_free+0x90/0xb0
        release_pages+0x22a/0x260
        pagevec_lru_move_fn+0xf3/0x110
        putback_lru_page+0x66/0xe0
        unmap_and_move+0x156/0x180
        migrate_pages+0x9e/0x1b0
        compact_zone+0x1f3/0x2f0
        compact_zone_order+0xa2/0xe0
        try_to_compact_pages+0xdf/0x110
        __alloc_pages_direct_compact+0xee/0x1c0
        __alloc_pages_slowpath+0x370/0x830
        __alloc_pages_nodemask+0x1b1/0x1c0
        alloc_pages_vma+0x9b/0x160
        do_huge_pmd_anonymous_page+0x160/0x270
        do_page_fault+0x207/0x4c0
        page_fault+0x25/0x30

    The "X" in the taint flag means that external modules were loaded but but
    is unrelated to the bug triggering.  The real problem was because the PFN
    layout looks like this

      Zone PFN ranges:
        DMA      0x00000010 -> 0x00001000
        DMA32    0x00001000 -> 0x00100000
        Normal   0x00100000 -> 0x01e80000
      Movable zone start PFN for each node
      early_node_map[14] active PFN ranges
          0: 0x00000010 -> 0x0000009b
          0: 0x00000100 -> 0x0007a1ec
          0: 0x0007a354 -> 0x0007a379
          0: 0x0007f7ff -> 0x0007f800
          0: 0x00100000 -> 0x00680000
          1: 0x00680000 -> 0x00e80000
          0: 0x00e80000 -> 0x01080000
          1: 0x01080000 -> 0x01280000
          0: 0x01280000 -> 0x01480000
          1: 0x01480000 -> 0x01680000
          0: 0x01680000 -> 0x01880000
          1: 0x01880000 -> 0x01a80000
          0: 0x01a80000 -> 0x01c80000
          1: 0x01c80000 -> 0x01e80000

    The fix is straight-forward.  isolate_migratepages() has to make a
    similar check to isolate_freepage to ensure that it never isolates pages
    from a zone it does not hold the LRU lock for.

    This was discovered in a 3.0-based kernel but it affects 3.1.x, 3.2.x
    and current mainline.

    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Nazarewicz <mina86@mina86.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 a5e2ba3e021e7a3135a7dbb8e188d21971a59f49
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed Feb 8 17:13:41 2012 -0800

    pcmcia: fix socket refcount decrementing on each resume

    commit 025e4ab3db07fcbf62c01e4f30d1012234beb980 upstream.

    This fixes a memory-corrupting bug: not only does it cause the warning,
    but as a result of dropping the refcount to zero, it causes the
    pcmcia_socket0 device structure to be freed while it still has
    references, causing slab caches corruption.  A fatal oops quickly
    follows this warning - often even just a 'dmesg' following the warning
    causes the kernel to oops.

    While testing suspend/resume on an ARM device with PCMCIA support, and a
    CF card inserted, I found that after five suspend and resumes, the
    kernel would complain, and shortly die after with slab corruption.

      WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()

    As the message doesn't give a clue about which kobject, and the built-in
    debugging in drivers/base/power/main.c happens too late, this was added
    right before each get_device():

      printk("%s: %p [%s] %u\n", __func__, dev, kobject_name(&dev->kobj), atomic_read(&dev->kobj.kref.refcount));

    and on the 3rd s2ram cycle, the following behaviour observed:

    On the 3rd suspend/resume cycle:

      dpm_prepare: c1a0d998 [pcmcia_socket0] 3
      dpm_suspend: c1a0d998 [pcmcia_socket0] 3
      dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 3
      dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 3
      dpm_resume: c1a0d998 [pcmcia_socket0] 3
      dpm_complete: c1a0d998 [pcmcia_socket0] 2

    4th:

      dpm_prepare: c1a0d998 [pcmcia_socket0] 2
      dpm_suspend: c1a0d998 [pcmcia_socket0] 2
      dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 2
      dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 2
      dpm_resume: c1a0d998 [pcmcia_socket0] 2
      dpm_complete: c1a0d998 [pcmcia_socket0] 1

    5th:

      dpm_prepare: c1a0d998 [pcmcia_socket0] 1
      dpm_suspend: c1a0d998 [pcmcia_socket0] 1
      dpm_suspend_noirq: c1a0d998 [pcmcia_socket0] 1
      dpm_resume_noirq: c1a0d998 [pcmcia_socket0] 1
      dpm_resume: c1a0d998 [pcmcia_socket0] 1
      dpm_complete: c1a0d998 [pcmcia_socket0] 0
      ------------[ cut here ]------------
      WARNING: at include/linux/kref.h:41 kobject_get+0x28/0x50()
      Modules linked in: ucb1x00_core
      Backtrace:
      [<c0212090>] (dump_backtrace+0x0/0x110) from [<c04799dc>] (dump_stack+0x18/0x1c)
      [<c04799c4>] (dump_stack+0x0/0x1c) from [<c021cba0>] (warn_slowpath_common+0x50/0x68)
      [<c021cb50>] (warn_slowpath_common+0x0/0x68) from [<c021cbdc>] (warn_slowpath_null+0x24/0x28)
      [<c021cbb8>] (warn_slowpath_null+0x0/0x28) from [<c0335374>] (kobject_get+0x28/0x50)
      [<c033534c>] (kobject_get+0x0/0x50) from [<c03804f4>] (get_device+0x1c/0x24)
      [<c0388c90>] (dpm_complete+0x0/0x1a0) from [<c0389cc0>] (dpm_resume_end+0x1c/0x20)
      ...

    Looking at commit 7b24e7988263 ("pcmcia: split up central event handler"),
    the following change was made to cs.c:

                    return 0;
            }
     #endif
    -
    -       send_event(skt, CS_EVENT_PM_RESUME, CS_EVENT_PRI_LOW);
    +       if (!(skt->state & SOCKET_CARDBUS) && (skt->callback))
    +               skt->callback->early_resume(skt);
            return 0;
     }

    And the corresponding change in ds.c is from:

    -static int ds_event(struct pcmcia_socket *skt, event_t event, int priority)
    -{
    -       struct pcmcia_socket *s = pcmcia_get_socket(skt);
    ...
    -       switch (event) {
    ...
    -       case CS_EVENT_PM_RESUME:
    -               if (verify_cis_cache(skt) != 0) {
    -                       dev_dbg(&skt->dev, "cis mismatch - different card\n");
    -                       /* first, remove the card */
    -                       ds_event(skt, CS_EVENT_CARD_REMOVAL, CS_EVENT_PRI_HIGH);
    -                       mutex_lock(&s->ops_mutex);
    -                       destroy_cis_cache(skt);
    -                       kfree(skt->fake_cis);
    -                       skt->fake_cis = NULL;
    -                       s->functions = 0;
    -                       mutex_unlock(&s->ops_mutex);
    -                       /* now, add the new card */
    -                       ds_event(skt, CS_EVENT_CARD_INSERTION,
    -                                CS_EVENT_PRI_LOW);
    -               }
    -               break;
    ...
    -    }

    -    pcmcia_put_socket(s);

    -    return 0;
    -} /* ds_event */

    to:

    +static int pcmcia_bus_early_resume(struct pcmcia_socket *skt)
    +{
    +       if (!verify_cis_cache(skt)) {
    +               pcmcia_put_socket(skt);
    +               return 0;
    +       }

    +       dev_dbg(&skt->dev, "cis mismatch - different card\n");

    +       /* first, remove the card */
    +       pcmcia_bus_remove(skt);
    +       mutex_lock(&skt->ops_mutex);
    +       destroy_cis_cache(skt);
    +       kfree(skt->fake_cis);
    +       skt->fake_cis = NULL;
    +       skt->functions = 0;
    +       mutex_unlock(&skt->ops_mutex);

    +       /* now, add the new card */
    +       pcmcia_bus_add(skt);
    +       return 0;
    +}

    As can be seen, the original function called pcmcia_get_socket() and
    pcmcia_put_socket() around the guts, whereas the replacement code
    calls pcmcia_put_socket() only in one path.  This creates an imbalance
    in the refcounting.

    Testing with pcmcia_put_socket() put removed shows that the bug is gone:

      dpm_suspend: c1a10998 [pcmcia_socket0] 5
      dpm_suspend_noirq: c1a10998 [pcmcia_socket0] 5
      dpm_resume_noirq: c1a10998 [pcmcia_socket0] 5
      dpm_resume: c1a10998 [pcmcia_socket0] 5
      dpm_complete: c1a10998 [pcmcia_socket0] 5

    Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b42237845c6c1f94479320b012664bbf07bb989
Author: Susan Gao <sgao@opensource.wolfsonmicro.com>
Date:   Mon Jan 30 13:57:04 2012 -0800

    ASoC: wm8962: Fix word length configuration

    commit 2b6712b19531e22455e7fa18371c5ba9eec76699 upstream.

    Signed-off-by: Susan Gao <sgao@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b855f76b5f217bd6d03c7dfa38a64b51143338ac
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Wed Feb 1 23:46:58 2012 +0000

    ASoC: wm_hubs: Correct line input to line output 2 paths

    commit 43b6cec27e1e50a1de3eff47e66e502f3fe7e66e upstream.

    The second line output mixer has the controls for the line input bypasses
    in the opposite order.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30b4b3a54fc6ca34c6f8a18b56c83680ad0a7fa9
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Jan 31 11:55:32 2012 +0000

    ASoC: wm_hubs: Fix routing of input PGAs to line output mixer

    commit ee76744c51ec342df9822b4a85dbbfc3887b6d60 upstream.

    IN1L/R is routed to both line output mixers, we don't route IN1 to LINEOUT1
    and IN2 to LINEOUT2.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb521fbb338f21b2de12fe8f7e4fa5b7e4f9fb2a
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Jan 27 05:43:59 2012 -0800

    hwmon: (w83627ehf) Fix number of fans for NCT6776F

    commit 585c0fd8216e0c9f98e2434092af7ec0f999522d upstream.

    NCT6776F can select fan input pins for fans 3 to 5 with a secondary set of
    chip register bits. Check that second set of bits in addition to the first set
    to detect if fans 3..5 are monitored.

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

commit d378b2d044139f88384d278bd5830669c44c789b
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Mon Nov 14 13:13:49 2011 +0100

    lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep

    commit df754e6af2f237a6c020c0daff55a1a609338e31 upstream.

    It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false
    lockdep messages, so do not disable lockdep in that case.
    We still want to keep lockdep disabled in the
    TAINT_OOT_MODULE case:

      - bin-only modules can cause various instabilities in
        their and in unrelated kernel code

      - they are impossible to debug for kernel developers

      - they also typically do not have the copyright license
        permission to link to the GPL-ed lockdep code.

    Suggested-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-xopopjjens57r0i13qnyh2yo@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e02c339f506e10fadf8a5f00f1c932035596ed8e
Author: Hubert Feurstein <h.feurstein@gmail.com>
Date:   Mon Jan 9 17:23:57 2012 +0100

    atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume

    commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream.

    An error was existing in the saving of CONTRAST_CTR register
    across suspend/resume.

    Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a415a8da853b0724413680a769d89affc8b5be5
Author: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Date:   Thu Feb 2 15:28:28 2012 -0600

    cifs: Fix oops in session setup code for null user mounts

    commit de47a4176c532ef5961b8a46a2d541a3517412d3 upstream.

    For null user mounts, do not invoke string length function
    during session setup.

    Reported-and-Tested-by: Chris Clayton <chris2553@googlemail.com>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a11d5d7fb7988a92e798dfbed7cdd350c0701cc
Author: Li Wang <liwang@nudt.edu.cn>
Date:   Thu Jan 19 09:44:36 2012 +0800

    eCryptfs: Infinite loop due to overflow in ecryptfs_write()

    commit 684a3ff7e69acc7c678d1a1394fe9e757993fd34 upstream.

    ecryptfs_write() can enter an infinite loop when truncating a file to a
    size larger than 4G. This only happens on architectures where size_t is
    represented by 32 bits.

    This was caused by a size_t overflow due to it incorrectly being used to
    store the result of a calculation which uses potentially large values of
    type loff_t.

    [tyhicks@canonical.com: rewrite subject and commit message]
    Signed-off-by: Li Wang <liwang@nudt.edu.cn>
    Signed-off-by: Yunchuan Wen <wenyunchuan@kylinos.com.cn>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dade9ad146b19c22141032d84190d2220623d2ca
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Sat Jan 7 23:40:35 2012 -0200

    drm/i915: handle 3rd pipe

    commit 07c1e8c1462fa7324de4c36ae9e55da2abd79cee upstream.

    We don't need to check 3rd pipe specifically, as it shares PLL with some
    other one.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41977
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd26f229584ab3c0470410550d3c69bf3c9d29ee
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Wed Dec 14 21:10:06 2011 -0200

    drm/i915: Fix TV Out refresh rate.

    commit 23bd15ec662344dc10e9918fdd0dbc58bc71526d upstream.

    TV Out refresh rate was half of the specification for almost all modes.
    Due to this reason pixel clock was so low for some modes causing flickering screen.

    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b19005c6230e6a65d3fe3de8f514feac7d2eebb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Nov 27 18:58:17 2011 +0100

    drm/i915: check ACTHD of all rings

    commit 097354eb14fa94d31a09c64d640643f58e4a5a9a upstream.

    Otherwise hangcheck spuriously fires when running blitter/bsd-only
    workloads.

    Contrary to a similar patch by Ben Widawsky this does not check
    INSTDONE of the other rings. Chris Wilson implied that in a failure to
    detect a hang, most likely because INSTDONE was fluctuating. Thus only
    check ACTHD, which as far as I know is rather reliable. Also, blitter
    and bsd rings can't launch complex tasks from a single instruction
    (like 3D_PRIM on the render with complex or even infinite shaders).

    This fixes spurious gpu hang detection when running
    tests/gem_hangcheck_forcewake on snb/ivb.

    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f8991ccf771442ae2423971798a6ca9d6db6343
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Fri Dec 9 20:42:21 2011 +0800

    drm/i915: DisplayPort hot remove notification to audio driver

    commit 832afda6a7d7235ef0e09f4ec46736861540da6d upstream.

    On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly,
    so that the audio driver will receive hot plug events and take action
    to refresh its device state and ELD contents.

    Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled
    only when the link training is complete and set to "Normal".

    Tested OK for both hot plug/remove and DPMS on/off.

    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 032aa01c0b53e12b3ac46db8e7202a3230a83a89
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Fri Dec 9 20:42:20 2011 +0800

    drm/i915: HDMI hot remove notification to audio driver

    commit 2deed761188d7480eb5f7efbfe7aa77f09322ed8 upstream.

    On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that
    the audio driver will receive hot plug events and take action to refresh
    its device state and ELD contents.

    The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing
    HDMI audio after DPMS on.

    CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1357ed0b4b9db30846377febb40a847d6103c991
Author: Jan Kara <jack@suse.cz>
Date:   Fri Dec 23 11:53:07 2011 +0100

    udf: Mark LVID buffer as uptodate before marking it dirty

    commit 853a0c25baf96b028de1654bea1e0c8857eadf3d upstream.

    When we hit EIO while writing LVID, the buffer uptodate bit is cleared.
    This then results in an anoying warning from mark_buffer_dirty() when we
    write the buffer again. So just set uptodate flag unconditionally.

    Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10f672f1a199240bc2a77d6f81e1d37f33ba743e
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Sep 20 11:41:54 2011 +0100

    ASoC: Ensure we generate a driver name

    commit f0e8ed858edb327802ee65fd695cc1538286226f upstream.

    Commit 873bd4c (ASoC: Don't set invalid name string to snd_card->driver
    field) broke generation of a driver name for all ASoC cards relying on the
    automatic generation of one. Fix this by using the old default with spaces
    replaced by underscores.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Acked-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c27711dc7f2cff89cee6a47026d936672cb29350
Author: Chanho Min <chanho0207@gmail.com>
Date:   Thu Jan 5 20:00:19 2012 +0900

    sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW

    commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d upstream.

    This issue happens under the following conditions:

     1. preemption is off
     2. __ARCH_WANT_INTERRUPTS_ON_CTXSW is defined
     3. RT scheduling class
     4. SMP system

    Sequence is as follows:

     1.suppose current task is A. start schedule()
     2.task A is enqueued pushable task at the entry of schedule()
       __schedule
        prev = rq->curr;
        ...
        put_prev_task
         put_prev_task_rt
          enqueue_pushable_task
     4.pick the task B as next task.
       next = pick_next_task(rq);
     3.rq->curr set to task B and context_switch is started.
       rq->curr = next;
     4.At the entry of context_swtich, release this cpu's rq->lock.
       context_switch
        prepare_task_switch
         prepare_lock_switch
          raw_spin_unlock_irq(&rq->lock);
     5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context
     6.try_to_wake_up() which called by ISR acquires rq->lock
        try_to_wake_up
         ttwu_remote
          rq = __task_rq_lock(p)
          ttwu_do_wakeup(rq, p, wake_flags);
            task_woken_rt
     7.push_rt_task picks the task A which is enqueued before.
       task_woken_rt
        push_rt_tasks(rq)
         next_task = pick_next_pushable_task(rq)
     8.At find_lock_lowest_rq(), If double_lock_balance() returns 0,
       lowest_rq can be the remote rq.
      (But,If preemption is on, double_lock_balance always return 1 and it
       does't happen.)
       push_rt_task
        find_lock_lowest_rq
         if (double_lock_balance(rq, lowest_rq))..
     9.find_lock_lowest_rq return the available rq. task A is migrated to
       the remote cpu/rq.
       push_rt_task
        ...
        deactivate_task(rq, next_task, 0);
        set_task_cpu(next_task, lowest_rq->cpu);
        activate_task(lowest_rq, next_task, 0);
     10. But, task A is on irq context at this cpu.
         So, task A is scheduled by two cpus at the same time until restore from IRQ.
         Task A's stack is corrupted.

    To fix it, don't migrate an RT task if it's still running.

    Signed-off-by: Chanho Min <chanho.min@lge.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/CAOAMb1BHA=5fm7KTewYyke6u-8DP0iUuJMpgQw54vNeXFsGpoQ@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32c4490a6ffbe3de604581f5fdce361eb049acff
Author: Seth Forshee <seth.forshee@canonical.com>
Date:   Tue Jan 31 19:06:25 2012 -0600

    drm/radeon/kms: disable output polling when suspended

    commit 86698c20f71d488b32c49ed4687fb3cf8a88a5ca upstream.

    Polling the outputs when the device is suspended can result in erroneous
    status updates. Disable output polling during suspend to prevent this
    from happening.

    Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1cf4ad959d7b2644f2be70ff38030d6cd3cbede
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Jan 10 10:18:28 2012 +1000

    drm/nouveau/gem: fix fence_sync race / oops

    commit 525895ba388c949aa906f26e3ec5cb1ab041f56b upstream.

    Due to a race it was possible for a fence to be destroyed while another
    thread was trying to synchronise with it.  If this happened in the fallback
    non-semaphore path, it lead to the following oops due to fence->channel
    being NULL.

    BUG: unable to handle kernel NULL pointer dereference at   (null)
    IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau]
    *pde = a649c067
    SMP
    Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]

    Pid: 2255, comm: gnome-shell Tainted: G           O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
    EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1
    EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
    EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
    ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
    Stack:
     7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
     00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
     00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
    Call Trace:
     [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
     [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau]
     [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
     [<fa964046>] validate_list+0x176/0x300 [nouveau]
     [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm]
     [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
     [<c0406481>] ? die+0x31/0x80
     [<f7c93d98>] drm_ioctl+0x388/0x490 [drm]
     [<c0406481>] ? die+0x31/0x80
     [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
     [<c0635c7b>] ? file_has_perm+0xcb/0xe0
     [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm]
     [<c0564f56>] do_vfs_ioctl+0x86/0x5b0
     [<c0406481>] ? die+0x31/0x80
     [<c0635f22>] ? selinux_file_ioctl+0x62/0x130
     [<c0554f30>] ? fget_light+0x30/0x340
     [<c05654ef>] sys_ioctl+0x6f/0x80
     [<c099e3a4>] syscall_call+0x7/0xb
     [<c0406481>] ? die+0x31/0x80
     [<c0406481>] ? die+0x31/0x80

    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5e9a83833c2effd51bb138b598636f4ed661498
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Feb 1 12:09:55 2012 +0100

    drm/radeon: Set DESKTOP_HEIGHT register to the framebuffer (not mode) height.

    commit 1b61925061660009f5b8047f93c5297e04541273 upstream.

    The value of this register is transferred to the V_COUNTER register at the
    beginning of vertical blank. V_COUNTER is the reference for VLINE waits and
    goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout,
    so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the
    beginning of vertical blank, and VLINE waits excluding the whole scanout area
    could never finish (possibly only if VIEWPORT_Y_START is larger than the length
    of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer
    height should prevent this for any kind of VLINE wait.

    Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 .

    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77650df5a701fb3a7acadfb347ebfb0e95cffe09
Author: Mel Gorman <mgorman@suse.de>
Date:   Fri Feb 3 15:37:18 2012 -0800

    mm: compaction: check pfn_valid when entering a new MAX_ORDER_NR_PAGES block during isolation for migration

    commit 0bf380bc70ecba68cb4d74dc656cc2fa8c4d801a upstream.

    When isolating for migration, migration starts at the start of a zone
    which is not necessarily pageblock aligned.  Further, it stops isolating
    when COMPACT_CLUSTER_MAX pages are isolated so migrate_pfn is generally
    not aligned.  This allows isolate_migratepages() to call pfn_to_page() on
    an invalid PFN which can result in a crash.  This was originally reported
    against a 3.0-based kernel with the following trace in a crash dump.

    PID: 9902   TASK: d47aecd0  CPU: 0   COMMAND: "memcg_process_s"
     #0 [d72d3ad0] crash_kexec at c028cfdb
     #1 [d72d3b24] oops_end at c05c5322
     #2 [d72d3b38] __bad_area_nosemaphore at c0227e60
     #3 [d72d3bec] bad_area at c0227fb6
     #4 [d72d3c00] do_page_fault at c05c72ec
     #5 [d72d3c80] error_code (via page_fault) at c05c47a4
        EAX: 00000000  EBX: 000c0000  ECX: 00000001  EDX: 00000807  EBP: 000c0000
        DS:  007b      ESI: 00000001  ES:  007b      EDI: f3000a80  GS:  6f50
        CS:  0060      EIP: c030b15a  ERR: ffffffff  EFLAGS: 00010002
     #6 [d72d3cb4] isolate_migratepages at c030b15a
     #7 [d72d3d14] zone_watermark_ok at c02d26cb
     #8 [d72d3d2c] compact_zone at c030b8de
     #9 [d72d3d68] compact_zone_order at c030bba1
    #10 [d72d3db4] try_to_compact_pages at c030bc84
    #11 [d72d3ddc] __alloc_pages_direct_compact at c02d61e7
    #12 [d72d3e08] __alloc_pages_slowpath at c02d66c7
    #13 [d72d3e78] __alloc_pages_nodemask at c02d6a97
    #14 [d72d3eb8] alloc_pages_vma at c030a845
    #15 [d72d3ed4] do_huge_pmd_anonymous_page at c03178eb
    #16 [d72d3f00] handle_mm_fault at c02f36c6
    #17 [d72d3f30] do_page_fault at c05c70ed
    #18 [d72d3fb0] error_code (via page_fault) at c05c47a4
        EAX: b71ff000  EBX: 00000001  ECX: 00001600  EDX: 00000431
        DS:  007b      ESI: 08048950  ES:  007b      EDI: bfaa3788
        SS:  007b      ESP: bfaa36e0  EBP: bfaa3828  GS:  6f50
        CS:  0073      EIP: 080487c8  ERR: ffffffff  EFLAGS: 00010202

    It was also reported by Herbert van den Bergh against 3.1-based kernel
    with the following snippet from the console log.

    BUG: unable to handle kernel paging request at 01c00008
    IP: [<c0522399>] isolate_migratepages+0x119/0x390
    *pdpt = 000000002f7ce001 *pde = 0000000000000000

    It is expected that it also affects 3.2.x and current mainline.

    The problem is that pfn_valid is only called on the first PFN being
    checked and that PFN is not necessarily aligned.  Lets say we have a case
    like this

    H = MAX_ORDER_NR_PAGES boundary
    | = pageblock boundary
    m = cc->migrate_pfn
    f = cc->free_pfn
    o = memory hole

    H------|------H------|----m-Hoooooo|ooooooH-f----|------H

    The migrate_pfn is just below a memory hole and the free scanner is beyond
    the hole.  When isolate_migratepages started, it scans from migrate_pfn to
    migrate_pfn+pageblock_nr_pages which is now in a memory hole.  It checks
    pfn_valid() on the first PFN but then scans into the hole where there are
    not necessarily valid struct pages.

    This patch ensures that isolate_migratepages calls pfn_valid when
    necessary.

    Reported-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
    Tested-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Nazarewicz <mina86@mina86.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 c713decb179258db83fd048c09ec55d521d864d4
Author: Carsten Otte <carsteno@de.ibm.com>
Date:   Fri Feb 3 15:37:14 2012 -0800

    mm/filemap_xip.c: fix race condition in xip_file_fault()

    commit 99f02ef1f18631eb0a4e0ea0a3d56878dbcb4b90 upstream.

    Fix a race condition that shows in conjunction with xip_file_fault() when
    two threads of the same user process fault on the same memory page.

    In this case, the race winner will install the page table entry and the
    unlucky loser will cause an oops: xip_file_fault calls vm_insert_pfn (via
    vm_insert_mixed) which drops out at this check:

    	retval = -EBUSY;
    	if (!pte_none(*pte))
    		goto out_unlock;

    The resulting -EBUSY return value will trigger a BUG_ON() in
    xip_file_fault.

    This fix simply considers the fault as fixed in this case, because the
    race winner has successfully installed the pte.

    [akpm@linux-foundation.org: use conventional (and consistent) comment layout]
    Reported-by: David Sadler <dsadler@us.ibm.com>
    Signed-off-by: Carsten Otte <cotte@de.ibm.com>
    Reported-by: Louis Alex Eisner <leisner@cs.ucsd.edu>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73632d80356dcadfcacc8e20a319850b112abb9b
Author: Nikolaus Voss <n.voss@weinmann.de>
Date:   Tue Jan 17 10:28:33 2012 +0100

    at_hdmac: bugfix for enabling channel irq

    commit bda3a47c886664e86ee14eb79e9072b9e341f575 upstream.

    commit 463894705e4089d0ff69e7d877312d496ac70e5b deleted redundant
    chan_id and chancnt initialization in dma drivers as this is done
    in dma_async_device_register().

    However, atc_enable_irq() relied on chan_id set before registering
    the device, what left only channel 0 functional for this driver.

    This patch introduces atc_enable/disable_chan_irq() as a variant
    of atc_enable/disable_irq() with the channel as explicit argument.

    Signed-off-by: Nikolaus Voss <n.voss@weinmann.de>
    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 603b63484725a6e88e4ae5da58716efd88154b1e
Author: Jiang Liu <liuj97@gmail.com>
Date:   Fri Feb 3 15:37:16 2012 -0800

    kprobes: fix a memory leak in function pre_handler_kretprobe()

    commit 55ca6140e9bb307efc97a9301a4f501de02a6fd6 upstream.

    In function pre_handler_kretprobe(), the allocated kretprobe_instance
    object will get leaked if the entry_handler callback returns non-zero.
    This may cause all the preallocated kretprobe_instance objects exhausted.

    This issue can be reproduced by changing
    samples/kprobes/kretprobe_example.c to probe "mutex_unlock".  And the fix
    is straightforward: just put the allocated kretprobe_instance object back
    onto the free_instances list.

    [akpm@linux-foundation.org: use raw_spin_lock/unlock]
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: Jim Keniston <jkenisto@us.ibm.com>
    Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55d9f089521b1355cdd6914d1186ae02ddc0f74f
Author: Jack Morgenstein <jackm@mellanox.com>
Date:   Thu Jan 26 16:41:33 2012 +0200

    IB/mlx4: pass SMP vendor-specific attribute MADs to firmware

    commit a6f7feae6d19e84253918d88b04153af09d3a243 upstream.

    In the current code, vendor-specific MADs (e.g with the FDR-10
    attribute) are silently dropped by the driver, resulting in timeouts
    at the sending side and inability to query/configure the relevant
    feature.  However, the ConnectX firmware is able to handle such MADs.
    For unsupported attributes, the firmware returns a GET_RESPONSE MAD
    containing an error status.

    For example, for a FDR-10 node with LID 11:

        # ibstat mlx4_0 1

        CA: 'mlx4_0'
        Port 1:
        State: Active
        Physical state: LinkUp
        Rate: 40 (FDR10)
        Base lid: 11
        LMC: 0
        SM lid: 24
        Capability mask: 0x02514868
        Port GUID: 0x0002c903002e65d1
        Link layer: InfiniBand

    Extended Port Query (EPI) vendor mad timeouts before the patch:

        # smpquery MEPI 11 -d

        ibwarn: [4196] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
        ibwarn: [4196] _do_madrpc: retry 1 (timeout 1000 ms)
        ibwarn: [4196] _do_madrpc: retry 2 (timeout 1000 ms)
        ibwarn: [4196] _do_madrpc: timeout after 3 retries, 3000 ms
        ibwarn: [4196] mad_rpc: _do_madrpc failed; dport (Lid 11)
        smpquery: iberror: [pid 4196] main: failed: operation EPI: ext port info query failed

    EPI query works OK with the patch:

        # smpquery MEPI 11 -d

        ibwarn: [6548] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
        ibwarn: [6548] mad_rpc: data offs 64 sz 64
        mad data
        0000 0000 0000 0001 0000 0001 0000 0001
        0000 0000 0000 0000 0000 0000 0000 0000
        0000 0000 0000 0000 0000 0000 0000 0000
        0000 0000 0000 0000 0000 0000 0000 0000
        # Ext Port info: Lid 11 port 0
        StateChangeEnable:...............0x00
        LinkSpeedSupported:..............0x01
        LinkSpeedEnabled:................0x01
        LinkSpeedActive:.................0x01

    Signed-off-by: Jack Morgenstein <jackm@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Acked-by: Ira Weiny <weiny2@llnl.gov>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2f8080ae4ebf8d860addf050536b1ec71c53e19
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Sun Jan 29 12:41:15 2012 +0100

    firewire: ohci: disable MSI on Ricoh controllers

    commit 320cfa6ce0b3dc794fedfa4bae54c0f65077234d upstream.

    The PCIe device

        FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller
        [1180:e832] (prog-if 10 [OHCI])

    is unable to access attached FireWire devices when MSI is enabled but
    works if MSI is disabled.
    http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.html

    Hence add the "disable MSI" quirks flag for this device, or in fact for
    safety and simplicity for all current (R5U230, R5U231, R5U240) and
    future Ricoh PCIe 1394 controllers.

    Reported-by: Stefan Thomas <kontrapunktstefan@googlemail.com>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 914dcd6a7120a034c515605ca509cb7e6767f52c
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Thu Jan 26 22:05:58 2012 +0100

    firewire: ohci: add reset packet quirk for SB Audigy

    commit d1bb399ad03c11e792f6dea198d3b1e23061f094 upstream.

    The Audigy's SB1394 controller is actually from Texas Instruments
    and has the same bus reset packet generation bug, so it needs the
    same quirk entry.

    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0053779e04bbfabe31287245d89ad10bb66e758a
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Jan 31 17:15:11 2012 +0100

    proc: make sure mem_open() doesn't pin the target's memory

    commit 6d08f2c7139790c268820a2e590795cb8333181a upstream.

    Once /proc/pid/mem is opened, the memory can't be released until
    mem_release() even if its owner exits.

    Change mem_open() to do atomic_inc(mm_count) + mmput(), this only
    pins mm_struct. Change mem_rw() to do atomic_inc_not_zero(mm_count)
    before access_remote_vm(), this verifies that this mm is still alive.

    I am not sure what should mem_rw() return if atomic_inc_not_zero()
    fails. With this patch it returns zero to match the "mm == NULL" case,
    may be it should return -EINVAL like it did before e268337d.

    Perhaps it makes sense to add the additional fatal_signal_pending()
    check into the main loop, to ensure we do not hold this memory if
    the target task was oom-killed.

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

commit b49767a65a6454f7d546068a785e25dbb0eabbcd
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Jan 31 17:14:54 2012 +0100

    proc: unify mem_read() and mem_write()

    commit 572d34b946bae070debd42db1143034d9687e13f upstream.

    No functional changes, cleanup and preparation.

    mem_read() and mem_write() are very similar. Move this code into the
    new common helper, mem_rw(), which takes the additional "int write"
    argument.

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

commit 401f63716ca0bca1728e55ccf2132fb3785cf5da
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Jan 31 17:14:38 2012 +0100

    proc: mem_release() should check mm != NULL

    commit 71879d3cb3dd8f2dfdefb252775c1b3ea04a3dd4 upstream.

    mem_release() can hit mm == NULL, add the necessary check.

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

commit 344d390bcb4c796b4b7797395cfc07e2c43d935d
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Fri Feb 3 15:37:15 2012 -0800

    drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer

    commit cbcb8346054073d000ecac324763372d6abd44ac upstream.

    KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland
    with a 64bit kernel if the font width is not 8.

    This is because of the setting of the KD_FONT_FLAG_OLD flag, which makes
    con_font_get return EIO in such case.

    This flag should *not* be set for KDFONTOP, since it's actually the whole
    point of this flag (see comment in con_font_set for instance).

    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Arthur Taylor <art@ified.ca>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: Jiri Olsa <jolsa@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 17f272d8e4349543de855ea63e4eea4a67a7abc5
Author: Yegor Yefremov <yegor_sub1@visionsystems.de>
Date:   Mon Jan 23 08:32:23 2012 +0100

    ARM: OMAP2+: GPMC: fix device size setup

    commit 8ef5d844cc3a644ea6f7665932a4307e9fad01fa upstream.

    following statement can only change device size from 8-bit(0) to 16-bit(1),
    but not vice versa:

    regval |= GPMC_CONFIG1_DEVICESIZE(wval);

    so as this field has 1 reserved bit, that could be used in future,
    just clear both bits and then OR with the desired value

    Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e358073331debaab9e14b3139bc469184288aa48
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 30 20:23:29 2012 +0100

    ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers

    commit 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f upstream.

    If we are context switched whilst copying into a thread's
    vfp_hard_struct then the partial copy may be corrupted by the VFP
    context switching code (see "ARM: vfp: flush thread hwstate before
    restoring context from sigframe").

    This patch updates the ptrace VFP set code so that the thread state is
    flushed before the copy, therefore disabling VFP and preventing
    corruption from occurring.

    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 ae3939e12cc597be0ba28d5f3b3d8f158f2d6d70
Author: Dave Martin <dave.martin@linaro.org>
Date:   Mon Jan 30 20:22:28 2012 +0100

    ARM: 7307/1: vfp: fix ptrace regset modification race

    commit 247f4993a5974e6759606c4d380748eecfd273ff upstream.

    In a preemptible kernel, vfp_set() can be preempted, causing the
    hardware VFP context to be switched while the thread vfp state is
    being read and modified.  This leads to a race condition which can
    cause the thread vfp state to become corrupted if lazy VFP context
    save occurs due to preemption in between the time thread->vfpstate
    is read and the time the modified state is written back.

    This may occur if preemption occurs during the execution of a
    ptrace() call which modifies the VFP register state of a thread.
    Such instances should be very rare in most realistic scenarios --
    none has been reported, so far as I am aware.  Only uniprocessor
    systems should be affected, since VFP context save is not currently
    lazy in SMP kernels.

    The problem was introduced by my earlier patch migrating to use
    regsets to implement ptrace.

    This patch does a vfp_sync_hwstate() before reading
    thread->vfpstate, to make sure that the thread's VFP state is not
    live in the hardware registers while the registers are modified.

    Thanks to Will Deacon for spotting this.

    Signed-off-by: Dave Martin <dave.martin@linaro.org>
    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 886d462b0c92357a2f0ca0fc19f5877efbb1f638
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 30 20:21:42 2012 +0100

    ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe

    commit 2af276dfb1722e97b190bd2e646b079a2aa674db upstream.

    Following execution of a signal handler, we currently restore the VFP
    context from the ucontext in the signal frame. This involves copying
    from the user stack into the current thread's vfp_hard_struct and then
    flushing the new data out to the hardware registers.

    This is problematic when using a preemptible kernel because we could be
    context switched whilst updating the vfp_hard_struct. If the current
    thread has made use of VFP since the last context switch, the VFP
    notifier will copy from the hardware registers into the vfp_hard_struct,
    overwriting any data that had been partially copied by the signal code.

    Disabling preemption across copy_from_user calls is a terrible idea, so
    instead we move the VFP thread flush *before* we update the
    vfp_hard_struct. Since the flushing is performed lazily, this has the
    effect of disabling VFP and clearing the CPU's VFP state pointer,
    therefore preventing the thread from being updated with stale data on
    the next context switch.

    Tested-by: Peter Maydell <peter.maydell@linaro.org>
    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 a2eeb4b984210336662a9ebdbecb96efd8823ff2
Author: UK KIM <w0806.kim@samsung.com>
Date:   Sat Jan 28 01:52:22 2012 +0900

    ASoC: wm_hubs: fix wrong bits for LINEOUT2 N/P mixer

    commit 114395c61ad2eb5a7a5cd163fcadb2414e48245a upstream.

    Signed-off-by: UK KIM <w0806.kim@samsung.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cf7d6f29728c367ac742e7e17d89d8d9b6caeba
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Fri Jan 20 12:19:43 2012 +0000

    ASoC: wm_hubs: Enable line out VMID buffer for single ended line outputs

    commit 77231abe55433aa17eca712718745275853fa66d upstream.

    For optimal performance the single ended line outputs require that the
    line output VMID buffer be enabled.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fe10cf8e23ed6e32c09c05303df7e66abdb7e39
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Feb 1 12:05:41 2012 +0100

    ALSA: HDA: Fix duplicated output to more than one codec

    commit 54c2a89f60fd71b924d0f848ac892442951401a6 upstream.

    This typo caused the wrong codec's nid to be checked for wcaps type.
    As a result, sometimes speakers would duplicate the output sent to
    HDMI output.

    BugLink: https://bugs.launchpad.net/bugs/924320
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99067d691614385f824b42f9a02da9708e66dbb6
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Fri Feb 3 15:37:17 2012 -0800

    readahead: fix pipeline break caused by block plug

    commit 3deaa7190a8da38453c4fabd9dec7f66d17fff67 upstream.

    Herbert Poetzl reported a performance regression since 2.6.39.  The test
    is a simple dd read, but with big block size.  The reason is:

    T1: ra (A, A+128k), (A+128k, A+256k)
    T2: lock_page for page A, submit the 256k
    T3: hit page A+128K, ra (A+256k, A+384). the range isn't submitted
    because of plug and there isn't any lock_page till we hit page A+256k
    because all pages from A to A+256k is in memory
    T4: hit page A+256k, ra (A+384, A+ 512). Because of plug, the range isn't
    submitted again.
    T5: lock_page A+256k, so (A+256k, A+512k) will be submitted. The task is
    waitting for (A+256k, A+512k) finish.

    There is no request to disk in T3 and T4, so readahead pipeline breaks.

    We really don't need block plug for generic_file_aio_read() for buffered
    I/O.  The readahead already has plug and has fine grained control when I/O
    should be submitted.  Deleting plug for buffered I/O fixes the regression.

    One side effect is plug makes the request size 256k, the size is 128k
    without it.  This is because default ra size is 128k and not a reason we
    need plug here.

    Vivek said:

    : We submit some readahead IO to device request queue but because of nested
    : plug, queue never gets unplugged.  When read logic reaches a page which is
    : not in page cache, it waits for page to be read from the disk
    : (lock_page_killable()) and that time we flush the plug list.
    :
    : So effectively read ahead logic is kind of broken in parts because of
    : nested plugging.  Removing top level plug (generic_file_aio_read()) for
    : buffered reads, will allow unplugging queue earlier for readahead.

    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Reported-by: Herbert Poetzl <herbert@13thfloor.at>
    Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Vivek Goyal <vgoyal@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>