commit 6102ace32239ad2174ffbb7d60be8dafee7341a1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jun 1 15:13:34 2012 +0800

    Linux 3.0.33

commit d19adfe6caf97ceb57ca460992fedd7a6e75a915
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Thu May 3 15:56:36 2012 +0200

    i2c: davinci: Free requested IRQ in remove
    
    commit 9868a060ccf769c08ec378a9829137e272e9a92c upstream.
    
    The freed IRQ is not necessary the one requested in probe.
    Even if it was, with two or more i2c-controllers it will fails anyway.
    
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab55458eb0cc7f0f23e38ed41828e9b5a5372134
Author: Dima Zavin <dima@android.com>
Date:   Mon Apr 30 10:26:14 2012 +0100

    ARM: 7409/1: Do not call flush_cache_user_range with mmap_sem held
    
    commit 435a7ef52db7d86e67a009b36cac1457f8972391 upstream.
    
    We can't be holding the mmap_sem while calling flush_cache_user_range
    because the flush can fault. If we fault on a user address, the
    page fault handler will try to take mmap_sem again. Since both places
    acquire the read lock, most of the time it succeeds. However, if another
    thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in
    between the call to flush_cache_user_range and the fault, the down_read
    in do_page_fault will deadlock.
    
    [will: removed drop of vma parameter as already queued by rmk (7365/1)]
    
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Dima Zavin <dima@android.com>
    Signed-off-by: John Stultz <john.stultz@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 866cd76c93e668389a8edb4eece7b900ac386b5e
Author: Dima Zavin <dima@android.com>
Date:   Thu Mar 29 20:44:06 2012 +0100

    ARM: 7365/1: drop unused parameter from flush_cache_user_range
    
    commit 4542b6a0fa6b48d9ae6b41c1efeb618b7a221b2a upstream.
    
    vma isn't used and flush_cache_user_range isn't a standard macro that
    is used on several archs with the same prototype. In fact only unicore32
    has a macro with the same name (with an identical implementation and no
    in-tree users).
    
    This is a part of a patch proposed by Dima Zavin (with Message-id:
    1272439931-12795-1-git-send-email-dima@android.com) that didn't get
    accepted.
    
    Cc: Dima Zavin <dima@android.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 923744e41efb5c8bddf6e466835adb0c2d2e63e9
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Apr 30 11:57:44 2012 -0700

    isci: fix oem parameter validation on single controller skus
    
    commit fc25f79af321c01a739150ba2c09435cf977a63d upstream.
    
    OEM parameters [1] are parsed from the platform option-rom / efi
    driver.  By default the driver was validating the parameters for the
    dual-controller case, but in single-controller case only the first set
    of parameters may be valid.
    
    Limit the validation to the number of actual controllers detected
    otherwise the driver may fail to parse the valid parameters leading to
    driver-load or runtime failures.
    
    [1] the platform specific set of phy address, configuration,and analog
        tuning values
    
    Reported-by: Dave Jiang <dave.jiang@intel.com>
    Tested-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6115b7a54b2a3f0b6fc783715f606d3760962dc9
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Fri May 25 12:32:09 2012 -0400

    tile: fix bug where fls(0) was not returning 0
    
    commit 9f1d62bed7f015d11b9164078b7fea433b474114 upstream.
    
    This is because __builtin_clz(0) returns 64 for the "undefined" case
    of 0, since the builtin just does a right-shift 32 and "clz" instruction.
    So, use the alpha approach of casting to u32 and using __builtin_clzll().
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d7755e450865b76b98e3fea2e166b0a2266972d
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Mon Apr 16 19:16:54 2012 -0400

    mmc: sdio: avoid spurious calls to interrupt handlers
    
    commit bbbc4c4d8c5face097d695f9bf3a39647ba6b7e7 upstream.
    
    Commit 06e8935feb ("optimized SDIO IRQ handling for single irq")
    introduced some spurious calls to SDIO function interrupt handlers,
    such as when the SDIO IRQ thread is started, or the safety check
    performed upon a system resume.  Let's add a flag to perform the
    optimization only when a real interrupt is signaled by the host
    driver and we know there is no point confirming it.
    
    Reported-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c4f53ca32463a742583976f40444ce4485f3cf9
Author: Tony Luck <tony.luck@intel.com>
Date:   Wed May 23 14:14:22 2012 -0700

    x86/mce: Fix check for processor context when machine check was taken.
    
    commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream.
    
    Linus pointed out that there was no value is checking whether m->ip
    was zero - because zero is a legimate value.  If we have a reliable
    (or faked in the VM86 case) "m->cs" we can use it to tell whether we
    were in user mode or kernelwhen the machine check hit.
    
    Reported-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c179c9851c1b009faf3ec15b2af5042431a5a2ca
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Wed Mar 21 09:50:36 2012 -0300

    media: uvcvideo: Fix ENUMINPUT handling
    
    commit 31c5f0c5e25ed71eeced170f113bb590f2f1f6f3 upstream.
    
    Properly validate the user-supplied index against the number of inputs.
    The code used the pin local variable instead of the index by mistake.
    
    Reported-by: Jozef Vesely <vesely@gjh.sk>
    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@linuxfoundation.org>

