Linux 3.0.42

commit 5aa287dcf1b5879aa0150b0511833c52885f5b4c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 26 15:12:29 2012 -0700

    Linux 3.0.42

commit 15e892b321f5669a48fbdfa3e9608ef1b185f8d8
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Aug 14 13:18:53 2012 +0000

    IB/srp: Fix a race condition

    commit 220329916c72ee3d54ae7262b215a050f04a18fc upstream.

    Avoid a crash caused by the scmnd->scsi_done(scmnd) call in
    srp_process_rsp() being invoked with scsi_done == NULL.  This can
    happen if a reply is received during or after a command abort.

    Reported-by: Joseph Glanville <joseph.glanville@orionvm.com.au>
    Reference: http://marc.info/?l=linux-rdma&m=134314367801595
    Acked-by: David Dillow <dillowda@ornl.gov>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a933fe49eaf78889e5cfb4faef6dd3f31d4b423
Author: Jeongdo Son <sohn9086@gmail.com>
Date:   Fri Jun 15 02:28:01 2012 +0900

    rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb.

    commit a769f9577232afe2c754606a83aad85127e7052a upstream.

    This is a RT3070 based device.

    Signed-off-by: Jeongdo Son <sohn9086@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edbc37fd3930900161aca75dd3684825179ca091
Author: Mark Ferrell <mferrell@uplogix.com>
Date:   Tue Jul 24 14:15:13 2012 -0500

    usb: serial: mos7840: Fixup mos7840_chars_in_buffer()

    commit 5c263b92f828af6a8cf54041db45ceae5af8f2ab upstream.

     * Use the buffer content length as opposed to the total buffer size.  This can
       be a real problem when using the mos7840 as a usb serial-console as all
       kernel output is truncated during boot.

    Signed-off-by: Mark Ferrell <mferrell@uplogix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0f56add7cd65221d04964de9cc78bddebe2ecae
Author: Ozan Çağlayan <ozancag@gmail.com>
Date:   Fri Aug 10 17:25:10 2012 +0300

    USB: ftdi_sio: Add VID/PID for Kondo Serial USB

    commit 7724a1edbe463b06d4e7831a41149ba095b16c53 upstream.

    This adds VID/PID for Kondo Kagaku Co. Ltd. Serial USB Adapter
    interface:
    http://www.kondo-robot.com/EN/wp/?cat=28

    Tested by controlling an RCB3 board using libRCB3.

    Signed-off-by: Ozan Çağlayan <ozancag@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb82df1a3fd0ab9ddab5134abe3e79917cd90954
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Aug 15 15:43:33 2012 +0200

    USB: option: add ZTE K5006-Z

    commit f1b5c997e68533df1f96dcd3068a231bca495603 upstream.

    The ZTE (Vodafone) K5006-Z use the following
    interface layout:

    00 DIAG
    01 secondary
    02 modem
    03 networkcard
    04 storage

    Ignoring interface #3 which is handled by the qmi_wwan
    driver.

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

