commit b8ed9e5b8c34dc9fb1882669e45b21e3d0194881
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Thu Jan 12 11:42:45 2012 -0800

    Linux 3.2.1

commit da777f649cf96859d61cf285957b30b694c0fbcb
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 f9fd8d6232137e255fc9409a81cf282817472b6f
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 f60d8cd0b0e0def00c9ac54bb4becae034138484
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 4a75c219087a4079e668c3e5836d64009446c0d3
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 25c413ad0029ea86008234be28aee33456e53e5b
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 d2570fc048ca1307e64572c825e0d7908bd60a21
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 5b511b783385bc68663e4729be7f169ce3061e6d
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 4781ace0ddff8057f2c1bf1811ae4886f8b88876
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 d2758dc6e9a3a0243e120df6132406f409ffd2bf
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 3ff8999cb9dabcac0cbb8a778f79fb991f2358c8
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 b4868343c4dde5315ffebc08de71ddffdd1460d8
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 945d49b38f4e3aa8a570b2fe51f179e7c2181b4d
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 dd857f5b4dc1d8d010da1711b71be789054fbcbe
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 966c248e661ce7d265caeb73c7d0aa68fbf8801a
Author: Tanmay Upadhyay <tanmay.upadhyay@einfochips.com>
Date:   Thu Dec 8 10:03:49 2011 +0530

    USB: pxa168: Fix compilation error
    
    commit 35657c4d72925936c7219cc5caac118ca632acc2 upstream.
    
    After commit c430131a02d677aa708f56342c1565edfdacb3c0 (Support
    controllers with big endian capability regs), HC_LENGTH takes
    two arguments. This patch fixes following compilation error:
    
    In file included from drivers/usb/host/ehci-hcd.c:1323:
    drivers/usb/host/ehci-pxa168.c:302:54: error: macro "HC_LENGTH" requires 2 arguments, but only 1 given
    In file included from drivers/usb/host/ehci-hcd.c:1323:
    drivers/usb/host/ehci-pxa168.c: In function 'ehci_pxa168_drv_probe':
    drivers/usb/host/ehci-pxa168.c:302: error: 'HC_LENGTH' undeclared (first use in this function)
    drivers/usb/host/ehci-pxa168.c:302: error: (Each undeclared identifier is reported only once
    drivers/usb/host/ehci-pxa168.c:302: error: for each function it appears in.)
    
    Signed-off-by: Tanmay Upadhyay <tanmay.upadhyay@einfochips.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit ab8887268c60a5dac0dc388c773a679470292c55
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 d6b3d54200b7b29473041fe8c2e2f5382f2f0c80
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 30234e2694cbc1d6985cafc87db5cd4848493196
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 9e9f6a20b59570ca9374b5e79cf1e7df32c67944
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 62cf6918d66acca738688658e33f9686ab174d94
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 b71bb82900b7491f47a0360f14d23dc30646433d
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 7f35a6941c20af66dde1148b491e2f501192179b
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Dec 16 11:26:30 2011 -0800

    usbfs: Fix oops related to user namespace conversion.
    
    commit 1b41c8321e495337e877ca02d0b9680bc4112eff upstream.
    
    When running the Point Grey "flycap" program for their USB 3.0 camera
    (which was running as a USB 2.0 device for some reason), I trigger this
    oops whenever I try to open a video stream:
    
    Dec 15 16:48:34 puck kernel: [ 1798.715559] BUG: unable to handle kernel NULL pointer dereference at           (null)
    Dec 15 16:48:34 puck kernel: [ 1798.719153] IP: [<ffffffff8147841e>] free_async+0x1e/0x70
    Dec 15 16:48:34 puck kernel: [ 1798.720991] PGD 6f833067 PUD 6fc56067 PMD 0
    Dec 15 16:48:34 puck kernel: [ 1798.722815] Oops: 0002 [#1] SMP
    Dec 15 16:48:34 puck kernel: [ 1798.724627] CPU 0
    Dec 15 16:48:34 puck kernel: [ 1798.724636] Modules linked in: ecryptfs encrypted_keys sha1_generic trusted binfmt_misc sha256_generic aesni_intel cryptd aes_x86_64 aes_generic parport_pc dm_crypt ppdev joydev snd_hda_codec_hdmi snd_hda_codec_conexant arc4 iwlwifi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer btusb uvcvideo snd_seq_device bluetooth videodev psmouse snd v4l2_compat_ioctl32 serio_raw tpm_tis cfg80211 tpm tpm_bios nvram soundcore snd_page_alloc lp parport i915 xhci_hcd ahci libahci drm_kms_helper drm sdhci_pci sdhci e1000e i2c_algo_bit video
    Dec 15 16:48:34 puck kernel: [ 1798.734212]
    Dec 15 16:48:34 puck kernel: [ 1798.736162] Pid: 2713, comm: FlyCap2 Not tainted 3.2.0-rc5+ #28 LENOVO 4286CTO/4286CTO
    Dec 15 16:48:34 puck kernel: [ 1798.738148] RIP: 0010:[<ffffffff8147841e>]  [<ffffffff8147841e>] free_async+0x1e/0x70
    Dec 15 16:48:34 puck kernel: [ 1798.740134] RSP: 0018:ffff88005715fd78  EFLAGS: 00010296
    Dec 15 16:48:34 puck kernel: [ 1798.742118] RAX: 00000000fffffff4 RBX: ffff88006fe8f900 RCX: 0000000000004118
    Dec 15 16:48:34 puck kernel: [ 1798.744116] RDX: 0000000001000000 RSI: 0000000000016390 RDI: 0000000000000000
    Dec 15 16:48:34 puck kernel: [ 1798.746087] RBP: ffff88005715fd88 R08: 0000000000000000 R09: ffffffff8146f22e
    Dec 15 16:48:34 puck kernel: [ 1798.748018] R10: ffff88006e520ac0 R11: 0000000000000001 R12: ffff88005715fe28
    Dec 15 16:48:34 puck kernel: [ 1798.749916] R13: ffff88005d31df00 R14: ffff88006fe8f900 R15: 00007f688c995cb8
    Dec 15 16:48:34 puck kernel: [ 1798.751785] FS:  00007f68a366da40(0000) GS:ffff880100200000(0000) knlGS:0000000000000000
    Dec 15 16:48:34 puck kernel: [ 1798.753659] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Dec 15 16:48:34 puck kernel: [ 1798.755509] CR2: 0000000000000000 CR3: 00000000706bb000 CR4: 00000000000406f0
    Dec 15 16:48:34 puck kernel: [ 1798.757334] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    Dec 15 16:48:34 puck kernel: [ 1798.759124] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Dec 15 16:48:34 puck kernel: [ 1798.760871] Process FlyCap2 (pid: 2713, threadinfo ffff88005715e000, task ffff88006c675b80)
    Dec 15 16:48:34 puck kernel: [ 1798.762605] Stack:
    Dec 15 16:48:34 puck kernel: [ 1798.764297]  ffff88005715fe28 0000000000000000 ffff88005715fe08 ffffffff81479058
    Dec 15 16:48:34 puck kernel: [ 1798.766020]  0000000000000000 ffffea0000004000 ffff880000004118 0000000000000000
    Dec 15 16:48:34 puck kernel: [ 1798.767750]  ffff880000000001 ffff88006e520ac0 fffffff46fd81180 0000000000000000
    Dec 15 16:48:34 puck kernel: [ 1798.769472] Call Trace:
    Dec 15 16:48:34 puck kernel: [ 1798.771147]  [<ffffffff81479058>] proc_do_submiturb+0x778/0xa00
    Dec 15 16:48:34 puck kernel: [ 1798.772798]  [<ffffffff8147a5fd>] usbdev_do_ioctl+0x24d/0x1200
    Dec 15 16:48:34 puck kernel: [ 1798.774410]  [<ffffffff8147b5de>] usbdev_ioctl+0xe/0x20
    Dec 15 16:48:34 puck kernel: [ 1798.775975]  [<ffffffff81189259>] do_vfs_ioctl+0x99/0x600
    Dec 15 16:48:34 puck kernel: [ 1798.777534]  [<ffffffff81189851>] sys_ioctl+0x91/0xa0
    Dec 15 16:48:34 puck kernel: [ 1798.779088]  [<ffffffff816247c2>] system_call_fastpath+0x16/0x1b
    ec 15 16:48:34 puck kernel: [ 1798.780634] Code: 51 ff ff ff e9 29 ff ff ff 0f 1f 40 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 89 fb 48 8b 7f 18 e8 a6 ea c0 ff 4
    8 8b 7b 20 <f0> ff 0f 0f 94 c0 84 c0 74 05 e8 d3 99 c1 ff 48 8b 43 40 48 8b
    Dec 15 16:48:34 puck kernel: [ 1798.783970] RIP  [<ffffffff8147841e>] free_async+0x1e/0x70
    Dec 15 16:48:34 puck kernel: [ 1798.785630]  RSP <ffff88005715fd78>
    Dec 15 16:48:34 puck kernel: [ 1798.787274] CR2: 0000000000000000
    Dec 15 16:48:34 puck kernel: [ 1798.794728] ---[ end trace 52894d3355f88d19 ]---
    
    markup_oops.pl says the oops is in put_cred:
    
     ffffffff81478401:      48 89 e5                mov    %rsp,%rbp
     ffffffff81478404:      53                      push   %rbx
     ffffffff81478405:      48 83 ec 08             sub    $0x8,%rsp
     ffffffff81478409:      e8 f2 c0 1a 00          callq  ffffffff81624500 <mcount>
     ffffffff8147840e:      48 89 fb                mov    %rdi,%rbx   |  %ebx => ffff88006fe8f900
            put_pid(as->pid);
     ffffffff81478411:      48 8b 7f 18             mov    0x18(%rdi),%rdi
     ffffffff81478415:      e8 a6 ea c0 ff          callq  ffffffff81086ec0 <put_pid>
            put_cred(as->cred);
     ffffffff8147841a:      48 8b 7b 20             mov    0x20(%rbx),%rdi |  %edi => 0  %ebx = ffff88006fe8f900
      */
     static inline int atomic_dec_and_test(atomic_t *v)
     {
            unsigned char c;
    
            asm volatile(LOCK_PREFIX "decl %0; sete %1"
    *ffffffff8147841e:      f0 ff 0f                lock decl (%rdi)   |  %edi = 0 <--- faulting instruction
     ffffffff81478421:      0f 94 c0                sete   %al
     static inline void put_cred(const struct cred *_cred)
     {
            struct cred *cred = (struct cred *) _cred;
    
            validate_creds(cred);
            if (atomic_dec_and_test(&(cred)->usage))
     ffffffff81478424:      84 c0                   test   %al,%al
     ffffffff81478426:      74 05                   je     ffffffff8147842d <free_async+0x2d>
                    __put_cred(cred);
     ffffffff81478428:      e8 d3 99 c1 ff          callq  ffffffff81091e00 <__put_cred>
            kfree(as->urb->transfer_buffer);
     ffffffff8147842d:      48 8b 43 40             mov    0x40(%rbx),%rax
     ffffffff81478431:      48 8b 78 68             mov    0x68(%rax),%rdi
     ffffffff81478435:      e8 a6 e1 ce ff          callq  ffffffff811665e0 <kfree>
            kfree(as->urb->setup_packet);
     ffffffff8147843a:      48 8b 43 40             mov    0x40(%rbx),%rax
     ffffffff8147843e:      48 8b b8 90 00 00 00    mov    0x90(%rax),%rdi
     ffffffff81478445:      e8 96 e1 ce ff          callq  ffffffff811665e0 <kfree>
            usb_free_urb(as->urb);
     ffffffff8147844a:      48 8b 7b 40             mov    0x40(%rbx),%rdi
     ffffffff8147844e:      e8 0d 6b ff ff          callq  ffffffff8146ef60 <usb_free_urb>
    
    This bug seems to have been introduced by commit
    d178bc3a708f39cbfefc3fab37032d3f2511b4ec "user namespace: usb: make usb
    urbs user namespace aware (v2)"
    
    I'm not sure if this is right fix, but it does stop the oops.
    
    Unfortunately, the Point Grey software still refuses to work, but it's a
    closed source app, so I can't fix it.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 170b209abef52783adcc3855c6afb51333e8ae89
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 d1883e7052eeffca3f42922bb31fa44d0992c6a6
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Tue Dec 27 13:49:37 2011 -0800

    Drivers:hv: Fix a bug in vmbus_driver_unregister()
    
    commit 8f257a142fc3868d69de3f996b95d7bdbc509560 upstream.
    
    The function vmbus_exists() was introduced recently to deal with cases where
    the vmbus driver failed to initialize and yet other Hyper-V drivers attempted
    to register with the vmbus bus driver. This patch introduced a bug where
    vmbus_driver_unregister() would fail to unregister the driver. This patch
    fixes the problem.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Fuzhou Chen <fuzhouch@microsoft.com>
    Cc: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 32eef9ed02e483cb39d0d70316ba35a5d4920b6b
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Thu Dec 1 09:59:34 2011 -0800

    drivers: hv: Don't OOPS when you cannot init vmbus
    
    commit cf6a2eacbcb2593b5b91d0817915c4f0464bb534 upstream.
    
    The hv vmbus driver was causing an OOPS since it was trying to register drivers
    on top of the bus even if initialization of the bus has failed for some
    reason (such as the odd chance someone would run a hv enabled kernel in a
    non-hv environment).
    
    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0558681f027b24a134e24fee2d96a0a1c6174c76
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 04e06ee56d4667deb90a3bb2952cfcffb051ff65
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 e75c11aceb7c8717241719e531c9adece8111987
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 88e02818005ddaf5d584f58586c38f18168cecf3
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Tue Nov 29 15:35:53 2011 -0800

    ore: FIX breakage when MISC_FILESYSTEMS is not set
    
    commit 831c2dc5f47c1dc79c32229d75065ada1dcc66e1 upstream.
    
    As Reported by Randy Dunlap
    
    When MISC_FILESYSTEMS is not enabled and NFS4.1 is:
    
    fs/built-in.o: In function `objio_alloc_io_state':
    objio_osd.c:(.text+0xcb525): undefined reference to `ore_get_rw_state'
    fs/built-in.o: In function `_write_done':
    objio_osd.c:(.text+0xcb58d): undefined reference to `ore_check_io'
    fs/built-in.o: In function `_read_done':
    ...
    
    When MISC_FILESYSTEMS, which is more of a GUI thing then anything else,
    is not selected. exofs/Kconfig is never examined during Kconfig,
    and it can not do it's magic stuff to automatically select everything
    needed.
    
    We must split exofs/Kconfig in two. The ore one is always included.
    And the exofs one is left in it's old place in the menu.
    
    Reported-by: Randy Dunlap <rdunlap@xenotime.net>
    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 673a3083dc48d45a798ee509995899e11625aa9d
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Wed Dec 28 19:21:45 2011 +0200

    ore: Must support none-PAGE-aligned IO
    
    commit 724577ca355795b0a25c93ccbeee927871ca1a77 upstream.
    
    NFS might send us offsets that are not PAGE aligned. So
    we must read in the reminder of the first/last pages, in cases
    we need it for Parity calculations.
    
    We only add an sg segments to read the partial page. But
    we don't mark it as read=true because it is a lock-for-write
    page.
    
    TODO: In some cases (IO spans a single unit) we can just
    adjust the raid_unit offset/length, but this is left for
    later Kernels.
    
    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0889c179651f57c6fdf4ed72e5027c5dcc90bda2
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Wed Dec 28 19:14:23 2011 +0200

    ore: fix BUG_ON, too few sgs when reading
    
    commit 361aba569f55dd159b850489a3538253afbb3973 upstream.
    
    When reading RAID5 files, in rare cases, we calculated too
    few sg segments. There should be two extra for the beginning
    and end partial units.
    
    Also "too few sg segments" should not be a BUG_ON there is
    all the mechanics in place to handle it, as a short read.
    So just return -ENOMEM and the rest of the code will gracefully
    split the IO.
    
    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 688485273b3173d2fdb590ff916b55c581da6ed0
Author: Boaz Harrosh <bharrosh@panasas.com>
Date:   Tue Dec 27 19:23:36 2011 +0200

    ore: Fix crash in case of an IO error.
    
    commit ffefb8eaa367e8a5c14f779233d9da1fbc23d164 upstream.
    
    The users of ore_check_io() expect the reported device
    (In case of error) to be indexed relative to the passed-in
    ore_components table, and not the logical dev index.
    
    This causes a crash inside objlayoutdriver in case of
    an IO error.
    
    Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 923415295307845e614589c1cce62abedd4d1731
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 0b58bf9909d4ef70275921fc1535f21390cf5bb5
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Dec 19 14:00:59 2011 -0800

    iwlagn: fix (remove) use of PAGE_SIZE
    
    commit 106671369e6d046c0b3e1e72b18ad6dd9cb298b0 upstream.
    
    The ICT code erroneously uses PAGE_SIZE. The bug
    is that PAGE_SIZE isn't necessarily 4096, so on
    such platforms this code will not work correctly
    as we'll try to attempt to read an index in the
    table that the device never wrote, it always has
    4096-byte pages.
    
    Additionally, the manual alignment code here is
    unnecessary -- Documentation/DMA-API-HOWTO.txt
    states:
      The cpu return address and the DMA bus master address are both
      guaranteed to be aligned to the smallest PAGE_SIZE order which
      is greater than or equal to the requested size.  This invariant
      exists (for example) to guarantee that if you allocate a chunk
      which is smaller than or equal to 64 kilobytes, the extent of the
      buffer you receive will not cross a 64K boundary.
    
    Just use appropriate new constants and get rid of
    the alignment code.
    
    Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    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 01b366aa69f33489d59d7a79702987752070fb3a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Dec 2 12:22:54 2011 -0800

    iwlagn: fix TID use bug
    
    commit 9a215e40d70ae63762963ab3ccc7f31dd966dc6a upstream.
    
    The driver everywhere uses max TID count as 9,
    which is wrong, it should be 8.
    
    I think the reason it uses 9 here is off-by-one
    confusion by whoever wrote this. We do use the
    value IWL_MAX_TID_COUNT for "not QoS/no TID"
    but that is completely correct even if it is 8
    and not 9 since 0-7 are only valid.
    
    As a side effect, this fixes the following bug:
    
     Open BA session requested for 00:23:cd:16:8a:7e tid 8
     ------------[ cut here ]------------
     kernel BUG at drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h:350!
     ...
    
    when you do
    echo "tx start 8" > /sys/kernel/debug/ieee80211/*/*/*/*/agg_status
    
    Reported-by: Nikolay Martynov <mar.kolya@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 585ea9bc6752c41d669ea0f4cee8f3954df326e0
Author: Eli Cohen <eli@dev.mellanox.co.il>
Date:   Tue Jan 3 20:36:48 2012 -0800

    IB/uverbs: Protect QP multicast list
    
    commit e214a0fe2b382fa302c036ecd6e6ffe99e3b9875 upstream.
    
    Userspace verbs multicast attach/detach operations on a QP are done
    while holding the rwsem of the QP for reading.  That's not sufficient
    since a reader lock allows more than one reader to acquire the
    lock.  However, multicast attach/detach does list manipulation that
    can corrupt the list if multiple threads run in parallel.
    
    Fix this by acquiring the rwsem as a writer to serialize attach/detach
    operations.  Add idr_write_qp() and put_qp_write() to encapsulate
    this.
    
    This fixes oops seen when running applications that perform multicast
    joins/leaves.
    
    Reported by: Mike Dubman <miked@mellanox.com>
    Signed-off-by: Eli Cohen <eli@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 0d878668d0a4663a4807d413532f3a99496eebf4
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 ddcf85d72ffe4fd46239a94253fe04c114d4d1e2
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 8e04782a06882913304916bc60960e4fc7405e18
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 f92fed3f1de1942a61978c5e59bbed56eab4ac55
Author: Pontus Fuchs <pontus.fuchs@gmail.com>
Date:   Thu Dec 1 12:13:44 2011 +0100

    wl12xx: Restore testmode ABI
    
    commit 3f1764945eaac532c20ab1f23afa352a40f797b2 upstream.
    
    Commit 80900d0140a7648587982c8f299830e900e49165 accidently broke
    the ABI for testmode commands. Restore the ABI again.
    
    Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
    Signed-off-by: Luciano Coelho <coelho@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 67d3bda61b6cf7b8c3166091ab44a07fbd9e091a
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 240ecc4a6fa0449738920ea0658ed4508398091a
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 618bbbe723e697e71b4533d3d8af554fbe5f3e16
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Fri Dec 9 22:16:07 2011 +0100

    bcma: support for suspend and resume
    
    commit 775ab52142b02237a54184238e922251c59a2b5c upstream.
    
    bcma used to lock up machine without enabling PCI or initializing CC.
    
    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit dd4f146b63d18b2cc5b7f20c56ba270f6a45fd01
Author: Andres Salomon <dilinger@queued.net>
Date:   Mon Dec 19 12:22:58 2011 -0800

    libertas: clean up scan thread handling
    
    commit afbca95f95f2bf7283a72670c24c1f6de00b1cb5 upstream.
    
    The libertas scan thread expects priv->scan_req to be non-NULL.  In theory,
    it should always be set.  In practice, we've seen the following oops:
    
    [ 8363.067444] Unable to handle kernel NULL pointer dereference at virtual address 00000004
    [ 8363.067490] pgd = c0004000
    [ 8363.078393] [00000004] *pgd=00000000
    [ 8363.086711] Internal error: Oops: 17 [#1] PREEMPT
    [ 8363.091375] Modules linked in: fuse libertas_sdio libertas psmouse mousedev ov7670 mmp_camera joydev videobuf2_core videobuf2_dma_sg videobuf2_memops [last unloaded: scsi_wait_scan]
    [ 8363.107490] CPU: 0    Not tainted  (3.0.0-gf7ccc69 #671)
    [ 8363.112799] PC is at lbs_scan_worker+0x108/0x5a4 [libertas]
    [ 8363.118326] LR is at 0x0
    [ 8363.120836] pc : [<bf03a854>]    lr : [<00000000>]    psr: 60000113
    [ 8363.120845] sp : ee66bf48  ip : 00000000  fp : 00000000
    [ 8363.120845] r10: ee2c2088  r9 : c04e2efc  r8 : eef97005
    [ 8363.132231] r7 : eee0716f  r6 : ee2c02c0  r5 : ee2c2088  r4 : eee07160
    [ 8363.137419] r3 : 00000000  r2 : a0000113  r1 : 00000001  r0 : eee07160
    [ 8363.143896] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    [ 8363.157630] Control: 10c5387d  Table: 2e754019  DAC: 00000015
    [ 8363.163334] Process kworker/u:1 (pid: 25, stack limit = 0xee66a2f8)
    
    While I've not found a smoking gun, there are two places that raised red flags
    for me.  The first is in _internal_start_scan, when we queue up a scan; we
    first queue the worker, and then set priv->scan_req.  There's theoretically
    a 50mS delay which should be plenty, but doing things that way just seems
    racy (and not in the good way).
    
    The second is in the scan worker thread itself.  Depending on the state of
    priv->scan_channel, we cancel pending scan runs and then requeue a run in
    300mS.  We then send the scan command down to the hardware, sleep, and if
    we get scan results for all the desired channels, we set priv->scan_req to
    NULL.  However, it that's happened in less than 300mS, what happens with
    the pending scan run?
    
    This patch addresses both of those concerns.  With the patch applied, we
    have not seen the oops in the past two weeks.
    
    Signed-off-by: Andres Salomon <dilinger@queued.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

commit 69236e6011d14450a3ed033327d1e6e225b35027
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 dfedad611959d25331b77459bc9a96fb7765127f
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 2289fb57dc2caea22e167bba67b0b52997bce28f
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 a5a0cdd640258b80e116de11517dd6482ab6f229
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 170797705f7ccb335e9fe3f61967a4d465846642
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 13e864be180093e145da19980e247b991d2fd99d
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>