commit 0ee936021bbea1a9d060cad85eb4796f261489c6
Author: Michael Krufky <mkrufky@linuxtv.org>
Date:   Thu Mar 22 13:55:05 2012 -0300

    smsusb: add autodetection support for USB ID 2040:c0a0
    
    commit 4d1b58b84472d1d300a66e1c5fd765b21e74ba15 upstream.
    
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 129b34bc3dd345b071ec9eba88ced71f6cd8d340
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 18 15:31:12 2012 +0100

    nouveau: nouveau_set_bo_placement takes TTM flags
    
    commit c284815debba2f14ee2fd07b1b4cc972ab116110 upstream.
    
    This seems to be wrong to me, spotted while thinking about dma-buf.
    
    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 808cf72ca9988a146dff8a8f658dcbad3cd31d5d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 13 22:29:25 2012 +0200

    drm/i915: don't clobber the pipe param in sanitize_modesetting
    
    commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream.
    
    ... we need it later on in the function to clean up pipe <-> plane
    associations. This regression has been introduced in
    
    commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Thu Mar 22 15:00:50 2012 +0000
    
        drm/i915: Sanitize BIOS debugging bits from PIPECONF
    
    Spotted by staring at debug output of an (as it turns out) totally
    unrelated bug.
    
    v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
    Chris Wilson.
    
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa8878bc13c76b9d8b52e55210e2c940987a5fb8
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Apr 14 18:41:32 2012 -0700

    drm/i915: [GEN7] Use HW scheduler for fixed function shaders
    
    commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream.
    
    This originally started as a patch from Bernard as a way of simply
    setting the VS scheduler. After submitting the RFC patch, we decided to
    also modify the DS scheduler. To be most explicit, I've made the patch
    explicitly set all scheduler modes, and included the defines for other
    modes (in case someone feels frisky later).
    
    The rest of the story gets a bit weird. The first version of the patch
    showed an almost unbelievable performance improvement. Since rebasing my
    branch it appears the performance improvement has gone, unfortunately.
    But setting these bits seem to be the right thing to do given that the
    docs describe corruption that can occur with the default settings.
    
    In summary, I am seeing no more perf improvements (or regressions) in my
    limited testing, but we believe this should be set to prevent rendering
    corruption, therefore cc stable.
    
    v1: Clear bit 4 also (Ken + Eugeni)
    Do a full clear + set of the bits we want (Me).
    
    Cc: Bernard Kilarski <bernard.r.kilarski@intel.com>
    Reviewed-by (RFC): Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98cfca8e0d48cd792d830198a34617668b10ed2c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 9 21:45:43 2012 +0100

    drm/i915: Avoid a double-read of PCH_IIR during interrupt handling
    
    commit 9adab8b5a7fde248504f484e197589f3e3c922e2 upstream.
    
    Currently the code re-reads PCH_IIR during the hotplug interrupt
    processing. Not only is this a wasted read, but introduces a potential
    for handling a spurious interrupt as we then may not clear all the
    interrupts processed (since the re-read IIR may contains more interrupts
    asserted than we clear using the result of the original read).
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d818cf47642e6379d61d9304fed3ca7c9d6786a8
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue May 8 09:22:49 2012 -0700

    xhci: Add new short TX quirk for Fresco Logic host.
    
    commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 upstream.
    
    Sergio reported that when he recorded audio from a USB headset mic
    plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
    "robotic".  When plugged into the USB 2.0 port under EHCI on the same
    laptop, the audio sounded fine.  The device is:
    
    Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
    
    The problem was tracked down to the Fresco Logic xHCI host controller
    not correctly reporting short transfers on isochronous IN endpoints.
    The driver would submit a 96 byte transfer, the device would only send
    88 or 90 bytes, and the xHCI host would report the transfer had a
    "successful" completion code, with an untransferred buffer length of 8
    or 6 bytes.
    
    The successful completion code and non-zero untransferred length is a
    contradiction.  The xHCI host is supposed to only mark a transfer as
    successful if all the bytes are transferred.  Otherwise, the transfer
    should be marked with a short packet completion code.  Without the EHCI
    bus trace, we wouldn't know whether the xHCI driver should trust the
    completion code or the untransferred length.  With it, we know to trust
    the untransferred length.
    
    Add a new xHCI quirk for the Fresco Logic host controller.  If a
    transfer is reported as successful, but the untransferred length is
    non-zero, print a warning.  For the Fresco Logic host, change the
    completion code to COMP_SHORT_TX and process the transfer like a short
    transfer.
    
    This should be backported to stable kernels that contain the commit
    f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
    Fresco Logic hosts."  That commit was marked for stable kernels as old
    as 2.6.36.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Sergio Correia <lists@uece.net>
    Tested-by: Sergio Correia <lists@uece.net>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c97ecdcfde93b2b05a0e5f3b5eaaf38e750337ae
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue May 8 07:09:26 2012 -0700

    xhci: Reset reserved command ring TRBs on cleanup.
    
    commit 33b2831ac870d50cc8e01c317b07fb1e69c13fe1 upstream.
    
    When the xHCI driver needs to clean up memory (perhaps due to a failed
    register restore on resume from S3 or resume from S4), it needs to reset
    the number of reserved TRBs on the command ring to zero.  Otherwise,
    several resume cycles (about 30) with a UAS device attached will
    continually increment the number of reserved TRBs, until all command
    submissions fail because there isn't enough room on the command ring.
    
    This patch should be backported to kernels as old as 2.6.32,
    that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d
    "USB: xhci: Change how xHCI commands are handled."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a4573e4e0bb86436881b7120a80cfb63d647a0f
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Apr 23 15:06:09 2012 +0200

    usb-xhci: Handle COMP_TX_ERR for isoc tds
    
    commit 9c745995ae5c4ff787f34a359de908facc11ee00 upstream.
    
    While testing unplugging an UVC HD webcam with usb-redirection (so through
    usbdevfs), my userspace usb-redir code was getting a value of -1 in
    iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
    is not a valid value.
    
    The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
    adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
    in this case, so this patch adds handling for that completion code to
    process_isoc_td().
    
    This was observed and tested with the following xhci controller:
    1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
    
    Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
    do, but since I cannot come up with anything better I've left that as is.
    
    This patch should be backported to kernels as old as 2.6.36, which contain the
    commit 04e51901dd44f40a5a385ced897f6bca87d5f40a "USB: xHCI: Isochronous
    transfer implementation".
    
    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@linuxfoundation.org>