commit 0dfcf2c7d9488159970a9753e15ccb8b0d0cecec
Author: fangxiaozhi <huananhu@huawei.com>
Date:   Wed Aug 8 09:24:45 2012 +0000

    USB: support the new interfaces of Huawei Data Card devices in option driver

    commit ee6f827df9107139e8960326e49e1376352ced4d upstream.

    In this patch, we add new declarations into option.c to support the new
    interfaces of Huawei Data Card devices. And at the same time, remove the
    redundant declarations from option.c.

    Signed-off-by: fangxiaozhi <huananhu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1289a4da9f715c71d7fce707b330f1c6dc1b9150
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Tue Jul 10 19:10:06 2012 -0300

    USB: add USB_VENDOR_AND_INTERFACE_INFO() macro

    commit d81a5d1956731c453b85c141458d4ff5d6cc5366 upstream.

    A lot of Broadcom Bluetooth devices provides vendor specific interface
    class and we are getting flooded by patches adding new device support.
    This change will help us enable support for any other Broadcom with vendor
    specific device that arrives in the future.

    Only the product id changes for those devices, so this macro would be
    perfect for us:

    { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }

    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Acked-by: Henrik Rydberg <rydberg@bitmath.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0135372d5c4305a59aee0091847da7ce0cf08ffe
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Jul 23 18:59:30 2012 +0300

    xhci: Switch PPT ports to EHCI on shutdown.

    commit e95829f474f0db3a4d940cae1423783edd966027 upstream.

    The Intel desktop boards DH77EB and DH77DF have a hardware issue that
    can be worked around by BIOS.  If the USB ports are switched to xHCI on
    shutdown, the xHCI host will send a spurious interrupt, which will wake
    the system.  Some BIOS will work around this, but not all.

    The bug can be avoided if the USB ports are switched back to EHCI on
    shutdown.  The Intel Windows driver switches the ports back to EHCI, so
    change the Linux xHCI driver to do the same.

    Unfortunately, we can't tell the two effected boards apart from other
    working motherboards, because the vendors will change the DMI strings
    for the DH77EB and DH77DF boards to their own custom names.  One example
    is Compulab's mini-desktop, the Intense-PC.  Instead, key off the
    Panther Point xHCI host PCI vendor and device ID, and switch the ports
    over for all PPT xHCI hosts.

    The only impact this will have on non-effected boards is to add a couple
    hundred milliseconds delay on boot when the BIOS has to switch the ports
    over from EHCI to xHCI.

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

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Denis Turischev <denis@compulab.co.il>
    Tested-by: Denis Turischev <denis@compulab.co.il>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b474a496850d10267320b7c2ff7c0ca09d2de8c9
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Jul 23 16:06:08 2012 -0700

    xhci: Increase reset timeout for Renesas 720201 host.

    commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b upstream.

    The NEC/Renesas 720201 xHCI host controller does not complete its reset
    within 250 milliseconds.  In fact, it takes about 9 seconds to reset the
    host controller, and 1 second for the host to be ready for doorbell
    rings.  Extend the reset and CNR polling timeout to 10 seconds each.

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

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Edwin Klein Mentink <e.kleinmentink@zonnet.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6216cf6ab8e7494da3fda76f9281a228198ce742
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Jul 2 13:36:23 2012 -0700

    xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.

    commit 5cb7df2b2d3afee7638b3ef23a5bcb89c6f07bd9 upstream.

    Gary reports that with recent kernels, he notices more xHCI driver
    warnings:

    xhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?

    We think his Etron xHCI host controller may have the same buggy behavior
    as the Fresco Logic xHCI host.  When a short transfer is received, the
    host will mark the transfer as successfully completed when it should be
    marking it with a short completion.

    Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron
    host is discovered.  Note that Gary has revision 1, but if Etron fixes
    this bug in future revisions, the quirk will have no effect.

    This patch should be backported to kernels as old as 2.6.36, that
    contain a backported version of commit
    1530bbc6272d9da1e39ef8e06190d42c13a02733 "xhci: Add new short TX quirk
    for Fresco Logic host."

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Gary E. Miller <gem@rellim.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1aa47aec9ca0de65c67d811c291153503972a08
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Aug 5 23:28:16 2012 -0400

    ext4: avoid kmemcheck complaint from reading uninitialized memory

    commit 7e731bc9a12339f344cddf82166b82633d99dd86 upstream.

    Commit 03179fe923 introduced a kmemcheck complaint in
    ext4_da_get_block_prep() because we save and restore
    ei->i_da_metadata_calc_last_lblock even though it is left
    uninitialized in the case where i_da_metadata_calc_len is zero.

    This doesn't hurt anything, but silencing the kmemcheck complaint
    makes it easier for people to find real bugs.

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45631
    (which is marked as a regression).

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5a5aa3a1f996962d9a2a9fe0bb2c096a8b06f37
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Fri Jul 27 16:32:24 2012 -0400

    drm/radeon: do not reenable crtc after moving vram start address

    commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream.

    It seems we can not update the crtc scanout address. After disabling
    crtc, update to base address do not take effect after crtc being
    reenable leading to at least frame being scanout from the old crtc
    base address. Disabling crtc display request lead to same behavior.

    So after changing the vram address if we don't keep crtc disabled
    we will have the GPU trying to read some random system memory address
    with some iommu this will broke the crtc engine and will lead to
    broken display and iommu error message.

    So to avoid this, disable crtc. For flicker less boot we will need
    to avoid moving the vram start address.

    This patch should also fix :

    https://bugs.freedesktop.org/show_bug.cgi?id=42373

    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 413b13d9dd468992591bafb55e849c87fb68341c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Aug 7 09:54:14 2012 +0200

    drm/i915: correctly order the ring init sequence

    commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.

    We may only start to set up the new register values after having
    confirmed that the ring is truely off. Otherwise the hw might lose the
    newly written register values. This is caught later on in the init
    sequence, when we check whether the register writes have stuck.

    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
    Tested-by: Yang Guang <guang.a.yang@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 318095d39c962873a6aa0f31683745cb0420753e
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Wed May 23 18:57:20 2012 +0100

    xen: mark local pages as FOREIGN in the m2p_override

    commit b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f upstream.

    When the frontend and the backend reside on the same domain, even if we
    add pages to the m2p_override, these pages will never be returned by
    mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
    always fail, so the pfn of the frontend will be returned instead
    (resulting in a deadlock because the frontend pages are already locked).

    INFO: task qemu-system-i38:1085 blocked for more than 120 seconds.
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    qemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000
     ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0
     ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0
     ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0
    Call Trace:
     [<ffffffff81101ee0>] ? __lock_page+0x70/0x70
     [<ffffffff81a0fdd9>] schedule+0x29/0x70
     [<ffffffff81a0fe80>] io_schedule+0x60/0x80
     [<ffffffff81101eee>] sleep_on_page+0xe/0x20
     [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0
     [<ffffffff81101ed7>] __lock_page+0x67/0x70
     [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40
     [<ffffffff811867e6>] ? bio_add_page+0x36/0x40
     [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60
     [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70
     [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0
     [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
     [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60
     [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
     [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390
     [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
     [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0
     [<ffffffff81104027>] generic_file_aio_read+0x737/0x780
     [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0
     [<ffffffff811038f0>] ? find_get_pages+0x150/0x150
     [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0
     [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90
     [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0
     [<ffffffff811998b8>] do_io_submit+0x708/0xb90
     [<ffffffff81199d50>] sys_io_submit+0x10/0x20
     [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b

    The explanation is in the comment within the code:

    We need to do this because the pages shared by the frontend
    (xen-blkfront) can be already locked (lock_page, called by
    do_read_cache_page); when the userspace backend tries to use them
    with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
    do_blockdev_direct_IO is going to try to lock the same pages
    again resulting in a deadlock.

    A simplified call graph looks like this:

    pygrub                          QEMU
    -----------------------------------------------
    do_read_cache_page              io_submit
      |                              |
    lock_page                       ext3_direct_IO
                                     |
                                    bio_add_page
                                     |
                                    lock_page

    Internally the xen-blkback uses m2p_add_override to swizzle (temporarily)
    a 'struct page' to have a different MFN (so that it can point to another
    guest). It also can easily find out whether another pfn corresponding
    to the mfn exists in the m2p, and can set the FOREIGN bit
    in the p2m, making sure that mfn_to_pfn returns the pfn of the backend.

    This allows the backend to perform direct_IO on these pages, but as a
    side effect prevents the frontend from using get_user_pages_fast on
    them while they are being shared with the backend.

    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd697182ee0264c6a6c9ac108d5d765e24b82724
Author: Zach Brown <zab@redhat.com>
Date:   Tue Jul 24 12:10:11 2012 -0700

    fuse: verify all ioctl retry iov elements

    commit fb6ccff667712c46b4501b920ea73a326e49626a upstream.

    Commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that
    the total iovec from the client doesn't overflow iov_length() but it
    only checked the first element.  The iovec could still overflow by
    starting with a small element.  The obvious fix is to check all the
    elements.

    The overflow case doesn't look dangerous to the kernel as the copy is
    limited by the length after the overflow.  This fix restores the
    intention of returning an error instead of successfully copying less
    than the iovec represented.

    I found this by code inspection.  I built it but don't have a test case.
    I'm cc:ing stable because the initial commit did as well.

    Signed-off-by: Zach Brown <zab@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44d3398477f343c8d63f7219ef0594fa06644e0a
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed Aug 8 09:32:20 2012 +0200

    s390/compat: fix mmap compat system calls

    commit e85871218513c54f7dfdb6009043cb638f2fecbe upstream.

    The native 31 bit and the compat behaviour for the mmap system calls differ:

    In native 31 bit mode the passed in address for the mmap system call will be
    unmodified passed to sys_mmap_pgoff().
    In compat mode however the passed in address will be modified with
    compat_ptr() which masks out the most significant bit.

    The result is that in native 31 bit mode each mmap request (with MAP_FIXED)
    will fail where the most significat bit is set, while in compat mode it
    may succeed.

    This odd behaviour was introduced with d3815898 "[S390] mmap: add missing
    compat_ptr conversion to both mmap compat syscalls".

    To restore a consistent behaviour accross native and compat mode this
    patch functionally reverts the above mentioned commit.

    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>