commit 36a51c272d5b9795e1f3cb36cd31ba42a04ff9c3
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Feb 9 15:55:13 2012 -0800

    xhci: Add Lynx Point to list of Intel switchable hosts.
    
    commit 1c12443ab8eba71a658fae4572147e56d1f84f66 upstream.
    
    The upcoming Intel Lynx Point chipset includes an xHCI host controller
    that can have ports switched from the EHCI host controller, just like
    the Intel Panther Point xHCI host.  This time, ports from both EHCI
    hosts can be switched to the xHCI host controller.  The PCI config
    registers to do the port switching are in the exact same place in the
    xHCI PCI configuration registers, with the same semantics.
    
    Hooray for shipping patches for next-gen hardware before the current gen
    hardware is even available for purchase!
    
    This patch should be backported to stable kernels as old as 3.0,
    that contain commit 69e848c2090aebba5698a1620604c7dccb448684
    "Intel xhci: Support EHCI/xHCI port switching."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a2b2678cad20ef33206be50b9552dff62966d6d
Author: Steffen Müller <steffen.mueller@radio-frei.de>
Date:   Mon Apr 30 13:05:34 2012 +0200

    usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es
    
    commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream.
    
    Tested-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit baf4c528447b128512a26ed270604db362106005
Author: Peter Chen <peter.chen@freescale.com>
Date:   Sun Apr 1 15:17:16 2012 +0800

    usb: gadget: fsl_udc_core: dTD's next dtd pointer need to be updated once written
    
    commit 4d0947dec4db1224354e2f6f00ae22ce38e62a43 upstream.
    
    dTD's next dtd pointer need to be updated once CPU writes it, or this
    request may not be handled by controller, then host will get NAK from
    device forever.
    
    This problem occurs when there is a request is handling, we need to add
    a new request to dTD list, if this new request is added before the current
    one is finished, the new request is intended to added as next dtd pointer
    at current dTD, but without wmb(), the dTD's next dtd pointer may not be
    updated when the controller reads it. In that case, the controller will
    still get Terminate Bit is 1 at dTD's next dtd pointer, that means there is
    no next request, then this new request is missed by controller.
    
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Acked-by: Li Yang <leoli@freescale.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6d78a4766a733dd2618fe122b354ad536228941
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Fri May 11 13:56:57 2012 -0700

    USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial console
    
    commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream.
    
    The Kontron M2M development board, also known as the Fish River Island II,
    has an optional daughter card providing access to the PCH_UART (EG20T) via
    a ti_usb_3410_5052 uart to usb chip.
    
    http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html
    
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    CC: Al Borchers <alborchers@steinerpoint.com>
    CC: Peter Berger <pberger@brimson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87d8d621cdd1c47d0dc19118081412d3f8178e72
Author: Huajun Li <huajun.li.lee@gmail.com>
Date:   Fri May 18 20:12:51 2012 +0800

    USB: Remove races in devio.c
    
    commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream.
    
    There exist races in devio.c, below is one case,
    and there are similar races in destroy_async()
    and proc_unlinkurb().  Remove these races.
    
     cancel_bulk_urbs()        async_completed()
    -------------------                -----------------------
     spin_unlock(&ps->lock);
    
                               list_move_tail(&as->asynclist,
    		                    &ps->async_completed);
    
                               wake_up(&ps->wait);
    
                               Lead to free_async() be triggered,
                               then urb and 'as' will be freed.
    
     usb_unlink_urb(as->urb);
     ===> refer to the freed 'as'
    
    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Oncaphillis <oncaphillis@snafu.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2960d811d562540494c83b96e4ae4b6b11196016
Author: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Date:   Mon Apr 16 14:19:07 2012 -0700

    usb: usbtest: two super speed fixes for usbtest
    
    commit 6a23ccd216b6a8ba2c67a9f9d8969b4431ad2920 upstream.
    
    bMaxPacketSize0 field for super speed is a power of 2, not a count.
    The size itself is always 512.
    
    Max packet size for a super speed bulk endpoint is 1024, so
    allocate the urb size in halt_simple() accordingly.
    
    Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4f3ef6343463dd129f1b97d9310a9a7ab235e7b
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Thu Jan 19 14:01:04 2012 -0600

    SCSI: hpsa: Fix problem with MSA2xxx devices
    
    commit 9bc3711cbb67ac620bf09b4a147cbab45b2c36c0 upstream.
    
    Upgraded firmware on Smart Array P7xx (and some others) made them show up as
    SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx
    logical drives to the correct bus/target/lun.  A symptom of this would be that
    the target ID of the logical drives as presented by the external storage array
    is ignored, and all such logical drives are assigned to target zero,
    differentiated only by LUN.  Some multipath software reportedly does not deal
    well with this behavior, failing to recognize different paths to the same
    device as such.
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: Scott Teel <scott.teel@hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12a055f4e0cfbda9942c6cc1588b7ce5a8f757f7
Author: Rajkumar Kasirajan <rajkumar.kasirajan@stericsson.com>
Date:   Thu May 17 17:03:24 2012 -0700

    drivers/rtc/rtc-pl031.c: configure correct wday for 2000-01-01
    
    commit c0a5f4a05af588a0f9951f8d24e2564b09501918 upstream.
    
    The reset date of the ST Micro version of PL031 is 2000-01-01.  The
    correct weekday for 2000-01-01 is saturday, but pl031 is initialized to
    sunday.  This may lead to alarm malfunction, so configure the correct
    wday if RTC_DR indicates reset.
    
    Signed-off-by: Rajkumar Kasirajan <rajkumar.kasirajan@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: Mattias Wallin <mattias.wallin@stericsson.com>
    Cc: 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@linuxfoundation.org>

commit 8c2a6ba40833258c8800c7ccc638d0f37c045e10
Author: Matthias Fend <Matthias.Fend@wolfvision.net>
Date:   Mon May 7 14:37:30 2012 +0200

    USB: ffs-test: fix length argument of out function call
    
    commit eb9c5836384cd2a276254df6254ed71117983626 upstream.
    
    The out functions should only handle actual available data instead of the complete buffer.
    Otherwise for example the ep0_consume function will report ghost events since it tries to decode
    the complete buffer - which may contain partly invalid data.
    
    Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net>
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35d339b05e97ef520829f4ad947c4f4ef12e578c
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 8 15:15:25 2012 -0400

    usb-storage: unusual_devs entry for Yarvik PMP400 MP4 player
    
    commit df767b71e5816692134d59c0c17e0f77cd73333d upstream.
    
    This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400
    MP4 music player.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Jesse Feddema <jdfeddema@gmail.com>
    Tested-by: Jesse Feddema <jdfeddema@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03f9babeb1874d239998c8a42380da1a0eb25b5f
Author: Éric Piel <piel@delmic.com>
Date:   Mon May 7 12:37:54 2012 +0200

    USB: ftdi-sio: add support for Physik Instrumente E-861
    
    commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream.
    
    This adds VID/PID for the PI E-861. Without it, I had to do:
    modprobe -q ftdi-sio product=0x1008 vendor=0x1a72
    
    http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610
    
    Signed-off-by: Éric Piel <piel@delmic.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c867337cdb88f7b31f9fcf07003e97d408fcd26
Author: Alan Cox <alan@linux.intel.com>
Date:   Mon May 14 14:51:22 2012 +0100

    tty: Allow uart_register/unregister/register
    
    commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream.
    
    This is legitimate but because we don't clear the drv->state pointer in the
    unregister code causes a bogus BUG().
    
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9fecd74e41f2a9ff04071675be20a5db97723ac
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Thu May 3 11:37:12 2012 +0200

    Add missing call to uart_update_timeout()
    
    commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream.
    
    This patch fixes a problem reported here:
    http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85968a996b092b9fe3bef36065e758dcd1550a23
Author: Shaohua Li <shli@kernel.org>
Date:   Mon May 21 09:26:59 2012 +1000

    md: using GFP_NOIO to allocate bio for flush request
    
    commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream.
    
    A flush request is usually issued in transaction commit code path, so
    using GFP_KERNEL to allocate memory for flush request bio falls into
    the classic deadlock issue.
    
    This is suitable for any -stable kernel to which it applies as it
    avoids a possible deadlock.
    
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit beb9576530bc9a2685847fa1fcbf96b97686fcaf
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed May 23 12:48:13 2012 +0100

    mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkages
    
    commit 05f144a0d5c2207a0349348127f996e104ad7404 upstream.
    
    Dave Jones' system call fuzz testing tool "trinity" triggered the
    following bug error with slab debugging enabled
    
        =============================================================================
        BUG numa_policy (Not tainted): Poison overwritten
        -----------------------------------------------------------------------------
    
        INFO: 0xffff880146498250-0xffff880146498250. First byte 0x6a instead of 0x6b
        INFO: Allocated in mpol_new+0xa3/0x140 age=46310 cpu=6 pid=32154
         __slab_alloc+0x3d3/0x445
         kmem_cache_alloc+0x29d/0x2b0
         mpol_new+0xa3/0x140
         sys_mbind+0x142/0x620
         system_call_fastpath+0x16/0x1b
        INFO: Freed in __mpol_put+0x27/0x30 age=46268 cpu=6 pid=32154
         __slab_free+0x2e/0x1de
         kmem_cache_free+0x25a/0x260
         __mpol_put+0x27/0x30
         remove_vma+0x68/0x90
         exit_mmap+0x118/0x140
         mmput+0x73/0x110
         exit_mm+0x108/0x130
         do_exit+0x162/0xb90
         do_group_exit+0x4f/0xc0
         sys_exit_group+0x17/0x20
         system_call_fastpath+0x16/0x1b
        INFO: Slab 0xffffea0005192600 objects=27 used=27 fp=0x          (null) flags=0x20000000004080
        INFO: Object 0xffff880146498250 @offset=592 fp=0xffff88014649b9d0
    
    This implied a reference counting bug and the problem happened during
    mbind().
    
    mbind() applies a new memory policy to a range and uses mbind_range() to
    merge existing VMAs or split them as necessary.  In the event of splits,
    mpol_dup() will allocate a new struct mempolicy and maintain existing
    reference counts whose rules are documented in
    Documentation/vm/numa_memory_policy.txt .
    
    The problem occurs with shared memory policies.  The vm_op->set_policy
    increments the reference count if necessary and split_vma() and
    vma_merge() have already handled the existing reference counts.
    However, policy_vma() screws it up by replacing an existing
    vma->vm_policy with one that potentially has the wrong reference count
    leading to a premature free.  This patch removes the damage caused by
    policy_vma().
    
    With this patch applied Dave's trinity tool runs an mbind test for 5
    minutes without error.  /proc/slabinfo reported that there are no
    numa_policy or shared_policy_node objects allocated after the test
    completed and the shared memory region was deleted.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Stephen Wilson <wilsons@start.ca>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: 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 935055856458a05c43f518bf9ed406f67c090f0a
Author: Tejun Heo <tj@kernel.org>
Date:   Mon May 14 15:04:50 2012 -0700

    workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is active
    
    commit 544ecf310f0e7f51fa057ac2a295fc1b3b35a9d3 upstream.
    
    worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running
    isn't zero when every worker is idle.  This can trigger spuriously
    while a cpu is going down due to the way trustee sets %WORKER_ROGUE
    and zaps nr_running.
    
    It first sets %WORKER_ROGUE on all workers without updating
    nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and
    then zaps nr_running.  If the last running worker enters idle
    inbetween, it would see stale nr_running which hasn't been zapped yet
    and trigger the WARN_ON_ONCE().
    
    Fix it by performing the sanity check iff the trustee is idle.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfd6d6af769c5cd62aa9ed75b038ea3d234b090b
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 9 13:53:21 2012 +0200

    USB: cdc-wdm: poll must return POLLHUP if device is gone
    
    commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0 upstream.
    
    Else the poll will be restarted indefinitely in a tight loop,
    preventing final device cleanup.
    
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53a8734d0b66c7fb78e6cb6f0d2a559e3a255f9e
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Apr 18 23:16:45 2012 -0700

    docs: update HOWTO for 2.6.x -> 3.x versioning
    
    commit 591bfc6bf9e5e25e464fd4c87d64afd5135667c4 upstream.
    
    The HOWTO document needed updating for the new kernel versioning. The
    git URI for -next was updated as well.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a044b505aa0048922b5276a2ac653ef62605beb0
Author: Richard Weinberger <richard@nod.at>
Date:   Sat Apr 14 17:29:30 2012 +0200

    um: Implement a custom pte_same() function
    
    commit f15b9000eb1d09bbaa4b0a6b2089d7e1f64e84b3 upstream.
    
    UML uses the _PAGE_NEWPAGE flag to mark pages which are not jet
    installed on the host side using mmap().
    pte_same() has to ignore this flag, otherwise unuse_pte_range()
    is unable to unuse the page because two identical
    page tables entries with different _PAGE_NEWPAGE flags would not
    match and swapoff() would never return.
    
    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec58eb2b33386d25c4f68b42a9bf9893ddc6db1a
Author: Richard Weinberger <richard@nod.at>
Date:   Sat Apr 14 17:46:01 2012 +0200

    um: Fix __swp_type()
    
    commit 2b76ebaa728f8a3967c52aa189261c72fe56a6f1 upstream.
    
    The current __swp_type() function uses a too small bitshift.
    Using more than one swap files causes bad pages because
    the type bits clash with other page flags.
    
    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7999a8cc446cd4a2c178f5f404349a88e4c6803
Author: Matt Johnson <johnso87@illinois.edu>
Date:   Fri Apr 27 01:42:30 2012 -0500

    ahci: Detect Marvell 88SE9172 SATA controller
    
    commit 642d89252201c4155fc3946bf9cdea409e5d263e upstream.
    
    The Marvell 88SE9172 SATA controller (PCI ID 1b4b 917a) already worked
    once it was detected, but was missing an ahci_pci_tbl entry.
    
    Boot tested on a Gigabyte Z68X-UD3H-B3 motherboard.
    
    Signed-off-by: Matt Johnson <johnso87@illinois.edu>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b640f4eb78ae91cc557e998785260c03f2ca4df0
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date:   Sat Mar 17 20:16:53 2012 +0200

    mtd: sm_ftl: fix typo in major number.
    
    commit 452380efbd72d8d41f53ea64c8a6ea1fedc4394d upstream.
    
    major == 0 allocates dynamic major, not major == -1
    
    Signed-off-by: Maxim Levitsky <maximlevitsky@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@linuxfoundation.org>

commit 888cc3675baa8b5eb672b53d1c2e346fe2164bee
Author: Robert Richter <robert.richter@amd.com>
Date:   Fri May 18 12:40:42 2012 +0200

    perf/x86: Update event scheduling constraints for AMD family 15h models
    
    commit 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 upstream.
    
    This update is for newer family 15h cpu models from 0x02 to 0x1f.
    
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lkml.kernel.org/r/1337337642-1621-1-git-send-email-robert.richter@amd.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 512a8016c25d2045630b8933e7882169f7a98751
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Apr 22 13:37:09 2012 +0200

    drivers/staging/comedi/comedi_fops.c: add missing vfree
    
    commit abae41e6438b798e046d721b6ccdd55b4a398170 upstream.
    
    aux_free is freed on all other exits from the function.  By removing the
    return, we can benefit from the vfree already at the end of the function.
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee9ffef206a54067e6fa728756c8b2ce10f31acf
Author: Eric Paris <eparis@redhat.com>
Date:   Wed Apr 4 13:47:11 2012 -0400

    SELinux: if sel_make_bools errors don't leave inconsistent state
    
    commit 154c50ca4eb9ae472f50b6a481213e21ead4457d upstream.
    
    We reset the bool names and values array to NULL, but do not reset the
    number of entries in these arrays to 0.  If we error out and then get back
    into this function we will walk these NULL pointers based on the belief
    that they are non-zero length.
    
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5032d5a70bf303543fef56d014a2b69f70d5714c
Author: David Howells <dhowells@redhat.com>
Date:   Fri May 11 10:56:56 2012 +0100

    KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat
    
    commit 45de6767dc51358a188f75dc4ad9dfddb7fb9480 upstream.
    
    Use the 32-bit compat keyctl() syscall wrapper on Sparc64 for Sparc32 binary
    compatibility.
    
    Without this, keyctl(KEYCTL_INSTANTIATE_IOV) is liable to malfunction as it
    uses an iovec array read from userspace - though the kernel should survive this
    as it checks pointers and sizes anyway.
    
    I think all the other keyctl() function should just work, provided (a) the top
    32-bits of each 64-bit argument register are cleared prior to invoking the
    syscall routine, and the 32-bit address space is right at the 0-end of the
    64-bit address space.  Most of the arguments are 32-bit anyway, and so for
    those clearing is not required.
    
    Signed-off-by: David Howells <dhowells@redhat.com
    cc: "David S. Miller" <davem@davemloft.net>
    cc: sparclinux@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77f38874d05fef08ca1182155bd823f06343a3ad
Author: Steve Wise <swise@opengridcomputing.com>
Date:   Mon Apr 30 15:31:29 2012 -0500

    RDMA/cxgb4: Drop peer_abort when no endpoint found
    
    commit 14b9222808bb8bfefc71f72bc0dbdcf3b2f0140f upstream.
    
    Log a warning and drop the abort message.  Otherwise we will do a
    bogus wake_up() and crash.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35d73fe5e3d8c72a41c2eaf285a9bfb7b6c66aee
Author: nagalakshmi.nandigama@lsi.com <nagalakshmi.nandigama@lsi.com>
Date:   Tue Mar 20 12:10:01 2012 +0530

    SCSI: mpt2sas: Fix for panic happening because of improper memory allocation
    
    commit e42fafc25fa86c61824e8d4c5e7582316415d24f upstream.
    
    The ioc->pfacts member in the IOC structure is getting set to zero
    following a call to _base_get_ioc_facts due to the memset in that routine.
    So if the ioc->pfacts was read after a host reset, there would be a NULL
    pointer dereference. The routine _base_get_ioc_facts is called from context
    of host reset.  The problem in _base_get_ioc_facts  is the size of
    Mpi2IOCFactsReply is 64, whereas the sizeof "struct mpt2sas_facts" is 60,
    so there is a four byte overflow resulting from the memset.
    
    Also, there is memset in _base_get_port_facts using the incorrect structure,
    it should be "struct mpt2sas_port_facts" instead of Mpi2PortFactsReply.
    
    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a35021b41669bd9d067e87c27115fb18de2a6834
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed May 9 09:37:30 2012 +0200

    s390/pfault: fix task state race
    
    commit d5e50a51ccbda36b379aba9d1131a852eb908dda upstream.
    
    When setting the current task state to TASK_UNINTERRUPTIBLE this can
    race with a different cpu. The other cpu could set the task state after
    it inspected it (while it was still TASK_RUNNING) to TASK_RUNNING which
    would change the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING again.
    
    This race was always present in the pfault interrupt code but didn't
    cause anything harmful before commit f2db2e6c "[S390] pfault: cpu hotplug
    vs missing completion interrupts" which relied on the fact that after
    setting the task state to TASK_UNINTERRUPTIBLE the task would really
    sleep.
    Since this is not necessarily the case the result may be a list corruption
    of the pfault_list or, as observed, a use-after-free bug while trying to
    access the task_struct of a task which terminated itself already.
    
    To fix this, we need to get a reference of the affected task when receiving
    the initial pfault interrupt and add special handling if we receive yet
    another initial pfault interrupt when the task is already enqueued in the
    pfault list.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3505c3cdccba113bd2e01c8703ec70c069f36c07
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 21 12:52:42 2012 -0700

    Fix blocking allocations called very early during bootup
    
    commit 31a67102f4762df5544bc2dfb34a931233d2a5b2 upstream.
    
    During early boot, when the scheduler hasn't really been fully set up,
    we really can't do blocking allocations because with certain (dubious)
    configurations the "might_resched()" calls can actually result in
    scheduling events.
    
    We could just make such users always use GFP_ATOMIC, but quite often the
    code that does the allocation isn't really aware of the fact that the
    scheduler isn't up yet, and forcing that kind of random knowledge on the
    initialization code is just annoying and not good for anybody.
    
    And we actually have a the 'gfp_allowed_mask' exactly for this reason:
    it's just that the kernel init sequence happens to set it to allow
    blocking allocations much too early.
    
    So move the 'gfp_allowed_mask' initialization from 'start_kernel()'
    (which is some of the earliest init code, and runs with preemption
    disabled for good reasons) into 'kernel_init()'.  kernel_init() is run
    in the newly created thread that will become the 'init' process, as
    opposed to the early startup code that runs within the context of what
    will be the first idle thread.
    
    So by the time we reach 'kernel_init()', we know that the scheduler must
    be at least limping along, because we've already scheduled from the idle
    thread into the init thread.
    
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec8f0159dc6f3f39db5a644d94fd25709c301934
Author: Luis R. Rodriguez <mcgrof@frijolero.org>
Date:   Fri Mar 23 07:23:31 2012 -0700

    cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB
    
    commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.
    
    It has happened twice now where elaborate troubleshooting has
    undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
    has been set but yet net/wireless/db.txt was not updated.
    
    Despite the documentation on this it seems system integrators could
    use some more help with this, so throw out a kernel warning at boot time
    when their database is empty.
    
    This does mean that the error-prone system integrator won't likely
    realize the issue until they boot the machine but -- it does not seem
    to make sense to enable a build bug breaking random build testing.
    
    [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB
    
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Youngsin Lee <youngsin@qualcomm.com>
    Cc: Raja Mani <rmani@qca.qualcomm.com>
    Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com>
    Cc: Vipin Mehta <vipimeht@qca.qualcomm.com>
    Cc: yahuan@qca.qualcomm.com
    Cc: jjan@qca.qualcomm.com
    Cc: vthiagar@qca.qualcomm.com
    Cc: henrykim@qualcomm.com
    Cc: jouni@qca.qualcomm.com
    Cc: athiruve@qca.qualcomm.com
    Cc: cjkim@qualcomm.com
    Cc: philipk@qca.qualcomm.com
    Cc: sunnykim@qualcomm.com
    Cc: sskwak@qualcomm.com
    Cc: kkim@qualcomm.com
    Cc: mattbyun@qualcomm.com
    Cc: ryanlee@qualcomm.com
    Cc: simbap@qualcomm.com
    Cc: krislee@qualcomm.com
    Cc: conner@qualcomm.com
    Cc: hojinkim@qualcomm.com
    Cc: honglee@qualcomm.com
    Cc: johnwkim@qualcomm.com
    Cc: jinyong@qca.qualcomm.com
    Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ec196c975ffb8076df77f6fa929448717e5141b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 21 16:06:20 2012 -0700

    vfs: make AIO use the proper rw_verify_area() area helpers
    
    commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893 upstream.
    
    We had for some reason overlooked the AIO interface, and it didn't use
    the proper rw_verify_area() helper function that checks (for example)
    mandatory locking on the file, and that the size of the access doesn't
    cause us to overflow the provided offset limits etc.
    
    Instead, AIO did just the security_file_permission() thing (that
    rw_verify_area() also does) directly.
    
    This fixes it to do all the proper helper functions, which not only
    means that now mandatory file locking works with AIO too, we can
    actually remove lines of code.
    
    Reported-by: Manish Honap <manish_honap_vit@yahoo.co.in>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee9d6e9cbb6655e2d34616b3f5e6e07699f40aec
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Apr 25 13:02:19 2012 +0000

    isdn/gigaset: ratelimit CAPI message dumps
    
    commit 8e618aad5348b6e6c5a90e8d97ea643197963b20 upstream.
    
    Introduce a global ratelimit for CAPI message dumps to protect
    against possible log flood.
    Drop the ratelimit for ignored messages which is now covered by the
    global one.
    
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63ce590e41683a7ba1895a1d79b29a62b06c7613
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Wed May 16 11:10:27 2012 +0100

    PARISC: fix panic on prefetch(NULL) on PA7300LC
    
    commit b3cb8674811d1851bbf1486a73d62b90c119b994 upstream.
    
    Due to an errata, the PA7300LC generates a TLB miss interruption even on the
    prefetch instruction.  This means that prefetch(NULL), which is supposed to be
    a nop on linux actually generates a NULL deref fault.  Fix this by testing the
    address of prefetch against NULL before doing the prefetch.
    
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2952561d79919e78efee8d43b499aa4d21453f03
Author: John David Anglin <dave.anglin@bell.net>
Date:   Wed May 16 10:14:52 2012 +0100

    PARISC: fix crash in flush_icache_page_asm on PA1.1
    
    commit 207f583d7179f707f402c36a7bda5ca1fd03ad5b upstream.
    
    As pointed out by serveral people, PA1.1 only has a type 26 instruction
    meaning that the space register must be explicitly encoded.  Not giving an
    explicit space means that the compiler uses the type 24 version which is PA2.0
    only resulting in an illegal instruction crash.
    
    This regression was caused by
    
        commit f311847c2fcebd81912e2f0caf8a461dec28db41
        Author: James Bottomley <James.Bottomley@HansenPartnership.com>
        Date:   Wed Dec 22 10:22:11 2010 -0600
    
            parisc: flush pages through tmpalias space
    
    Reported-by: Helge Deller <deller@gmx.de>
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34f3f91d9ec7b735217dcba820636827f42d2811
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Tue May 15 11:04:19 2012 +0100

    PARISC: fix PA1.1 oops on boot
    
    commit 5e185581d7c46ddd33cd9c01106d1fc86efb9376 upstream.
    
    All PA1.1 systems have been oopsing on boot since
    
    commit f311847c2fcebd81912e2f0caf8a461dec28db41
    Author: James Bottomley <James.Bottomley@HansenPartnership.com>
    Date:   Wed Dec 22 10:22:11 2010 -0600
    
        parisc: flush pages through tmpalias space
    
    because a PA2.0 instruction was accidentally introduced into the PA1.1 TLB
    insertion interruption path when it was consolidated with the do_alias macro.
    Fix the do_alias macro only to use PA2.0 instructions if compiled for 64 bit.
    
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37a8457773c266cdb77fcddec008cd73e81786be
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Fri May 11 16:34:10 2012 +0200

    block: don't mark buffers beyond end of disk as mapped
    
    commit 080399aaaf3531f5b8761ec0ac30ff98891e8686 upstream.
    
    Hi,
    
    We have a bug report open where a squashfs image mounted on ppc64 would
    exhibit errors due to trying to read beyond the end of the disk.  It can
    easily be reproduced by doing the following:
    
    [root@ibm-p750e-02-lp3 ~]# ls -l install.img
    -rw-r--r-- 1 root root 142032896 Apr 30 16:46 install.img
    [root@ibm-p750e-02-lp3 ~]# mount -o loop ./install.img /mnt/test
    [root@ibm-p750e-02-lp3 ~]# dd if=/dev/loop0 of=/dev/null
    dd: reading `/dev/loop0': Input/output error
    277376+0 records in
    277376+0 records out
    142016512 bytes (142 MB) copied, 0.9465 s, 150 MB/s
    
    In dmesg, you'll find the following:
    
    squashfs: version 4.0 (2009/01/31) Phillip Lougher
    [   43.106012] attempt to access beyond end of device
    [   43.106029] loop0: rw=0, want=277410, limit=277408
    [   43.106039] Buffer I/O error on device loop0, logical block 138704
    [   43.106053] attempt to access beyond end of device
    [   43.106057] loop0: rw=0, want=277412, limit=277408
    [   43.106061] Buffer I/O error on device loop0, logical block 138705
    [   43.106066] attempt to access beyond end of device
    [   43.106070] loop0: rw=0, want=277414, limit=277408
    [   43.106073] Buffer I/O error on device loop0, logical block 138706
    [   43.106078] attempt to access beyond end of device
    [   43.106081] loop0: rw=0, want=277416, limit=277408
    [   43.106085] Buffer I/O error on device loop0, logical block 138707
    [   43.106089] attempt to access beyond end of device
    [   43.106093] loop0: rw=0, want=277418, limit=277408
    [   43.106096] Buffer I/O error on device loop0, logical block 138708
    [   43.106101] attempt to access beyond end of device
    [   43.106104] loop0: rw=0, want=277420, limit=277408
    [   43.106108] Buffer I/O error on device loop0, logical block 138709
    [   43.106112] attempt to access beyond end of device
    [   43.106116] loop0: rw=0, want=277422, limit=277408
    [   43.106120] Buffer I/O error on device loop0, logical block 138710
    [   43.106124] attempt to access beyond end of device
    [   43.106128] loop0: rw=0, want=277424, limit=277408
    [   43.106131] Buffer I/O error on device loop0, logical block 138711
    [   43.106135] attempt to access beyond end of device
    [   43.106139] loop0: rw=0, want=277426, limit=277408
    [   43.106143] Buffer I/O error on device loop0, logical block 138712
    [   43.106147] attempt to access beyond end of device
    [   43.106151] loop0: rw=0, want=277428, limit=277408
    [   43.106154] Buffer I/O error on device loop0, logical block 138713
    [   43.106158] attempt to access beyond end of device
    [   43.106162] loop0: rw=0, want=277430, limit=277408
    [   43.106166] attempt to access beyond end of device
    [   43.106169] loop0: rw=0, want=277432, limit=277408
    ...
    [   43.106307] attempt to access beyond end of device
    [   43.106311] loop0: rw=0, want=277470, limit=2774
    
    Squashfs manages to read in the end block(s) of the disk during the
    mount operation.  Then, when dd reads the block device, it leads to
    block_read_full_page being called with buffers that are beyond end of
    disk, but are marked as mapped.  Thus, it would end up submitting read
    I/O against them, resulting in the errors mentioned above.  I fixed the
    problem by modifying init_page_buffers to only set the buffer mapped if
    it fell inside of i_size.
    
    Cheers,
    Jeff
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    
    --
    
    Changes from v1->v2: re-used max_block, as suggested by Nick Piggin.
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19e40444eb3a1fddeb274c25951bdcace4315d6a
Author: Tejun Heo <tj@kernel.org>
Date:   Tue May 15 08:22:04 2012 +0200

    block: fix buffer overflow when printing partition UUIDs
    
    commit 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 upstream.
    
    6d1d8050b4bc8 "block, partition: add partition_meta_info to hd_struct"
    added part_unpack_uuid() which assumes that the passed in buffer has
    enough space for sprintfing "%pU" - 37 characters including '\0'.
    
    Unfortunately, b5af921ec0233 "init: add support for root devices
    specified by partition UUID" supplied 33 bytes buffer to the function
    leading to the following panic with stackprotector enabled.
    
      Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e
    
      [<ffffffff815e226b>] panic+0xba/0x1c6
      [<ffffffff81b14c7e>] ? printk_all_partitions+0x259/0x26xb
      [<ffffffff810566bb>] __stack_chk_fail+0x1b/0x20
      [<ffffffff81b15c7e>] printk_all_paritions+0x259/0x26xb
      [<ffffffff81aedfe0>] mount_block_root+0x1bc/0x27f
      [<ffffffff81aee0fa>] mount_root+0x57/0x5b
      [<ffffffff81aee23b>] prepare_namespace+0x13d/0x176
      [<ffffffff8107eec0>] ? release_tgcred.isra.4+0x330/0x30
      [<ffffffff81aedd60>] kernel_init+0x155/0x15a
      [<ffffffff81087b97>] ? schedule_tail+0x27/0xb0
      [<ffffffff815f4d24>] kernel_thread_helper+0x5/0x10
      [<ffffffff81aedc0b>] ? start_kernel+0x3c5/0x3c5
      [<ffffffff815f4d20>] ? gs_change+0x13/0x13
    
    Increase the buffer size, remove the dangerous part_unpack_uuid() and
    use snprintf() directly from printk_all_partitions().
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Szymon Gruszczynski <sz.gruszczynski@googlemail.com>
    Cc: Will Drewry <wad@chromium.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2c927b9f37c5668a94dee3c6b7f222414d711a3
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Fri May 18 13:33:24 2012 -0400

    tilegx: enable SYSCALL_WRAPPERS support
    
    commit e6d9668e119af44ae5bcd5f1197174531458afe3 upstream.
    
    Some discussion with the glibc mailing lists revealed that this was
    necessary for 64-bit platforms with MIPS-like sign-extension rules
    for 32-bit values.  The original symptom was that passing (uid_t)-1 to
    setreuid() was failing in programs linked -pthread because of the "setxid"
    mechanism for passing setxid-type function arguments to the syscall code.
    SYSCALL_WRAPPERS handles ensuring that all syscall arguments end up with
    proper sign-extension and is thus the appropriate fix for this problem.
    
    On other platforms (s390, powerpc, sparc64, and mips) this was fixed
    in 2.6.28.6.  The general issue is tracked as CVE-2009-0029.
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>