commit 6c180de4a3687a2caec109f84bed0b40d9ced28e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Aug 3 09:32:59 2015 -0700

    Linux 3.14.49

commit ed84c2ed1edb60257cdd89d0725a10217561df93
Author: Nicholas Mc Guire <hofrat@osadl.org>
Date:   Thu May 7 14:47:50 2015 +0200

    MIPS: KVM: Do not sign extend on unsigned MMIO load
    
    commit ed9244e6c534612d2b5ae47feab2f55a0d4b4ced upstream.
    
    Fix possible unintended sign extension in unsigned MMIO loads by casting
    to uint16_t in the case of mmio_needed != 2.
    
    Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Tested-by: James Hogan <james.hogan@imgtec.com>
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: kvm@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/9985/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ab76da285be1c19450b4f6a20f9a3c294888da4
Author: Chad Dupuis <chad.dupuis@qlogic.com>
Date:   Thu Sep 25 05:17:01 2014 -0400

    qla2xxx: Mark port lost when we receive an RSCN for it.
    
    commit ef86cb2059a14b4024c7320999ee58e938873032 upstream.
    
    Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
    Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4abcbd6f4f997d218ba54c4c835d9e18a72dcdfb
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jul 9 11:20:01 2015 -0700

    Fix firmware loader uevent buffer NULL pointer dereference
    
    commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c upstream.
    
    The firmware class uevent function accessed the "fw_priv->buf" buffer
    without the proper locking and testing for NULL.  This is an old bug
    (looks like it goes back to 2012 and commit 1244691c73b2: "firmware
    loader: introduce firmware_buf"), but for some reason it's triggering
    only now in 4.2-rc1.
    
    Shuah Khan is trying to bisect what it is that causes this to trigger
    more easily, but in the meantime let's just fix the bug since others are
    hitting it too (at least Ingo reports having seen it as well).
    
    Reported-and-tested-by: Shuah Khan <shuahkh@osg.samsung.com>
    Acked-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdf13352f0fdcb41d2132b9f41cb291b114a3939
Author: Joe Perches <joe@perches.com>
Date:   Thu Mar 26 20:47:10 2015 -0700

    hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead
    
    commit a28e4b2b18ccb90df402da3f21e1a83c9d4f8ec1 upstream.
    
    Removing unnecessary static buffers is good.
    Use the vsprintf %pV extension instead.
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a788e1386d8dfe9b20eb0522fffba56a145d79c7
Author: Christoffer Dall <christoffer.dall@linaro.org>
Date:   Wed Jul 1 14:08:31 2015 +0200

    arm64: Don't report clear pmds and puds as huge
    
    commit fd28f5d439fca77348c129d5b73043a56f8a0296 upstream.
    
    The current pmd_huge() and pud_huge() functions simply check if the table
    bit is not set and reports the entries as huge in that case.  This is
    counter-intuitive as a clear pmd/pud cannot also be a huge pmd/pud, and
    it is inconsistent with at least arm and x86.
    
    To prevent others from making the same mistake as me in looking at code
    that calls these functions and to fix an issue with KVM on arm64 that
    causes memory corruption due to incorrect page reference counting
    resulting from this mistake, let's change the behavior.
    
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Reviewed-by: Steve Capper <steve.capper@linaro.org>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Fixes: 084bd29810a5 ("ARM64: mm: HugeTLB support.")
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79494ffe93cadb66e6c88d7e67d5eff3699fb266
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Jun 28 14:18:16 2015 +0100

    agp/intel: Fix typo in needs_ilk_vtd_wa()
    
    commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.
    
    In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
    the ids for the mobile GPU and the mobile host bridge. That latter is
    impossible and so likely was just a typo for the desktop GPU device id
    (which is also buggy).
    
    Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Wed Feb 13 09:31:53 2013 +0000
    
        drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
    
    Reported-by: Ting-Wei Lan <lantw44@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127
    References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db51d9652aad3415ca51c44c2b79c88ba78785f5
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Jun 24 17:24:33 2015 +0300

    rbd: use GFP_NOIO in rbd_obj_request_create()
    
    commit 5a60e87603c4c533492c515b7f62578189b03c9c upstream.
    
    rbd_obj_request_create() is called on the main I/O path, so we need to
    use GFP_NOIO to make sure allocation doesn't blow back on us.  Not all
    callers need this, but I'm still hardcoding the flag inside rather than
    making it a parameter because a) this is going to stable, and b) those
    callers shouldn't really use rbd_obj_request_create() and will be fixed
    in the future.
    
    More memory allocation fixes will follow.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5347e3a935573310ce420b306e86cd3c5670202
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Jul 12 10:34:29 2015 -0400

    9p: don't leave a half-initialized inode sitting around
    
    commit 0a73d0a204a4a04a1e110539c5a524ae51f91d6d upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 360e4e9ec085f43a8e975a1810cd053952d7bfad
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Jul 4 16:04:19 2015 -0400

    9p: forgetting to cancel request on interrupted zero-copy RPC
    
    commit a84b69cb6e0a41e86bc593904faa6def3b957343 upstream.
    
    If we'd already sent a request and decide to abort it, we *must*
    issue TFLUSH properly and not just blindly reuse the tag, or
    we'll get seriously screwed when response eventually arrives
    and we confuse it for response to later request that had reused
    the same tag.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a8ca28bb26b3d89a604fa2cb2f390102cc6761f
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Mon Jun 1 15:10:25 2015 -0400

    SUNRPC: Fix a memory leak in the backchannel code
    
    commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream.
    
    req->rq_private_buf isn't initialised when xprt_setup_backchannel calls
    xprt_free_allocation.
    
    Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b873e2f230b631e6e09e61d098bfac285505eeda
Author: Jeff Layton <jlayton@poochiereds.net>
Date:   Tue Jun 9 19:43:56 2015 -0400

    nfs: increase size of EXCHANGE_ID name string buffer
    
    commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream.
    
    The current buffer is much too small if you have a relatively long
    hostname. Bring it up to the size of the one that SETCLIENTID has.
    
    Reported-by: Michael Skralivetsky <michael.skralivetsky@primarydata.com>
    Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8647f53903e0e97c53b8d4ddfa3abb29737d8d0e
Author: Olga Kornievskaia <kolga@netapp.com>
Date:   Fri May 15 11:45:31 2015 -0400

    fixing infinite OPEN loop in 4.0 stateid recovery
    
    commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream.
    
    Problem: When an operation like WRITE receives a BAD_STATEID, even though
    recovery code clears the RECLAIM_NOGRACE recovery flag before recovering
    the open state, because of clearing delegation state for the associated
    inode, nfs_inode_find_state_and_recover() gets called and it makes the
    same state with RECLAIM_NOGRACE flag again. As a results, when we restart
    looking over the open states, we end up in the infinite loop instead of
    breaking out in the next test of state flags.
    
    Solution: unset the RECLAIM_NOGRACE set because of
    calling of nfs_inode_find_state_and_recover() after returning from calling
    recover_open() function.
    
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 752a65413b78af54f15bf5e778235d64dcc9d56b
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue May 26 11:53:52 2015 -0400

    NFS: Fix size of NFSACL SETACL operations
    
    commit d683cc49daf7c5afca8cd9654aaa1bf63cdf2ad9 upstream.
    
    When encoding the NFSACL SETACL operation, reserve just the estimated
    size of the ACL rather than a fixed maximum. This eliminates needless
    zero padding on the wire that the server ignores.
    
    Fixes: ee5dc7732bd5 ('NFS: Fix "kernel BUG at fs/nfs/nfs3xdr.c:1338!"')
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 615b5141abfb6c1f3787a766be3a3ef480b18957
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Apr 29 20:38:46 2015 +0200

    watchdog: omap: assert the counter being stopped before reprogramming
    
    commit 530c11d432727c697629ad5f9d00ee8e2864d453 upstream.
    
    The omap watchdog has the annoying behaviour that writes to most
    registers don't have any effect when the watchdog is already running.
    Quoting the AM335x reference manual:
    
    	To modify the timer counter value (the WDT_WCRR register),
    	prescaler ratio (the WDT_WCLR[4:2] PTV bit field), delay
    	configuration value (the WDT_WDLY[31:0] DLY_VALUE bit field), or
    	the load value (the WDT_WLDR[31:0] TIMER_LOAD bit field), the
    	watchdog timer must be disabled by using the start/stop sequence
    	(the WDT_WSPR register).
    
    Currently the timer is stopped in the .probe callback but still there
    are possibilities that yield to a situation where omap_wdt_start is
    entered with the timer running (e.g. when /dev/watchdog is closed
    without stopping and then reopened). In such a case programming the
    timeout silently fails!
    
    To circumvent this stop the timer before reprogramming.
    
    Assuming one of the first things the watchdog user does is setting the
    timeout explicitly nothing too bad should happen because this explicit
    setting works fine.
    
    Fixes: 7768a13c252a ("[PATCH] OMAP: Add Watchdog driver support")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7698906bdc7cd2c935eba0cde4bcbf8d148730d3
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Wed Apr 8 19:59:20 2015 +0300

    of: return NUMA_NO_NODE from fallback of_node_to_nid()
    
    commit c8fff7bc5bba6bd59cad40441c189c4efe7190f6 upstream.
    
    Node 0 might be offline as well as any other numa node,
    in this case kernel cannot handle memory allocation and crashes.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function")
    Signed-off-by: Grant Likely <grant.likely@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80c825f2facf71acf7e605f2ac555cf7fde14cc4
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Wed Jul 22 07:57:12 2015 -0400

    block: Do a full clone when splitting discard bios
    
    commit f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc upstream.
    
    This fixes a data corruption bug when using discard on top of MD linear,
    raid0 and raid10 personalities.
    
    Commit 20d0189b1012 "block: Introduce new bio_split()" permits sharing
    the bio_vec between the two resulting bios. That is fine for read/write
    requests where the bio_vec is immutable. For discards, however, we need
    to be able to attach a payload and update the bio_vec so the page can
    get mapped to a scatterlist entry. Therefore the bio_vec can not be
    shared when splitting discards and we must do a full clone.
    
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reported-by: Seunguk Shin <seunguk.shin@samsung.com>
    Tested-by: Seunguk Shin <seunguk.shin@samsung.com>
    Cc: Seunguk Shin <seunguk.shin@samsung.com>
    Cc: Jens Axboe <axboe@fb.com>
    Cc: Kent Overstreet <kent.overstreet@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22029a0ccb163815f8ff3f0d41bb924565bed90b
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jan 29 11:29:13 2015 -0500

    USB: usbfs: allow URBs to be reaped after disconnection
    
    commit 3f2cee73b650921b2e214bf487b2061a1c266504 upstream.
    
    The usbfs API has a peculiar hole: Users are not allowed to reap their
    URBs after the device has been disconnected.  There doesn't seem to be
    any good reason for this; it is an ad-hoc inconsistency.
    
    The patch allows users to issue the USBDEVFS_REAPURB and
    USBDEVFS_REAPURBNDELAY ioctls (together with their 32-bit counterparts
    on 64-bit systems) even after the device is gone.  If no URBs are
    pending for a disconnected device then the ioctls will return -ENODEV
    rather than -EAGAIN, because obviously no new URBs will ever be able
    to complete.
    
    The patch also adds a new capability flag for
    USBDEVFS_GET_CAPABILITIES to indicate that the reap-after-disconnect
    feature is supported.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Chris Dickens <christopher.a.dickens@gmail.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 637a3249626a7de6cfaa63e56930538f1e9829f9
Author: Pali Rohár <pali.rohar@gmail.com>
Date:   Tue Jun 23 10:11:19 2015 +0200

    dell-laptop: Fix allocating & freeing SMI buffer page
    
    commit b8830a4e71b15d0364ac8e6c55301eea73f211da upstream.
    
    This commit fix kernel crash when probing for rfkill devices in dell-laptop
    driver failed. Function free_page() was incorrectly used on struct page *
    instead of virtual address of SMI buffer.
    
    This commit also simplify allocating page for SMI buffer by using
    __get_free_page() function instead of sequential call of functions
    alloc_page() and page_address().
    
    Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39a8db185a4f731be6b913a474d59b872bc96f6f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sat Jun 13 15:23:33 2015 +0200

    ideapad: fix software rfkill setting
    
    commit 4b200b4604bec3388426159f1656109d19fadf6e upstream.
    
    This fixes a several year old regression that I found while trying
    to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant
    to send a command to the embedded controller through ACPI, but
    as of c1f73658ed, it sends the index of the rfkill device instead
    of the command, and ignores the opcode field.
    
    This changes it back to the original behavior, which indeed
    flips the rfkill state as seen in the debugfs interface.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)")
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 510a437d013e8531c4b6d9854e056ca79cf4ba49
Author: Damian Eppel <d.eppel@samsung.com>
Date:   Fri Jun 26 15:23:04 2015 +0200

    clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier
    
    commit 56a94f13919c0db5958611b388e1581b4852f3c9 upstream.
    
    Whilst testing cpu hotplug events on kernel configured with
    DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP we get following BUG message,
    caused by calling request_irq() and free_irq() in the context of
    hotplug notification (which is in this case atomic context).
    
    [   40.785859] CPU1: Software reset
    [   40.786660] BUG: sleeping function called from invalid context at mm/slub.c:1241
    [   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
    [   40.786678] Preemption disabled at:[<  (null)>]   (null)
    [   40.786681]
    [   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc4-00024-g7dca860 #36
    [   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
    [   40.786728] [<c0014a00>] (unwind_backtrace) from [<c0011980>] (show_stack+0x10/0x14)
    [   40.786747] [<c0011980>] (show_stack) from [<c0449ba0>] (dump_stack+0x70/0xbc)
    [   40.786767] [<c0449ba0>] (dump_stack) from [<c00c6124>] (kmem_cache_alloc+0xd8/0x170)
    [   40.786785] [<c00c6124>] (kmem_cache_alloc) from [<c005d6f8>] (request_threaded_irq+0x64/0x128)
    [   40.786804] [<c005d6f8>] (request_threaded_irq) from [<c0350b8c>] (exynos4_local_timer_setup+0xc0/0x13c)
    [   40.786820] [<c0350b8c>] (exynos4_local_timer_setup) from [<c0350ca8>] (exynos4_mct_cpu_notify+0x30/0xa8)
    [   40.786838] [<c0350ca8>] (exynos4_mct_cpu_notify) from [<c003b330>] (notifier_call_chain+0x44/0x84)
    [   40.786857] [<c003b330>] (notifier_call_chain) from [<c0022fd4>] (__cpu_notify+0x28/0x44)
    [   40.786873] [<c0022fd4>] (__cpu_notify) from [<c0013714>] (secondary_start_kernel+0xec/0x150)
    [   40.786886] [<c0013714>] (secondary_start_kernel) from [<40008764>] (0x40008764)
    
    Interrupts cannot be requested/freed in the CPU_STARTING/CPU_DYING
    notifications which run on the hotplugged cpu with interrupts and
    preemption disabled.
    
    To avoid the issue, request the interrupts for all possible cpus in
    the boot code. The interrupts are marked NO_AUTOENABLE to avoid a racy
    request_irq/disable_irq() sequence. The flag prevents the
    request_irq() code from enabling the interrupt immediately.
    
    The interrupt is then enabled in the CPU_STARTING notifier of the
    hotplugged cpu and again disabled with disable_irq_nosync() in the
    CPU_DYING notifier.
    
    [ tglx: Massaged changelog to match the patch ]
    
    Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for local timer registration")
    Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Tested-by: Marcin Jabrzyk <m.jabrzyk@samsung.com>
    Signed-off-by: Damian Eppel <d.eppel@samsung.com>
    Cc: m.szyprowski@samsung.com
    Cc: kyungmin.park@samsung.com
    Cc: daniel.lezcano@linaro.org
    Cc: kgene@kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/1435324984-7328-1-git-send-email-d.eppel@samsung.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ea1b03950b3c587b837d20bd11715d1430c010b
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Fri May 22 10:22:40 2015 +0200

    mac80211: prevent possible crypto tx tailroom corruption
    
    commit ab499db80fcf07c18e4053f91a619500f663e90e upstream.
    
    There was a possible race between
    ieee80211_reconfig() and
    ieee80211_delayed_tailroom_dec(). This could
    result in inability to transmit data if driver
    crashed during roaming or rekeying and subsequent
    skbs with insufficient tailroom appeared.
    
    This race was probably never seen in the wild
    because a device driver would have to crash AND
    recover within 0.5s which is very unlikely.
    
    I was able to prove this race exists after
    changing the delay to 10s locally and crashing
    ath10k via debugfs immediately after GTK
    rekeying. In case of ath10k the counter went below
    0. This was harmless but other drivers which
    actually require tailroom (e.g. for WEP ICV or
    MMIC) could end up with the counter at 0 instead
    of >0 and introduce insufficient skb tailroom
    failures because mac80211 would not resize skbs
    appropriately anymore.
    
    Fixes: 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when roaming")
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75be724f4edfc8fd51303a47c214dec2c29f8e08
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Thu Jun 25 15:01:44 2015 -0700

    security_syslog() should be called once only
    
    commit d194e5d666225b04c7754471df0948f645b6ab3a upstream.
    
    The final version of commit 637241a900cb ("kmsg: honor dmesg_restrict
    sysctl on /dev/kmsg") lost few hooks, as result security_syslog() are
    processed incorrectly:
    
    - open of /dev/kmsg checks syslog access permissions by using
      check_syslog_permissions() where security_syslog() is not called if
      dmesg_restrict is set.
    
    - syslog syscall and /proc/kmsg calls do_syslog() where security_syslog
      can be executed twice (inside check_syslog_permissions() and then
      directly in do_syslog())
    
    With this patch security_syslog() is called once only in all
    syslog-related operations regardless of dmesg_restrict value.
    
    Fixes: 637241a900cb ("kmsg: honor dmesg_restrict sysctl on /dev/kmsg")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Cc: Eric Paris <eparis@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 567ee68e2c19462b5a1101ef551f2dcd5af0a2ff
Author: Chris Metcalf <cmetcalf@ezchip.com>
Date:   Thu Jun 25 15:02:08 2015 -0700

    __bitmap_parselist: fix bug in empty string handling
    
    commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 upstream.
    
    bitmap_parselist("", &mask, nmaskbits) will erroneously set bit zero in
    the mask.  The same bug is visible in cpumask_parselist() since it is
    layered on top of the bitmask code, e.g.  if you boot with "isolcpus=",
    you will actually end up with cpu zero isolated.
    
    The bug was introduced in commit 4b060420a596 ("bitmap, irq: add
    smp_affinity_list interface to /proc/irq") when bitmap_parselist() was
    generalized to support userspace as well as kernelspace.
    
    Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
    Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    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 7e7f9ef49764684da13bbfb61ca552b70613a461
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jun 25 00:35:16 2015 +0200

    PM / sleep: Increase default DPM watchdog timeout to 60
    
    commit fff3b16d2754a061a3549c4307a186423a0128fd upstream.
    
    Many harddisks (mostly WD ones) have firmware problems and take too
    long, more than 10 seconds, to resume from suspend.  And this often
    exceeds the default DPM watchdog timeout (12 seconds), resulting in a
    kernel panic out of sudden.
    
    Since most distros just take the default as is, we should give a bit
    more safer value.  This patch increases the default value from 12
    seconds to one minute, which has been confirmed to be long enough for
    such problematic disks.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=91921
    Fixes: 70fea60d888d (PM / Sleep: Detect device suspend/resume lockup and log event)
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13f42f740aa0ebd55b8b48d911b38371108d81ee
Author: Ding Wang <justin.wang@spreadtrum.com>
Date:   Mon May 18 20:14:15 2015 +0800

    mmc: card: Fixup request missing in mmc_blk_issue_rw_rq
    
    commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 upstream.
    
    The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
    may cause new coming request permanent missing when the ongoing
    request (previoulsy started) complete end.
    
    The problem scenario is as follows:
    (1) Request A is ongoing;
    (2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
    (3) Request A encounters the MMC_BLK_CMD_ERR error;
    (4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
        end request A completed and return zero. Continue the error handling,
        suppose mmc_blk_reset() reset device success;
    (5) Continue the execution, while loop completed because variable ret
        is zero now;
    (6) Finally, mmc_blk_issue_rw_rq() return without processing request B.
    
    The process related to the missing request may wait that IO request
    complete forever, possibly crashing the application or hanging the system.
    
    Fix this issue by starting new request when reset success.
    
    Signed-off-by: Ding Wang <justin.wang@spreadtrum.com>
    Fixes: 67716327eec7 ("mmc: block: add eMMC hardware reset support")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97883d0d82b2ea44597f9a6ee321b6edb02b66b1
Author: Sagi Grimberg <sagig@mellanox.com>
Date:   Thu Jun 4 19:49:20 2015 +0300

    iser-target: release stale iser connections
    
    commit 2f1b6b7d9a815f341b18dfd26a363f37d4d3c96a upstream.
    
    When receiving a new iser connect request we serialize
    the pending requests by adding the newly created iser connection
    to the np accept list and let the login thread process the connect
    request one by one (np_accept_wait).
    
    In case we received a disconnect request before the iser_conn
    has begun processing (still linked in np_accept_list) we should
    detach it from the list and clean it up and not have the login
    thread process a stale connection. We do it only when the connection
    state is not already terminating (initiator driven disconnect) as
    this might lead us to access np_accept_mutex after the np was released
    in live shutdown scenarios.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Jenny Falkovich <jennyf@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4056924db5898b1eb2695f014d1ee2569bda5b4
Author: Sagi Grimberg <sagig@mellanox.com>
Date:   Sun Mar 29 15:52:04 2015 +0300

    iser-target: Fix possible deadlock in RDMA_CM connection error
    
    commit 4a579da2586bd3b79b025947ea24ede2bbfede62 upstream.
    
    Before we reach to connection established we may get an
    error event. In this case the core won't teardown this
    connection (never established it), so we take care of freeing
    it ourselves.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ae80131575a8497799d818f33e9f3c18d4b07fd
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Feb 26 22:19:15 2015 -0800

    iscsi-target: Convert iscsi_thread_set usage to kthread.h
    
    commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca upstream.
    
    This patch converts iscsi-target code to use modern kthread.h API
    callers for creating RX/TX threads for each new iscsi_conn descriptor,
    and releasing associated RX/TX threads during connection shutdown.
    
    This is done using iscsit_start_kthreads() -> kthread_run() to start
    new kthreads from within iscsi_post_login_handler(), and invoking
    kthread_stop() from existing iscsit_close_connection() code.
    
    Also, convert iscsit_logout_post_handler_closesession() code to use
    cmpxchg when determing when iscsit_cause_connection_reinstatement()
    needs to sleep waiting for completion.
    
    Reported-by: Sagi Grimberg <sagig@mellanox.com>
    Tested-by: Sagi Grimberg <sagig@mellanox.com>
    Cc: Slava Shwartsman <valyushash@gmail.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1028665b14ba748b48046a1dfd97a828c01bb61c
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Wed Jul 1 14:43:26 2015 +0800

    ACPICA: Tables: Fix an issue that FACS initialization is performed twice
    
    commit c04be18448355441a0c424362df65b6422e27bda upstream.
    
    ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658
    
    This patch adds a new FACS initialization flag for acpi_tb_initialize().
    acpi_enable_subsystem() might be invoked several times in OS bootup process,
    and we don't want FACS initialization to be invoked twice. Lv Zheng.
    
    Link: https://github.com/acpica/acpica/commit/90f5332a
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9876d7419edb206d58db51440d616148b4d06c2
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Jun 29 19:30:23 2015 +0300

    crush: fix a bug in tree bucket decode
    
    commit 82cd003a77173c91b9acad8033fb7931dac8d751 upstream.
    
    struct crush_bucket_tree::num_nodes is u8, so ceph_decode_8_safe()
    should be used.  -Wconversion catches this, but I guess it went
    unnoticed in all the noise it spews.  The actual problem (at least for
    common crushmaps) isn't the u32 -> u8 truncation though - it's the
    advancement by 4 bytes instead of 1 in the crushmap buffer.
    
    Fixes: http://tracker.ceph.com/issues/2759
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Josh Durgin <jdurgin@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41ba3f95026b5910e7179c579db88862257c6125
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Wed Jul 1 16:25:55 2015 +0200

    fuse: initialize fc->release before calling it
    
    commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed upstream.
    
    fc->release is called from fuse_conn_put() which was used in the error
    cleanup before fc->release was initialized.
    
    [Jeremiah Mahler <jmmahler@gmail.com>: assign fc->release after calling
    fuse_conn_init(fc) instead of before.]
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afee5b6682d0e3926489b37582fb2b050583529d
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Jul 3 08:36:11 2015 +0100

    Btrfs: fix memory leak in the extent_same ioctl
    
    commit 497b4050e0eacd4c746dd396d14916b1e669849d upstream.
    
    We were allocating memory with memdup_user() but we were never releasing
    that memory. This affected pretty much every call to the ioctl, whether
    it deduplicated extents or not.
    
    This issue was reported on IRC by Julian Taylor and on the mailing list
    by Marcel Ritter, credit goes to them for finding the issue.
    
    Reported-by: Julian Taylor <jtaylor.debian@googlemail.com>
    Reported-by: Marcel Ritter <ritter.marcel@gmail.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Mark Fasheh <mfasheh@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1abde69d9deedef5155bcc79ae88298a8763c2c8
Author: Filipe Manana <fdmanana@suse.com>
Date:   Sat Jun 13 06:52:56 2015 +0100

    Btrfs: use kmem_cache_free when freeing entry in inode cache
    
    commit c3f4a1685bb87e59c886ee68f7967eae07d4dffa upstream.
    
    The free space entries are allocated using kmem_cache_zalloc(),
    through __btrfs_add_free_space(), therefore we should use
    kmem_cache_free() and not kfree() to avoid any confusion and
    any potential problem. Looking at the kfree() definition at
    mm/slab.c it has the following comment:
    
      /*
       * (...)
       *
       * Don't free memory not originally allocated by kmalloc()
       * or you will run into trouble.
       */
    
    So better be safe and use kmem_cache_free().
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b808a7ee5384d2ff472dfa832394263b7054e56c
Author: Firo Yang <firogm@gmail.com>
Date:   Thu Jun 11 09:41:10 2015 +0800

    md: fix a build warning
    
    commit 4e023612325a9034a542bfab79f78b1fe5ebb841 upstream.
    
    Warning like this:
    
    drivers/md/md.c: In function "update_array_info":
    drivers/md/md.c:6394:26: warning: logical not is only applied
    to the left hand side of comparison [-Wlogical-not-parentheses]
          !mddev->persistent  != info->not_persistent||
    
    Fix it as Neil Brown said:
    mddev->persistent != !info->not_persistent ||
    
    Signed-off-by: Firo Yang <firogm@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f65ca32b2c9bcd5ca9f5326f174428c1beda4c7
Author: Stevens, Nick <Nick.Stevens@digi.com>
Date:   Wed Jul 1 16:07:41 2015 +0000

    hwmon: (mcp3021) Fix broken output scaling
    
    commit 347d7e45bd09ce09cbc30d5cea9de377eb22f55c upstream.
    
    The mcp3021 scaling code is dividing the VDD (full-scale) value in
    millivolts by the A2D resolution to obtain the scaling factor. When VDD
    is 3300mV (the standard value) and the resolution is 12-bit (4096
    divisions), the result is a scale factor of 3300/4096, which is always
    one.  Effectively, the raw A2D reading is always being returned because
    no scaling is applied.
    
    This patch fixes the issue and simplifies the register-to-volts
    calculation, removing the unneeded "output_scale" struct member.
    
    Signed-off-by: Nick Stevens <Nick.Stevens@digi.com>
    [Guenter Roeck: Dropped unnecessary value check]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7455cf6dd3b0d8dea67ba34eb7913bfffb2af0e0
Author: Lior Amsalem <alior@marvell.com>
Date:   Tue May 26 15:07:32 2015 +0200

    dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup
    
    commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream.
    
    This patch fixes a bug in the XOR driver where the cleanup function can be
    called and free descriptors that never been processed by the engine (which
    result in data errors).
    
    The cleanup function will free descriptors based on the ownership bit in
    the descriptors.
    
    Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
    Signed-off-by: Lior Amsalem <alior@marvell.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Reviewed-by: Ofer Heifetz <oferh@marvell.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c3515b900168ceb181f91f9acd0c810c2d5e4b4
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Tue Jul 7 15:05:03 2015 -0400

    tracing: Have branch tracer use recursive field of task struct
    
    commit 6224beb12e190ff11f3c7d4bf50cb2922878f600 upstream.
    
    Fengguang Wu's tests triggered a bug in the branch tracer's start up
    test when CONFIG_DEBUG_PREEMPT set. This was because that config
    adds some debug logic in the per cpu field, which calls back into
    the branch tracer.
    
    The branch tracer has its own recursive checks, but uses a per cpu
    variable to implement it. If retrieving the per cpu variable calls
    back into the branch tracer, you can see how things will break.
    
    Instead of using a per cpu variable, use the trace_recursion field
    of the current task struct. Simply set a bit when entering the
    branch tracing and clear it when leaving. If the bit is set on
    entry, just don't do the tracing.
    
    There's also the case with lockdep, as the local_irq_save() called
    before the recursion can also trigger code that can call back into
    the function. Changing that to a raw_local_irq_save() will protect
    that as well.
    
    This prevents the recursion and the inevitable crash that follows.
    
    Link: http://lkml.kernel.org/r/20150630141803.GA28071@wfg-t540p.sh.intel.com
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46c6c6903dd3ba041749b7885ed91029277680dd
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Jun 25 18:10:09 2015 -0400

    tracing/filter: Do not allow infix to exceed end of string
    
    commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 upstream.
    
    While debugging a WARN_ON() for filtering, I found that it is possible
    for the filter string to be referenced after its end. With the filter:
    
     # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter
    
    The filter_parse() function can call infix_get_op() which calls
    infix_advance() that updates the infix filter pointers for the cnt
    and tail without checking if the filter is already at the end, which
    will put the cnt to zero and the tail beyond the end. The loop then calls
    infix_next() that has
    
    	ps->infix.cnt--;
    	return ps->infix.string[ps->infix.tail++];
    
    The cnt will now be below zero, and the tail that is returned is
    already passed the end of the filter string. So far the allocation
    of the filter string usually has some buffer that is zeroed out, but
    if the filter string is of the exact size of the allocated buffer
    there's no guarantee that the charater after the nul terminating
    character will be zero.
    
    Luckily, only root can write to the filter.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42d97c682b6cc4a515c7485e82aa731b35124b93
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Jun 25 18:02:29 2015 -0400

    tracing/filter: Do not WARN on operand count going below zero
    
    commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream.
    
    When testing the fix for the trace filter, I could not come up with
    a scenario where the operand count goes below zero, so I added a
    WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case
    that it can happen (although the filter would be wrong).
    
     # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter
    
    That is, a single operation without any operands will hit the path
    where the WARN_ON_ONCE() can trigger. Although this is harmless,
    and the filter is reported as a error. But instead of spitting out
    a warning to the kernel dmesg, just fail nicely and report it via
    the proper channels.
    
    Link: http://lkml.kernel.org/r/558C6082.90608@oracle.com
    
    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d603db6866e95aaf908bf429d86e655c90dc4b2e
Author: Arne Fitzenreiter <arne_f@ipfire.org>
Date:   Wed Jul 15 13:54:37 2015 +0200

    libata: force disable trim for SuperSSpeed S238
    
    commit cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc upstream.
    
    This device loses blocks, often the partition table area, on trim.
    Disable TRIM.
    http://pcengines.ch/msata16a.htm
    
    Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9df7bfdab50978f8ccfba460827e138d1f4084f9
Author: Arne Fitzenreiter <arne_f@ipfire.org>
Date:   Wed Jul 15 13:54:36 2015 +0200

    libata: add ATA_HORKAGE_NOTRIM
    
    commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 upstream.
    
    Some devices lose data on TRIM whether queued or not.  This patch adds
    a horkage to disable TRIM.
    
    tj: Collapsed unnecessary if() nesting.
    
    Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64351188e4a28c362bb62f71254102892562f4a4
Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
Date:   Tue Apr 21 13:59:31 2015 -0400

    evm: labeling pseudo filesystems exception
    
    commit 5101a1850bb7ccbf107929dee9af0cd2f400940f upstream.
    
    To prevent offline stripping of existing file xattrs and relabeling of
    them at runtime, EVM allows only newly created files to be labeled.  As
    pseudo filesystems are not persistent, stripping of xattrs is not a
    concern.
    
    Some LSMs defer file labeling on pseudo filesystems.  This patch
    permits the labeling of existing files on pseudo files systems.
    
    Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 735ad0d67f7363a2b9e7c182a0f1655597e9fa16
Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
Date:   Thu Jun 11 11:54:42 2015 -0400

    ima: fix ima_show_template_data_ascii()
    
    commit 45b26133b97871896b8c5241d59f4ff7839db7b2 upstream.
    
    This patch fixes a bug introduced in "4d7aeee ima: define new template
    ima-ng and template fields d-ng and n-ng".
    
    Changelog:
    - change int to uint32 (Roberto Sassu's suggestion)
    
    Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Signed-off-by: Roberto Sassu <rsassu@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9cd9b18dac801040ada16562dc579d5ac366d75
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Jul 27 15:23:43 2015 +0100

    KEYS: ensure we free the assoc array edit if edit is valid
    
    commit ca4da5dd1f99fe9c59f1709fb43e818b18ad20e0 upstream.
    
    __key_link_end is not freeing the associated array edit structure
    and this leads to a 512 byte memory leak each time an identical
    existing key is added with add_key().
    
    The reason the add_key() system call returns okay is that
    key_create_or_update() calls __key_link_begin() before checking to see
    whether it can update a key directly rather than adding/replacing - which
    it turns out it can.  Thus __key_link() is not called through
    __key_instantiate_and_link() and __key_link_end() must cancel the edit.
    
    CVE-2015-1333
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce4703c07b3e0af19c84f301e7664baaa3094e65
Author: Hon Ching \\(Vicky\\) Lo <honclo@linux.vnet.ibm.com>
Date:   Fri May 22 13:23:02 2015 -0400

    vTPM: set virtual device before passing to ibmvtpm_reset_crq
    
    commit 9d75f08946e8485109458ccf16f714697c207f41 upstream.
    
    tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
    set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
    the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address.
    
    Signed-off-by: Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>
    Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
    Reviewed-by: Ashley Lai <ashley@ahsleylai.com>
    Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
    Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12029f2222cd0db2b25e7c34853a166c494df351
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Mon Jun 22 09:42:48 2015 +1000

    xfs: fix remote symlinks on V5/CRC filesystems
    
    commit 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 upstream.
    
    If we create a CRC filesystem, mount it, and create a symlink with
    a path long enough that it can't live in the inode, we get a very
    strange result upon remount:
    
    # ls -l mnt
    total 4
    lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM
    
    XSLM is the V5 symlink block header magic (which happens to be
    followed by a NUL, so the string looks terminated).
    
    xfs_readlink_bmap() advanced cur_chunk by the size of the header
    for CRC filesystems, but never actually used that pointer; it
    kept reading from bp->b_addr, which is the start of the block,
    rather than the start of the symlink data after the header.
    
    Looks like this problem goes back to v3.10.
    
    Fixing this gets us reading the proper link target, again.
    
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff40ffaf5cb00e49e5acc635212bc2060ef8d872
Author: Zhao Junwang <zhjwpku@gmail.com>
Date:   Tue Jul 7 17:08:35 2015 +0800

    drm: add a check for x/y in drm_mode_setcrtc
    
    commit 01447e9f04ba1c49a9534ae6a5a6f26c2bb05226 upstream.
    
    legacy setcrtc ioctl does take a 32 bit value which might indeed
    overflow
    
    the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
    needed any more with this
    
    v2: -polish the annotation according to Daniel's comment
    
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Zhao Junwang <zhjwpku@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f842158eca0e5dc1257e31bb38eadc94d3f56d7e
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jul 9 21:08:17 2015 -0400

    drm/radeon: add a dpm quirk for Sapphire Radeon R9 270X 2GB GDDR5
    
    commit 5dfc71bc44d91d1620505c064fa22b0b3db58a9d upstream.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=76490
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68c31ce38baddfc69d4301f71edd02618c882aba
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Jul 3 10:02:27 2015 +0900

    drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL
    
    commit 233709d2cd6bbaaeda0aeb8d11f6ca7f98563b39 upstream.
    
    This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
    or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
    flushes the TLB after setting rdev->gart.ptr to non-NULL.
    
    Fixes panic on powering off R7xx GPUs.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bd2d54d351bd645bb033d82ff2efc07a1a202dc
Author: Jérôme Glisse <jglisse@redhat.com>
Date:   Fri Jun 19 10:32:16 2015 -0400

    drm/radeon: SDMA fix hibernation (CI GPU family).
    
    commit 2ba8d1bb8f6b589037f7db1f01144fc80750e8f7 upstream.
    
    In order for hibernation to reliably work we need to properly turn
    off the SDMA block, sadly after numerous attemps i haven't not found
    proper sequence for clean and full shutdown. So simply reset both
    SDMA block, this makes hibernation works reliably on sea island GPU
    family (CI)
    
    Hibernation and suspend to ram were tested (several times) on :
    Bonaire
    Hawaii
    Mullins
    Kaveri
    Kabini
    
    Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fabd533d1ff1df7796a2e5211cada6aa832c45c
Author: Jérôme Glisse <jglisse@redhat.com>
Date:   Fri Jun 19 10:32:15 2015 -0400

    drm/radeon: compute ring fix hibernation (CI GPU family) v2.
    
    commit 161569deaa03cf3c00ed63352006193f250b0648 upstream.
    
    In order for hibernation to reliably work we need to cleanup more
    thoroughly the compute ring. Hibernation is different from suspend
    resume as when we resume from hibernation the hardware is first
    fully initialize by regular kernel then freeze callback happens
    (which correspond to a suspend inside the radeon kernel driver)
    and turn off each of the block. It turns out we were not cleanly
    shutting down the compute ring. This patch fix that.
    
    Hibernation and suspend to ram were tested (several times) on :
    Bonaire
    Hawaii
    Mullins
    Kaveri
    Kabini
    
    Changed since v1:
      - Factor the ring stop logic into a function taking ring as arg.
    
    Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43c171f107d21d82ad8240bf8337d7ca56e27e0e
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri May 15 11:48:52 2015 -0400

    drm/radeon: take the mode_config mutex when dealing with hpds (v2)
    
    commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.
    
    Since we are messing with state in the worker.
    
    v2: drop the changes in the mst worker
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f8ddc25483278711e736dc062e4417fa87675b7
Author: Frediano Ziglio <fziglio@redhat.com>
Date:   Wed Jun 3 12:09:10 2015 +0100

    drm/qxl: Do not leak memory if qxl_release_list_add fails
    
    commit 8451cc964c1d193b989c41a44e5e77109cc696f8 upstream.
    
    If the function fails reference counter to the object is not decremented
    causing leaks.
    This is hard to spot as it happens only on very low memory situations.
    
    Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c476d1a03af7a1029557bd34481baf9dba1c4a2
Author: Frediano Ziglio <fziglio@redhat.com>
Date:   Wed Jun 3 12:09:09 2015 +0100

    drm/qxl: Do not cause spice-server to clean our objects
    
    commit 2fa19535ca6abcbfd1ccc9ef694db52f49f77747 upstream.
    
    If objects are moved back from system memory to VRAM (and spice id
    created again) memory is already initialized so we need to set flag
    to not clear memory.
    If you don't do it after a while using desktop many images turns to
    black or transparents.
    
    Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6a9311992221fd8252d1386608a4156d6e84c61
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Thu Jul 16 15:50:45 2015 +0200

    mmc: block: Add missing mmc_blk_put() in power_ro_lock_show()
    
    commit 9098f84cced870f54d8c410dd2444cfa61467fa0 upstream.
    
    Enclosing mmc_blk_put() is missing in power_ro_lock_show() sysfs handler,
    let's add it.
    
    Fixes: add710eaa886 ("mmc: boot partition ro lock support")
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a43be296d7a8b9069fc866bc2049769100c751c
Author: Joe Thornber <ejt@redhat.com>
Date:   Fri Jul 3 14:51:32 2015 +0100

    dm btree: silence lockdep lock inversion in dm_btree_del()
    
    commit 1c7518794a3647eb345d59ee52844e8a40405198 upstream.
    
    Allocate memory using GFP_NOIO when deleting a btree.  dm_btree_del()
    can be called via an ioctl and we don't want to recurse into the FS or
    block layer.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6a7ec379695715ca64acaf681a7a7c039a857ff
Author: Dennis Yang <shinrairis@gmail.com>
Date:   Fri Jun 26 15:25:48 2015 +0100

    dm btree remove: fix bug in redistribute3
    
    commit 4c7e309340ff85072e96f529582d159002c36734 upstream.
    
    redistribute3() shares entries out across 3 nodes.  Some entries were
    being moved the wrong way, breaking the ordering.  This manifested as a
    BUG() in dm-btree-remove.c:shift() when entries were removed from the
    btree.
    
    For additional context see:
    https://www.redhat.com/archives/dm-devel/2015-May/msg00113.html
    
    Signed-off-by: Dennis Yang <shinrairis@gmail.com>
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fa89d491b5854d69cfb5602acfb9d466cd22da2
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Jun 17 13:35:19 2015 +0100

    dm space map metadata: fix occasional leak of a metadata block on resize
    
    commit 6096d91af0b65a3967139b32d5adbb3647858a26 upstream.
    
    The metadata space map has a simplified 'bootstrap' mode that is
    operational when extending the space maps.  Whilst in this mode it's
    possible for some refcount decrement operations to become queued (eg, as
    a result of shadowing one of the bitmap indexes).  These decrements were
    not being applied when switching out of bootstrap mode.
    
    The effect of this bug was the leaking of a 4k metadata block.  This is
    detected by the latest version of thin_check as a non fatal error.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d90be37ead9f3a9a7a254e9eb8b56d7e82d3d0b5
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Jun 5 09:50:42 2015 -0400

    dm stats: fix divide by zero if 'number_of_areas' arg is zero
    
    commit dd4c1b7d0c95be1c9245118a3accc41a16f1db67 upstream.
    
    If the number_of_areas argument was zero the kernel would crash on
    div-by-zero.  Add better input validation.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d5feb50069fd51462440359c65aa27321f606eb
Author: AMAN DEEP <aman.deep@samsung.com>
Date:   Tue Jul 21 17:20:27 2015 +0300

    usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function
    
    commit 3496810663922617d4b706ef2780c279252ddd6a upstream.
    
    virt_dev->num_cached_rings counts on freed ring and is not updated
    correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring
    is added into cache and then num_rings_cache is incremented as below:
    		virt_dev->ring_cache[rings_cached] =
    			virt_dev->eps[ep_index].ring;
    		virt_dev->num_rings_cached++;
    here, free ring pointer is added to a current index and then
    index is incremented.
    So current index always points to empty location in the ring cache.
    For getting available free ring, current index should be decremented
    first and then corresponding ring buffer value should be taken from ring
    cache.
    
    But In function xhci_endpoint_init(), the num_rings_cached index is
    accessed before decrement.
    		virt_dev->eps[ep_index].new_ring =
    			virt_dev->ring_cache[virt_dev->num_rings_cached];
    		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
    		virt_dev->num_rings_cached--;
    This is bug in manipulating the index of ring cache.
    And it should be as below:
    		virt_dev->num_rings_cached--;
    		virt_dev->eps[ep_index].new_ring =
    			virt_dev->ring_cache[virt_dev->num_rings_cached];
    		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
    
    Signed-off-by: Aman Deep <aman.deep@samsung.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c3a55ae14f7cb4323be84dbb569d78d6b53ceb3
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date:   Wed Jul 8 17:26:37 2015 +0200

    USB: serial: Destroy serial_minors IDR on module exit
    
    commit d23f47d4927fd2f61b3a754d83c7bcec215b5cfe upstream.
    
    Destroy serial_minors IDR on module exit, reclaiming the allocated memory.
    
    This was detected by the following semantic patch (written by Luis
    Rodriguez <mcgrof@suse.com>)
    
    <SmPL>
    @ defines_module_init @
    declarer name module_init, module_exit;
    declarer name DEFINE_IDR;
    identifier init;
    @@
    
    module_init(init);
    
    @ defines_module_exit @
    identifier exit;
    @@
    
    module_exit(exit);
    
    @ declares_idr depends on defines_module_init && defines_module_exit @
    identifier idr;
    @@
    
    DEFINE_IDR(idr);
    
    @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
    identifier declares_idr.idr, defines_module_exit.exit;
    @@
    
    exit(void)
    {
     ...
     idr_destroy(&idr);
     ...
    }
    
    @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
    identifier declares_idr.idr, defines_module_exit.exit;
    @@
    
    exit(void)
    {
     ...
     +idr_destroy(&idr);
    }
    </SmPL>
    
    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3239e8b85c73ec7630641bc85341a3b0c4b58b8f
Author: Claudio Cappelli <claudio.cappelli.linux@gmail.com>
Date:   Wed Jun 10 20:38:30 2015 +0200

    USB: option: add 2020:4000 ID
    
    commit f6d7fb37f92622479ef6da604f27561f5045ba1e upstream.
    
    Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
    
    T:  Bus=01 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2020 ProdID=4000 Rev=03.00
    S:  Manufacturer=Network Connect
    S:  Product=MT6225
    C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    
    Signed-off-by: Claudio Cappelli <claudio.cappelli.linux@gmail.com>
    Suggested-by: Lars Melin <larsm17@gmail.com>
    [johan: amend commit message with devices info ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b63ea8bdc012be9820f98aa5a72ea9bc83564efa
Author: Peter Sanford <peter@sanford.io>
Date:   Thu Jun 25 17:40:05 2015 -0700

    USB: cp210x: add ID for Aruba Networks controllers
    
    commit f98a7aa81eeeadcad25665c3501c236d531d4382 upstream.
    
    Add the USB serial console device ID for Aruba Networks 7xxx series
    controllers which have a USB port for their serial console.
    
    Signed-off-by: Peter Sanford <peter@sanford.io>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26cbf8ea380a3e1ed1c22697c476e0576531d7a3
Author: Felipe Balbi <balbi@ti.com>
Date:   Tue Jun 2 13:03:36 2015 -0500

    usb: musb: host: rely on port_mode to call musb_start()
    
    commit be9d39881fc4fa39a64b6eed6bab5d9ee5125344 upstream.
    
    Currently, we're calling musb_start() twice for DRD ports
    in some situations. This has been observed to cause enumeration
    issues after suspend/resume cycles with AM335x.
    
    In order to fix the problem, we just have to fix the check
    on musb_has_gadget() so that it only returns true if
    current mode is Host and ignore the fact that we have or
    not a gadget driver loaded.
    
    Fixes: ae44df2e21b5 (usb: musb: call musb_start() only once in OTG mode)
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Sekhar Nori <nsekhar@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a2b2ec160c8b5565628b42230427fce1f03a7fe
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon May 18 15:29:51 2015 +0300

    USB: devio: fix a condition in async_completed()
    
    commit 83ed07c5db71bc02bd646d6eb60b48908235cdf9 upstream.
    
    Static checkers complain that the current condition is never true.  It
    seems pretty likely that it's a typo and "URB" was intended instead of
    "USB".
    
    Fixes: 3d97ff63f899 ('usbdevfs: Use scatter-gather lists for large bulk transfers')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aeb166d2ab291475eeda9a7b42ca9d78c5de38ce
Author: John Youn <John.Youn@synopsys.com>
Date:   Mon Sep 17 00:00:00 2001 -0700

    usb: dwc3: Reset the transfer resource index on SET_INTERFACE
    
    commit aebda618718157a69c0dc0adb978d69bc2b8723c upstream.
    
    This fixes an issue introduced in commit b23c843992b6 (usb: dwc3:
    gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would
    only use DEPSTARTCFG once per SetConfig.
    
    The trick is that we should use one DEPSTARTCFG per SetConfig *OR*
    SetInterface. SetInterface was completely missed from the original
    patch.
    
    This problem became aparent after commit 76e838c9f776 (usb: dwc3:
    gadget: return error if command sent to DEPCMD register fails)
    added checking of the return status of device endpoint commands.
    
    'Set Endpoint Transfer Resource' command was caught failing
    occasionally. This is because the Transfer Resource
    Index was not getting reset during a SET_INTERFACE request.
    
    Finally, to fix the issue, was we have to do is make sure that
    our start_config_issued flag gets reset whenever we receive a
    SetInterface request.
    
    To verify the problem (and its fix), all we have to do is run
    test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'.
    
    Tested-by: Huang Rui <ray.huang@amd.com>
    Tested-by: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
    Fixes: b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
    Signed-off-by: John Youn <johnyoun@synopsys.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfd5bab553dd52e1367c96e86965cbb345741bbe
Author: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Date:   Thu May 21 15:46:48 2015 +0530

    usb: dwc3: gadget: return error if command sent to DEPCMD register fails
    
    commit 76e838c9f7765f9a6205b4d558d75a66104bc60d upstream.
    
    We need to return error to caller if command is not sent to
    controller succesfully.
    
    Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
    Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver)
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35910b3c03c66d782a78f801c624319e0bb7a06b
Author: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Date:   Thu May 21 15:46:47 2015 +0530

    usb: dwc3: gadget: return error if command sent to DGCMD register fails
    
    commit 891b1dc022955d36cf4c0f42d383226a930db7ed upstream.
    
    We need to return error to caller if command is not sent to
    controller succesfully.
    
    Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
    Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support)
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67939728615c21de5c6eb6113a9374ea09eaaf75
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jul 8 13:06:12 2015 -0400

    libata: increase the timeout when setting transfer mode
    
    commit d531be2ca2f27cca5f041b6a140504999144a617 upstream.
    
    I have a ST4000DM000 disk. If Linux is booted while the disk is spun down,
    the command that sets transfer mode causes the disk to spin up. The
    spin-up takes longer than the default 5s timeout, so the command fails and
    timeout is reported.
    
    Fix this by increasing the timeout to 15s, which is enough for the disk to
    spin up.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5d5aeefc6425c3a440127087e52c4b925c01937
Author: Aleksei Mamlin <mamlinav@gmail.com>
Date:   Wed Jul 1 13:48:30 2015 +0300

    libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER
    
    commit 08c85d2a599d967ede38a847f5594447b6100642 upstream.
    
    Enabling AA on HP 250GB SATA disk VB0250EAVER causes errors:
    
    [    3.788362] ata3.00: failed to enable AA (error_mask=0x1)
    [    3.789243] ata3.00: failed to enable AA (error_mask=0x1)
    
    Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.
    
    tj: Collected FPDMA_AA entries and updated comment.
    
    Signed-off-by: Aleksei Mamlin <mamlinav@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e1fe1e8d2714355dbec58c5c7847d653edcdcd1
Author: Zidan Wang <zidan.wang@freescale.com>
Date:   Thu Jun 11 19:14:36 2015 +0800

    ASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1]
    
    commit a077e81ec61e07a7f86997d045109f06719fbffe upstream.
    
    the enum of "DAC Polarity" should be wm8960_enum[1].
    
    Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9600a7fe511c1008dc650b46522b54cdfc61bcd
Author: Axel Lin <axel.lin@ingics.com>
Date:   Mon May 11 09:04:06 2015 +0800

    ASoC: wm8903: Fix define for WM8903_VMID_RES_250K
    
    commit ebb6ad73e645b8f2d098dd3c41d2ff0da4146a02 upstream.
    
    VMID Control 0 BIT[2:1] is VMID Divider Enable and Select
    
    00 = VMID disabled (for OFF mode)
    01 = 2 x 50kΩ divider (for normal operation)
    10 = 2 x 250kΩ divider (for low power standby)
    11 = 2 x 5kΩ divider (for fast start-up)
    
    So WM8903_VMID_RES_250K should be 2 << 1, which is 4.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d919a4e6bb3cafadd0d0bd3925a19fd59c7e56d1
Author: Axel Lin <axel.lin@ingics.com>
Date:   Fri May 15 09:15:16 2015 +0800

    ASoC: wm8955: Fix setting wrong register for WM8955_K_8_0_MASK bits
    
    commit 12c350050538c7dc779c083b7342bfd20f74949c upstream.
    
    WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than
    WM8955_PLL_CONTROL_2.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d999ec5d6ee95a4ccc49773711b4715a69238ec
Author: Axel Lin <axel.lin@ingics.com>
Date:   Sun May 10 11:35:06 2015 +0800

    ASoC: wm8737: Fixup setting VMID Impedance control register
    
    commit 14ba3ec1de043260cecd9e828ea2e3a0ad302893 upstream.
    
    According to the datasheet:
    R10 (0Ah) VMID Impedance Control
    
    BIT 3:2 VMIDSEL DEFAULT 00
    
    DESCRIPTION: VMID impedance selection control
    00: 75kΩ output
    01: 300kΩ output
    10: 2.5kΩ output
    
    WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]),
    so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7beaa8501c791c477407661a70204ec82a0f1647
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jun 10 18:37:23 2015 +0300

    ASoC: imx-wm8962: Add a missing error check
    
    commit 474ff0ae23b834e9fc18374d14bb5f3e7b3828b4 upstream.
    
    My static checker complains that:
    
    	sound/soc/fsl/imx-wm8962.c:196 imx_wm8962_probe() warn:
    	we tested 'ret' before and it was 'false'
    
    The intent was that we use "ret" to check imx_audmux_v2_configure_port().
    
    Fixes: 8de2ae2a7f1f ('ASoC: fsl: add imx-wm8962 machine driver')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Otherwise, Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eca0a2cf644733c95999d55a26da371e01d18e15
Author: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date:   Thu May 28 14:28:12 2015 +0100

    ASoC: arizona: Fix noise generator gain TLV
    
    commit 15575ed544910464715df5c45a44b9732e415b93 upstream.
    
    The Arizona codec drivers had an incorrect dB scaling for the
    noise generator gain that started at 0dB and went upwards.
    Actually the highest setting is 0dB.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cceed3976af74c7565636f0dfbcd1fc6817dc5d
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Tue Apr 28 18:51:17 2015 -0300

    cx24116: fix a buffer overflow when checking userspace params
    
    commit 1fa2337a315a2448c5434f41e00d56b01a22283c upstream.
    
    The maximum size for a DiSEqC command is 6, according to the
    userspace API. However, the code allows to write up much more values:
    	drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37adcab9a6086c3e106b199cae969879edf8bb2f
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Tue Apr 28 18:34:40 2015 -0300

    s5h1420: fix a buffer overflow when checking userspace params
    
    commit 12f4543f5d6811f864e6c4952eb27253c7466c02 upstream.
    
    The maximum size for a DiSEqC command is 6, according to the
    userspace API. However, the code allows to write up to 7 values:
    	drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ed28d5811b12f986ffddee1d216e7a46e827dd2
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Tue Apr 28 19:02:19 2015 -0300

    af9013: Don't accept invalid bandwidth
    
    commit d7b76c91f471413de9ded837bddeca2164786571 upstream.
    
    If userspace sends an invalid bandwidth, it should either return
    EINVAL or switch to auto mode.
    
    This driver will go past an array and program the hardware on a
    wrong way if this happens.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b9bd62380a21ac2c52bf26109af17873fd1c08e
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Tue Apr 28 19:03:59 2015 -0300

    cx24117: fix a buffer overflow when checking userspace params
    
    commit 82e3b88b679049f043fe9b03991d6d66fc0a43c8 upstream.
    
    The maximum size for a DiSEqC command is 6, according to the
    userspace API. However, the code allows to write up much more values:
    	drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83a863f62a104209eb90fc1517011ac86d44ae05
Author: Jan Leupold <leupold@rsi-elektrotechnik.de>
Date:   Wed Jun 17 18:21:36 2015 +0200

    iio: adc: at91_adc: allow to use full range of startup time
    
    commit 2ab5f39bc7825808e0fa1e7e5f0b23e174563467 upstream.
    
    The DT-Property "atmel,adc-startup-time" is stored in an u8 for a microsecond
    value. When trying to increase the value of STARTUP in Register AT91_ADC_MR
    some higher values can't be reached.
    
    Change the type in function parameter and private structure field from u8 to
    u32.
    
    Signed-off-by: Jan Leupold <leupold@rsi-elektrotechnik.de>
    [nicolas.ferre@atmel.com: change commit message, increase u16 to u32 for startup time]
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58bf2ffd79c6f3bdc6ffd051bfdda702dd3d6ee7
Author: Peter Meerwald <pmeerw@pmeerw.net>
Date:   Sun Jun 21 23:50:21 2015 +0200

    iio: tmp006: Check channel info on write
    
    commit 8d05abfaeff52bdf66aba3a3a337dcdbdb4911bf upstream.
    
    only SAMP_FREQ is writable
    
    Will lead to SAMP_FREQ being written by any attempt to write
    to the other exported attributes and hence a rather unexpected
    result!
    
    Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f755f06a8b65d05eb608a243035febfc3134140b
Author: JM Friedt <jmfriedt@femto-st.fr>
Date:   Fri Jun 19 14:48:06 2015 +0200

    iio: DAC: ad5624r_spi: fix bit shift of output data value
    
    commit adfa969850ae93beca57f7527f0e4dc10cbe1309 upstream.
    
    The value sent on the SPI bus is shifted by an erroneous number of bits.
    The shift value was already computed in the iio_chan_spec structure and
    hence subtracting this argument to 16 yields an erroneous data position
    in the SPI stream.
    
    Signed-off-by: JM Friedt <jmfriedt@femto-st.fr>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1d34ce4a8c3ea7a84ff725fb597eac6831080f9
Author: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date:   Tue Jun 9 18:22:14 2015 +0200

    i2c: at91: fix a race condition when using the DMA controller
    
    commit 93563a6a71bb69dd324fc7354c60fb05f84aae6b upstream.
    
    For TX transactions, the TXCOMP bit in the Status Register is cleared
    when the first data is written into the Transmit Holding Register.
    
    In the lines from at91_do_twi_transfer():
    at91_twi_write_data_dma(dev);
    at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);
    
    the TXCOMP interrupt may be enabled before the DMA controller has
    actually started to write into the THR. In such a case, the TXCOMP bit
    is still set into the Status Register so the interrupt is triggered
    immediately. The driver understands that a transaction completion has
    occurred but this transaction hasn't started yet. Hence the TXCOMP
    interrupt is no longer enabled by at91_do_twi_transfer() but instead
    by at91_twi_write_data_dma_callback().
    
    Also, the TXCOMP bit in the Status Register in not a clear on read flag
    but a snapshot of the transmission state at the time the Status
    Register is read.
    When a NACK error is dectected by the I2C controller, the TXCOMP, NACK
    and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP
    interrupt is triggered at the same time. Also setting the TXRDY to 1
    triggers the DMA controller to write the next data into the THR. Such
    a write resets the TXCOMP bit to 0 in the SR. So depending on when the
    interrupt handler reads the SR, it may fail to detect the NACK error
    if it relies on the TXCOMP bit. The NACK bit and its interrupt should
    be used instead.
    
    For RX transactions, the TXCOMP bit in the Status Register is cleared
    when the START bit is set into the Control Register. However to unify
    the management of the TXCOMP bit when the DMA controller is used, the
    TXCOMP interrupt is now enabled by the DMA callbacks for both TX and
    RX transfers.
    
    Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77be71cc3830c3e3d310fa722e996d8ea3046812
Author: Joseph Qi <joseph.qi@huawei.com>
Date:   Mon Jun 15 14:36:01 2015 -0400

    jbd2: fix ocfs2 corrupt when updating journal superblock fails
    
    commit 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a upstream.
    
    If updating journal superblock fails after journal data has been
    flushed, the error is omitted and this will mislead the caller as a
    normal case.  In ocfs2, the checkpoint will be treated successfully
    and the other node can get the lock to update. Since the sb_start is
    still pointing to the old log block, it will rewrite the journal data
    during journal recovery by the other node. Thus the new updates will
    be overwritten and ocfs2 corrupts.  So in above case we have to return
    the error, and ocfs2_commit_cache will take care of the error and
    prevent the other node to do update first.  And only after recovering
    journal it can do the new updates.
    
    The issue discussion mail can be found at:
    https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html
    http://comments.gmane.org/gmane.comp.file-systems.ext4/48841
    
    [ Fixed bug in patch which allowed a non-negative error return from
      jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this
      was causing xfstests ext4/306 to fail. -- Ted ]
    
    Reported-by: Yiwen Jiang <jiangyiwen@huawei.com>
    Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Tested-by: Yiwen Jiang <jiangyiwen@huawei.com>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 204d0acc29bae9b82ca4e31d65f3d2f56038a4de
Author: Dmitry Monakhov <dmonakhov@openvz.org>
Date:   Mon Jun 15 00:18:02 2015 -0400

    jbd2: use GFP_NOFS in jbd2_cleanup_journal_tail()
    
    commit b4f1afcd068f6e533230dfed00782cd8a907f96b upstream.
    
    jbd2_cleanup_journal_tail() can be invoked by jbd2__journal_start()
    So allocations should be done with GFP_NOFS
    
    [Full stack trace snipped from 3.10-rh7]
    [<ffffffff815c4bd4>] dump_stack+0x19/0x1b
    [<ffffffff8105dba1>] warn_slowpath_common+0x61/0x80
    [<ffffffff8105dcca>] warn_slowpath_null+0x1a/0x20
    [<ffffffff815c2142>] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17
    [<ffffffff8119c045>] kmem_cache_alloc+0x55/0x210
    [<ffffffff811477f5>] ? mempool_alloc_slab+0x15/0x20
    [<ffffffff811477f5>] mempool_alloc_slab+0x15/0x20
    [<ffffffff81147939>] mempool_alloc+0x69/0x170
    [<ffffffff815cb69e>] ? _raw_spin_unlock_irq+0xe/0x20
    [<ffffffff8109160d>] ? finish_task_switch+0x5d/0x150
    [<ffffffff811f1a8e>] bio_alloc_bioset+0x1be/0x2e0
    [<ffffffff8127ee49>] blkdev_issue_flush+0x99/0x120
    [<ffffffffa019a733>] jbd2_cleanup_journal_tail+0x93/0xa0 [jbd2] -->GFP_KERNEL
    [<ffffffffa019aca1>] jbd2_log_do_checkpoint+0x221/0x4a0 [jbd2]
    [<ffffffffa019afc7>] __jbd2_log_wait_for_space+0xa7/0x1e0 [jbd2]
    [<ffffffffa01952d8>] start_this_handle+0x2d8/0x550 [jbd2]
    [<ffffffff811b02a9>] ? __memcg_kmem_put_cache+0x29/0x30
    [<ffffffff8119c120>] ? kmem_cache_alloc+0x130/0x210
    [<ffffffffa019573a>] jbd2__journal_start+0xba/0x190 [jbd2]
    [<ffffffff811532ce>] ? lru_cache_add+0xe/0x10
    [<ffffffffa01c9549>] ? ext4_da_write_begin+0xf9/0x330 [ext4]
    [<ffffffffa01f2c77>] __ext4_journal_start_sb+0x77/0x160 [ext4]
    [<ffffffffa01c9549>] ext4_da_write_begin+0xf9/0x330 [ext4]
    [<ffffffff811446ec>] generic_file_buffered_write_iter+0x10c/0x270
    [<ffffffff81146918>] __generic_file_write_iter+0x178/0x390
    [<ffffffff81146c6b>] __generic_file_aio_write+0x8b/0xb0
    [<ffffffff81146ced>] generic_file_aio_write+0x5d/0xc0
    [<ffffffffa01bf289>] ext4_file_write+0xa9/0x450 [ext4]
    [<ffffffff811c31d9>] ? pipe_read+0x379/0x4f0
    [<ffffffff811b93f0>] do_sync_write+0x90/0xe0
    [<ffffffff811b9b6d>] vfs_write+0xbd/0x1e0
    [<ffffffff811ba5b8>] SyS_write+0x58/0xb0
    [<ffffffff815d4799>] system_call_fastpath+0x16/0x1b
    
    Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b768cfd04269c8224ef9899cd5bff9bdcfc4b2c4
Author: Michal Hocko <mhocko@suse.cz>
Date:   Sun Jul 5 12:33:44 2015 -0400

    ext4: replace open coded nofail allocation in ext4_free_blocks()
    
    commit 7444a072c387a93ebee7066e8aee776954ab0e41 upstream.
    
    ext4_free_blocks is looping around the allocation request and mimics
    __GFP_NOFAIL behavior without any allocation fallback strategy. Let's
    remove the open coded loop and replace it with __GFP_NOFAIL. Without the
    flag the allocator has no way to find out never-fail requirement and
    cannot help in any way.
    
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b77d9a0f566ebc43ff32d5f2fa1b7923ddf0cbff
Author: Eryu Guan <guaneryu@gmail.com>
Date:   Sat Jul 4 00:03:44 2015 -0400

    ext4: correctly migrate a file with a hole at the beginning
    
    commit 8974fec7d72e3e02752fe0f27b4c3719c78d9a15 upstream.
    
    Currently ext4_ind_migrate() doesn't correctly handle a file which
    contains a hole at the beginning of the file.  This caused the migration
    to be done incorrectly, and then if there is a subsequent following
    delayed allocation write to the "hole", this would reclaim the same data
    blocks again and results in fs corruption.
    
      # assmuing 4k block size ext4, with delalloc enabled
      # skip the first block and write to the second block
      xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/ext4/testfile
    
      # converting to indirect-mapped file, which would move the data blocks
      # to the beginning of the file, but extent status cache still marks
      # that region as a hole
      chattr -e /mnt/ext4/testfile
    
      # delayed allocation writes to the "hole", reclaim the same data block
      # again, results in i_blocks corruption
      xfs_io -c "pwrite 0 4k" /mnt/ext4/testfile
      umount /mnt/ext4
      e2fsck -nf /dev/sda6
      ...
      Inode 53, i_blocks is 16, should be 8.  Fix? no
      ...
    
    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 054f1c39fdd689d01a61148fd5011bf5492cc399
Author: Eryu Guan <guaneryu@gmail.com>
Date:   Fri Jul 3 23:56:50 2015 -0400

    ext4: be more strict when migrating to non-extent based file
    
    commit d6f123a9297496ad0b6335fe881504c4b5b2a5e5 upstream.
    
    Currently the check in ext4_ind_migrate() is not enough before doing the
    real conversion:
    
    a) delayed allocated extents could bypass the check on eh->eh_entries
       and eh->eh_depth
    
    This can be demonstrated by this script
    
      xfs_io -fc "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/ext4/testfile
      chattr -e /mnt/ext4/testfile
    
    where testfile has two extents but still be converted to non-extent
    based file format.
    
    b) only extent length is checked but not the offset, which would result
       in data lose (delalloc) or fs corruption (nodelalloc), because
       non-extent based file only supports at most (12 + 2^10 + 2^20 + 2^30)
       blocks
    
    This can be demostrated by
    
      xfs_io -fc "pwrite 5T 4k" /mnt/ext4/testfile
      chattr -e /mnt/ext4/testfile
      sync
    
    If delalloc is enabled, dmesg prints
      EXT4-fs warning (device dm-4): ext4_block_to_path:105: block 1342177280 > max in inode 53
      EXT4-fs (dm-4): Delayed block allocation failed for inode 53 at logical offset 1342177280 with max blocks 1 with error 5
      EXT4-fs (dm-4): This should not happen!! Data will be lost
    
    If delalloc is disabled, e2fsck -nf shows corruption
      Inode 53, i_size is 5497558142976, should be 4096.  Fix? no
    
    Fix the two issues by
    
    a) forcing all delayed allocation blocks to be allocated before checking
       eh->eh_depth and eh->eh_entries
    b) limiting the last logical block of the extent is within direct map
    
    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3959e2a62f63cacb28f88d933bc3d009d6084c38
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Fri Jul 3 21:13:55 2015 -0400

    ext4: fix reservation release on invalidatepage for delalloc fs
    
    commit 9705acd63b125dee8b15c705216d7186daea4625 upstream.
    
    On delalloc enabled file system on invalidatepage operation
    in ext4_da_page_release_reservation() we want to clear the delayed
    buffer and remove the extent covering the delayed buffer from the extent
    status tree.
    
    However currently there is a bug where on the systems with page size >
    block size we will always remove extents from the start of the page
    regardless where the actual delayed buffers are positioned in the page.
    This leads to the errors like this:
    
    EXT4-fs warning (device loop0): ext4_da_release_space:1225:
    ext4_da_release_space: ino 13, to_free 1 with only 0 reserved data
    blocks
    
    This however can cause data loss on writeback time if the file system is
    in ENOSPC condition because we're releasing reservation for someones
    else delayed buffer.
    
    Fix this by only removing extents that corresponds to the part of the
    page we want to invalidate.
    
    This problem is reproducible by the following fio receipt (however I was
    only able to reproduce it with fio-2.1 or older.
    
    [global]
    bs=8k
    iodepth=1024
    iodepth_batch=60
    randrepeat=1
    size=1m
    directory=/mnt/test
    numjobs=20
    [job1]
    ioengine=sync
    bs=1k
    direct=1
    rw=randread
    filename=file1:file2
    [job2]
    ioengine=libaio
    rw=randwrite
    direct=1
    filename=file1:file2
    [job3]
    bs=1k
    ioengine=posixaio
    rw=randwrite
    direct=1
    filename=file1:file2
    [job5]
    bs=1k
    ioengine=sync
    rw=randread
    filename=file1:file2
    [job7]
    ioengine=libaio
    rw=randwrite
    filename=file1:file2
    [job8]
    ioengine=posixaio
    rw=randwrite
    filename=file1:file2
    [job10]
    ioengine=mmap
    rw=randwrite
    bs=1k
    filename=file1:file2
    [job11]
    ioengine=mmap
    rw=randwrite
    direct=1
    filename=file1:file2
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e35e467d628a658fbd9a58d6d7d8b5d9f3f8850
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Sun Jun 21 21:10:51 2015 -0400

    ext4: don't retry file block mapping on bigalloc fs with non-extent file
    
    commit 292db1bc6c105d86111e858859456bcb11f90f91 upstream.
    
    ext4 isn't willing to map clusters to a non-extent file.  Don't signal
    this with an out of space error, since the FS will retry the
    allocation (which didn't fail) forever.  Instead, return EUCLEAN so
    that the operation will fail immediately all the way back to userspace.
    
    (The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.)
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0899d250540c251826aecae283b2815ac4647db
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Jun 20 22:50:33 2015 -0400

    ext4: call sync_blockdev() before invalidate_bdev() in put_super()
    
    commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream.
    
    Normally all of the buffers will have been forced out to disk before
    we call invalidate_bdev(), but there will be some cases, where a file
    system operation was aborted due to an ext4_error(), where there may
    still be some dirty buffers in the buffer cache for the device.  So
    try to force them out to memory before calling invalidate_bdev().
    
    This fixes a warning triggered by generic/081:
    
    WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 __blkdev_put+0xb5/0x16f()
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fb9ff99feb58aa3de4a6e862401528f72b19ef3
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Jun 12 23:45:33 2015 -0400

    ext4: fix race between truncate and __ext4_journalled_writepage()
    
    commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e upstream.
    
    The commit cf108bca465d: "ext4: Invert the locking order of page_lock
    and transaction start" caused __ext4_journalled_writepage() to drop
    the page lock before the page was written back, as part of changing
    the locking order to jbd2_journal_start -> page_lock.  However, this
    introduced a potential race if there was a truncate racing with the
    data=journalled writeback mode.
    
    Fix this by grabbing the page lock after starting the journal handle,
    and then checking to see if page had gotten truncated out from under
    us.
    
    This fixes a number of different warnings or BUG_ON's when running
    xfstests generic/086 in data=journalled mode, including:
    
    jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7
    c0, 164), jh->b_transaction (  (null), 0), jh->b_next_transaction (  (null), 0), jlist 0
    
    	      	      	  - and -
    
    kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200!
        ...
    Call Trace:
     [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
     [<c02b2de5>] __ext4_journalled_invalidatepage+0x10f/0x117
     [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
     [<c027d883>] ? lock_buffer+0x36/0x36
     [<c02b2dfa>] ext4_journalled_invalidatepage+0xd/0x22
     [<c0229139>] do_invalidatepage+0x22/0x26
     [<c0229198>] truncate_inode_page+0x5b/0x85
     [<c022934b>] truncate_inode_pages_range+0x156/0x38c
     [<c0229592>] truncate_inode_pages+0x11/0x15
     [<c022962d>] truncate_pagecache+0x55/0x71
     [<c02b913b>] ext4_setattr+0x4a9/0x560
     [<c01ca542>] ? current_kernel_time+0x10/0x44
     [<c026c4d8>] notify_change+0x1c7/0x2be
     [<c0256a00>] do_truncate+0x65/0x85
     [<c0226f31>] ? file_ra_state_init+0x12/0x29
    
    	      	      	  - and -
    
    WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396
    irty_metadata+0x14a/0x1ae()
        ...
    Call Trace:
     [<c01b879f>] ? console_unlock+0x3a1/0x3ce
     [<c082cbb4>] dump_stack+0x48/0x60
     [<c0178b65>] warn_slowpath_common+0x89/0xa0
     [<c02ef2cf>] ? jbd2_journal_dirty_metadata+0x14a/0x1ae
     [<c0178bef>] warn_slowpath_null+0x14/0x18
     [<c02ef2cf>] jbd2_journal_dirty_metadata+0x14a/0x1ae
     [<c02d8615>] __ext4_handle_dirty_metadata+0xd4/0x19d
     [<c02b2f44>] write_end_fn+0x40/0x53
     [<c02b4a16>] ext4_walk_page_buffers+0x4e/0x6a
     [<c02b59e7>] ext4_writepage+0x354/0x3b8
     [<c02b2f04>] ? mpage_release_unused_pages+0xd4/0xd4
     [<c02b1b21>] ? wait_on_buffer+0x2c/0x2c
     [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
     [<c02b5a5b>] __writepage+0x10/0x2e
     [<c0225956>] write_cache_pages+0x22d/0x32c
     [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
     [<c02b6ee8>] ext4_writepages+0x102/0x607
     [<c019adfe>] ? sched_clock_local+0x10/0x10e
     [<c01a8a7c>] ? __lock_is_held+0x2e/0x44
     [<c01a8ad5>] ? lock_is_held+0x43/0x51
     [<c0226dff>] do_writepages+0x1c/0x29
     [<c0276bed>] __writeback_single_inode+0xc3/0x545
     [<c0277c07>] writeback_sb_inodes+0x21f/0x36d
        ...
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92bb60fedef6b17c0b586ac5250734f14ab28289
Author: Haggai Eran <haggai.eran@gmail.com>
Date:   Sat May 23 23:13:51 2015 +0300

    staging: rtl8712: prevent buffer overrun in recvbuf2recvframe
    
    commit cab462140f8a183e3cca0b51c8b59ef715cb6148 upstream.
    
    With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
    packet are set, but the packet length is too large. Allocate enough
    space to prevent memory corruption and a resulting kernel panic [1].
    
    [1] http://www.spinics.net/lists/linux-wireless/msg136546.html
    
    Signed-off-by: Haggai Eran <haggai.eran@gmail.com>
    ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4f773f7de5fdcc6e8675d2a014b012e05d41cab
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Jun 2 10:38:32 2015 +0200

    ath9k: fix DMA stop sequence for AR9003+
    
    commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream.
    
    AR93xx and newer needs to stop rx before tx to avoid getting the DMA
    engine or MAC into a stuck state.
    This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e62a2b95518eb7d45f646b2f3d73978811b0874
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Sun Jun 7 09:42:19 2015 +0200

    Bluetooth: btusb: Fix memory leak in Intel setup routine
    
    commit ecffc80478cdce122f0ecb6a4e4f909132dd5c47 upstream.
    
    The SKB returned from the Intel specific version information command is
    missing a kfree_skb.
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d486560ebb5873ee361f456032700fe3f06ec66
Author: Boris BREZILLON <b.brezillon.dev@gmail.com>
Date:   Sat Feb 1 19:10:28 2014 +0100

    mtd: nand: fix erroneous read_buf call in nand_write_page_raw_syndrome
    
    commit 60c3bc1fd6f1fa40b415ef5b83e2948a89a3d79c upstream.
    
    read_buf is called in place of write_buf in the
    nand_write_page_raw_syndrome function.
    
    Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Cc: Mason <slash.tmp@free.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bbc02f4c7186fea8fabc3c85cec3793ee6d4a36
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Fri Nov 29 22:04:28 2013 -0800

    mtd: nand: don't use read_buf for 8-bit ONFI transfers
    
    commit bd9c6e99b58255b9de1982711ac9487c9a2f18be upstream.
    
    Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
    devices, we need to avoid the upper I/O[16:9] bits. See the following
    commit for reference:
    
    commit 05f7835975dad6b3b517f9e23415985e648fb875
    Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Date:   Thu Dec 5 22:22:04 2013 +0100
    
        mtd: nand: don't use {read,write}_buf for 8-bit transfers
    
    Now, I think that all barriers to probing ONFI on x16 devices are
    removed, so remove the check from nand_flash_detect_onfi().
    
    Tested on 8-bit ONFI NAND (Micron MT29F32G08CBADAWP).
    
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
    Tested-By: Pekon Gupta <pekon@ti.com>
    Cc: Mason <slash.tmp@free.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78c07a4d10f6f45037d15e2e844289c9c47f9bd0
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue Jun 9 18:46:58 2015 +0200

    pinctrl: mvebu: armada-xp: fix functions of MPP48
    
    commit ea78b9511a54d0de026e04b5da86b30515072f31 upstream.
    
    There was a mistake in the definition of the functions for MPP48 on
    Marvell Armada XP. The second function is dev(clkout), and not tclk.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 568ec6ffda6b693e6325ec4a1a5eb9348fb980e0
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue Jun 9 18:46:57 2015 +0200

    pinctrl: mvebu: armada-xp: remove non-existing VDD cpu_pd functions
    
    commit 80b3d04feab5e69d51cb2375eb989a7165e43e3b upstream.
    
    The latest version of the Armada XP datasheet no longer documents the
    VDD cpu_pd functions, which might indicate they are not working and/or
    not supported. This commit ensures the pinctrl driver matches the
    datasheet.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 517e6f3680dd306932a3e741b3406707235620c1
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue Jun 9 18:46:56 2015 +0200

    pinctrl: mvebu: armada-xp: remove non-existing NAND pins
    
    commit bc99357f3690c11817756adfee0ece811a3db2e7 upstream.
    
    After updating to a more recent version of the Armada XP datasheet, we
    realized that some of the pins documented as having a NAND-related
    functionality in fact did not have such functionality. This commit
    updates the pinctrl driver accordingly.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Fixes: 463e270f766a ("pinctrl: mvebu: add pinctrl driver for Armada XP")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61ceacfe0acde223db89102673e4bf1ecb655d77
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue Jun 9 18:46:54 2015 +0200

    pinctrl: mvebu: armada-370: fix spi0 pin description
    
    commit 438881dfddb9107ef0eb30b49368e91e092f0b3e upstream.
    
    Due to a mistake, the CS0 and CS1 SPI0 functions were incorrectly
    named "spi0-1" instead of just "spi0". This commit fixes that.
    
    This DT binding change does not affect any of the in-tree users.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Fixes: 5f597bb2be57 ("pinctrl: mvebu: add pinctrl driver for Armada 370")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87fe76cf55e7bd5be13ba50094fdac0b6547b65d
Author: Lukasz Majewski <l.majewski@samsung.com>
Date:   Wed Sep 24 10:27:10 2014 +0200

    thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
    
    commit 26bb0e9a1a938ec98ee07aa76533f1a711fba706 upstream.
    
    It turns out that some boards can have instance->lower greater than 0 and
    when thermal trend is dropping it results with next_target equal to -1.
    
    Since the next_target is defined as unsigned long it is interpreted as
    0xFFFFFFFF and larger than instance->upper.
    As a result the next_target is set to instance->upper which ramps up to
    maximal cooling device target when the temperature is steadily decreasing.
    
    Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Cc: Mason <slash.tmp@free.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b35e24e866fd5456fec99277a80c4d7622941f1
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu May 28 10:22:10 2015 +0200

    mtd: dc21285: use raw spinlock functions for nw_gpio_lock
    
    commit e5babdf928e5d0c432a8d4b99f20421ce14d1ab6 upstream.
    
    Since commit bd31b85960a7 (which is in 3.2-rc1) nw_gpio_lock is a raw spinlock
    that needs usage of the corresponding raw functions.
    
    This fixes:
    
      drivers/mtd/maps/dc21285.c: In function 'nw_en_write':
      drivers/mtd/maps/dc21285.c:41:340: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type
        spin_lock_irqsave(&nw_gpio_lock, flags);
    
      In file included from include/linux/seqlock.h:35:0,
                       from include/linux/time.h:5,
                       from include/linux/stat.h:18,
                       from include/linux/module.h:10,
                       from drivers/mtd/maps/dc21285.c:8:
      include/linux/spinlock.h:299:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
       static inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
                                                                                                            ^
      drivers/mtd/maps/dc21285.c:43:25: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type
        spin_unlock_irqrestore(&nw_gpio_lock, flags);
                               ^
      In file included from include/linux/seqlock.h:35:0,
                       from include/linux/time.h:5,
                       from include/linux/stat.h:18,
                       from include/linux/module.h:10,
                       from drivers/mtd/maps/dc21285.c:8:
      include/linux/spinlock.h:370:91: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
       static inline void spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
    
    Fixes: bd31b85960a7 ("locking, ARM: Annotate low level hw locks as raw")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b545c420061ce9e0dc4d19bf1a5f7f14b2bf3809
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Thu May 7 17:55:16 2015 -0700

    mtd: fix: avoid race condition when accessing mtd->usecount
    
    commit 073db4a51ee43ccb827f54a4261c0583b028d5ab upstream.
    
    On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to
    mtd->usecount were done without taking mtd_table_mutex.
    kernel: Call Trace:
    kernel: [<ffffffff80401818>] __put_mtd_device+0x20/0x50
    kernel: [<ffffffff804086f4>] blktrans_release+0x8c/0xd8
    kernel: [<ffffffff802577e0>] __blkdev_put+0x1a8/0x200
    kernel: [<ffffffff802579a4>] blkdev_close+0x1c/0x30
    kernel: [<ffffffff8022006c>] __fput+0xac/0x250
    kernel: [<ffffffff80171208>] task_work_run+0xd8/0x120
    kernel: [<ffffffff8012c23c>] work_notifysig+0x10/0x18
    kernel:
    kernel:
            Code: 2442ffff  ac8202d8  000217fe <00020336> dc820128  10400003
                   00000000  0040f809  00000000
    kernel: ---[ end trace 080fbb4579b47a73 ]---
    
    Fixed by taking the mutex in blktrans_open and blktrans_release.
    
    Note that this locking is already suggested in
    include/linux/mtd/blktrans.h:
    
    struct mtd_blktrans_ops {
    ...
    	/* Called with mtd_table_mutex held; no race with add/remove */
    	int (*open)(struct mtd_blktrans_dev *dev);
    	void (*release)(struct mtd_blktrans_dev *dev);
    ...
    };
    
    But we weren't following it.
    
    Originally reported by (and patched by) Zhang and Giuseppe,
    independently. Improved and rewritten.
    
    Reported-by: Zhang Xingcai <zhangxingcai@huawei.com>
    Reported-by: Giuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com>
    Tested-by: Giuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7fef973f424d06d0dad557ab14fb29cc601a233
Author: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Date:   Fri Apr 24 14:57:10 2015 +0300

    leds / PM: fix hibernation on arm when gpio-led used with CPU led trigger
    
    commit 084609bf727981c7a2e6e69aefe0052c9d793300 upstream.
    
    Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of
    hibernation callbacks means those pm functions will not be
    called upon hibernation - that leads to system crash on ARM during
    freezing if gpio-led is used in combination with CPU led trigger.
    It may happen after freeze_noirq stage (GPIO is suspended)
    and before syscore_suspend stage (CPU led trigger is suspended)
    - usually when disable_nonboot_cpus() is called.
    
    Log:
      PM: noirq freeze of devices complete after 1.425 msecs
      Disabling non-boot CPUs ...
        ^ system may crash or stuck here with message (TI AM572x)
    
      WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370()
      44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
    
      CPU1: shutdown
        ^ or here
    
    Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
    assigns the suspend and hibernation callbacks and move
    led_suspend/led_resume under CONFIG_PM_SLEEP to avoid
    build warnings.
    
    Fixes: 73e1ab41a80d (leds: Convert led class driver from legacy pm ops to dev_pm_ops)
    Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
    Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6281994e0aa3fdc91a81922cf4878af9b9914498
Author: Axel Lin <axel.lin@ingics.com>
Date:   Mon May 11 17:02:58 2015 +0800

    genirq: devres: Fix testing return value of request_any_context_irq()
    
    commit 63781394c540dd9e666a6b21d70b64dd52bce76e upstream.
    
    request_any_context_irq() returns a negative value on failure.
    It returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success.
    So fix testing return value of request_any_context_irq().
    
    Also fixup the return value of devm_request_any_context_irq() to make it
    consistent with request_any_context_irq().
    
    Fixes: 0668d3065128 ("genirq: Add devm_request_any_context_irq()")
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
    Link: http://lkml.kernel.org/r/1431334978.17783.4.camel@ingics.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84c90ff24c66c83a680a6161c3d36dcad080b002
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Mon May 18 13:22:44 2015 +0200

    scsi_transport_srp: Fix a race condition
    
    commit 535fb906225fb7436cb658144d0c0cea14a26f3e upstream.
    
    Avoid that srp_terminate_io() can get invoked while srp_queuecommand()
    is in progress. This patch avoids that an I/O timeout can trigger the
    following kernel warning:
    
    WARNING: at drivers/infiniband/ulp/srp/ib_srp.c:1447 srp_terminate_io+0xef/0x100 [ib_srp]()
    Call Trace:
     [<ffffffff814c65a2>] dump_stack+0x4e/0x68
     [<ffffffff81051f71>] warn_slowpath_common+0x81/0xa0
     [<ffffffff8105204a>] warn_slowpath_null+0x1a/0x20
     [<ffffffffa075f51f>] srp_terminate_io+0xef/0x100 [ib_srp]
     [<ffffffffa07495da>] __rport_fail_io_fast+0xba/0xc0 [scsi_transport_srp]
     [<ffffffffa0749a90>] rport_fast_io_fail_timedout+0xe0/0xf0 [scsi_transport_srp]
     [<ffffffff8106e09b>] process_one_work+0x1db/0x780
     [<ffffffff8106e75b>] worker_thread+0x11b/0x450
     [<ffffffff81073c64>] kthread+0xe4/0x100
     [<ffffffff814cf26c>] ret_from_fork+0x7c/0xb0
    
    See also patch "scsi_transport_srp: Add transport layer error
    handling" (commit ID 29c17324803c).
    
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: James Bottomley <JBottomley@Odin.com>
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28b2106e7def74bd4e9ec90d8ea328497d889332
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Mon May 18 13:22:19 2015 +0200

    scsi_transport_srp: Introduce srp_wait_for_queuecommand()
    
    commit be34c62ddf39d1931780b07a6f4241393e4ba2ee upstream.
    
    Introduce the helper function srp_wait_for_queuecommand().
    Move the definition of scsi_request_fn_active(). Add a comment
    above srp_wait_for_queuecommand() that support for scsi-mq needs
    to be added.
    
    This patch does not change any functionality. A second call to
    srp_wait_for_queuecommand() will be introduced in the next patch.
    
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: James Bottomley <JBottomley@Odin.com>
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a11aebf2b40f0c0f2d5c59d2cf09bc60574fcb6c
Author: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Date:   Mon May 11 12:20:18 2015 -0300

    spi: pl022: Specify 'num-cs' property as required in devicetree binding
    
    commit ea6055c46eda1e19e02209814955e13f334bbe1b upstream.
    
    Since commit 39a6ac11df65 ("spi/pl022: Devicetree support w/o platform data")
    the 'num-cs' parameter cannot be passed through platform data when probing
    with devicetree. Instead, it's a required devicetree property.
    
    Fix the binding documentation so the property is properly specified.
    
    Fixes: 39a6ac11df65 ("spi/pl022: Devicetree support w/o platform data")
    Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b36a9870ef91864268f016c2cf95e85cd5c60144
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sun May 10 07:50:45 2015 +0000

    spi: fix race freeing dummy_tx/rx before it is unmapped
    
    commit 8e76ef88f607174082023f50b87fe12dcdbe5db5 upstream.
    
    Fix a race (with some kernel configurations) where a queued
    master->pump_messages runs and frees dummy_tx/rx before
    spi_unmap_msg is running (or is finished).
    
    This results in the following messages:
      BUG: Bad page state in process
      page:db7ba030 count:0 mapcount:0 mapping:  (null) index:0x0
      flags: 0x200(arch_1)
      page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
      ...
    
    Reported-by: Noralf Trønnes <noralf@tronnes.org>
    Suggested-by: Noralf Trønnes <noralf@tronnes.org>
    Tested-by: Noralf Trønnes <noralf@tronnes.org>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 073db8d52c821214ff5bfff429ddf166e2bca94f
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Tue Jun 9 20:09:42 2015 +0000

    regulator: core: fix constraints output buffer
    
    commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf upstream.
    
    The buffer for condtraints debug isn't big enough to hold the output
    in all cases. So fix this issue by increasing the buffer.
    
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b6a5a1b62b2e610e4cf934070b869f8e2da6347
Author: Maxime Coquelin <maxime.coquelin@st.com>
Date:   Tue Jun 16 13:53:19 2015 +0200

    regmap: Fix possible shift overflow in regmap_field_init()
    
    commit 921cc29473a0d7c109105c1876ddb432f4a4be7d upstream.
    
    The way the mask is generated in regmap_field_init() is wrong.
    Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
    overflow while calculating the mask field.
    
    On some 32 bits architectures, such as x86, the generated mask is 0,
    instead of the expected 0xffffffff.
    
    This patch uses GENMASK() to fix the problem, as this macro is already safe
    regarding shift overflow.
    
    Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97e83aca6ed024ddeb15d04696a40fa694a3e445
Author: Arun Chandran <achandran@mvista.com>
Date:   Mon Jun 15 15:59:02 2015 +0530

    regmap: Fix regmap_bulk_read in BE mode
    
    commit 15b8d2c41fe5839582029f65c5f7004db451cc2b upstream.
    
    In big endian mode regmap_bulk_read gives incorrect data
    for byte reads.
    
    This is because memcpy of a single byte from an address
    after full word read gives different results when
    endianness differs. ie. we get little-end in LE and big-end in BE.
    
    Signed-off-by: Arun Chandran <achandran@mvista.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dff5d6ed2aa052706a6cb877aa27f4c6b9e70f05
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu May 1 00:14:04 2014 +0200

    cpuidle / menu: Return (-1) if there are no suitable states
    
    commit 3836785a1bdcd6706c68ad46bf53adc0b057b310 upstream.
    
    If there is a PM QoS latency limit and all of the sufficiently shallow
    C-states are disabled, the cpuidle menu governor returns 0 which on
    some systems is CPUIDLE_DRIVER_STATE_START and shouldn't be returned
    if that C-state has been disabled.
    
    Fix the issue by modifying the menu governor to return (-1) in such
    situations.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [shilpab: Backport to 3.10.y
     - adjust context
     - add a check if 'next_state' is less than 0 in 'cpuidle_idle_call()',
       this ensures that we exit 'cpuidle_idle_call()' if governor->select()
       returns  negative value]
    Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fee157bdb44fde593a541ba0268c742a70d32e9
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jun 19 13:56:33 2015 +0100

    arm64: vdso: work-around broken ELF toolchains in Makefile
    
    commit 6f1a6ae87c0c60d7c462ef8fd071f291aa7a9abb upstream.
    
    When building the kernel with a bare-metal (ELF) toolchain, the -shared
    option may not be passed down to collect2, resulting in silent corruption
    of the vDSO image (in particular, the DYNAMIC section is omitted).
    
    The effect of this corruption is that the dynamic linker fails to find
    the vDSO symbols and libc is instead used for the syscalls that we
    intended to optimise (e.g. gettimeofday). Functionally, there is no
    issue as the sigreturn trampoline is still intact and located by the
    kernel.
    
    This patch fixes the problem by explicitly passing -shared to the linker
    when building the vDSO.
    
    Reported-by: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
    Reported-by: James Greenlaigh <james.greenhalgh@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a81e753d0294e9e7a46d3ddb6d20df553e8c986b
Author: Dave P Martin <Dave.Martin@arm.com>
Date:   Tue Jun 16 17:38:47 2015 +0100

    arm64: mm: Fix freeing of the wrong memmap entries with !SPARSEMEM_VMEMMAP
    
    commit b9bcc919931611498e856eae9bf66337330d04cc upstream.
    
    The memmap freeing code in free_unused_memmap() computes the end of
    each memblock by adding the memblock size onto the base.  However,
    if SPARSEMEM is enabled then the value (start) used for the base
    may already have been rounded downwards to work out which memmap
    entries to free after the previous memblock.
    
    This may cause memmap entries that are in use to get freed.
    
    In general, you're not likely to hit this problem unless there
    are at least 2 memblocks and one of them is not aligned to a
    sparsemem section boundary.  Note that carve-outs can increase
    the number of memblocks by splitting the regions listed in the
    device tree.
    
    This problem doesn't occur with SPARSEMEM_VMEMMAP, because the
    vmemmap code deals with freeing the unused regions of the memmap
    instead of requiring the arch code to do it.
    
    This patch gets the memblock base out of the memblock directly when
    computing the block end address to ensure the correct value is used.
    
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8401bf59751d62bdf110cf095eac0f92cd22a6f8
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Fri Jun 12 11:24:41 2015 +0100

    arm64: Do not attempt to use init_mm in reset_context()
    
    commit 565630d503ef24e44c252bed55571b3a0d68455f upstream.
    
    After secondary CPU boot or hotplug, the active_mm of the idle thread is
    &init_mm. The init_mm.pgd (swapper_pg_dir) is only meant for TTBR1_EL1
    and must not be set in TTBR0_EL1. Since when active_mm == &init_mm the
    TTBR0_EL1 is already set to the reserved value, there is no need to
    perform any context reset.
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab3252616dead8fb62a19b576eabdec137196e6d
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Thu Nov 13 15:54:01 2014 +0530

    ARC: add compiler barrier to LLSC based cmpxchg
    
    commit d57f727264f1425a94689bafc7e99e502cb135b5 upstream.
    
    When auditing cmpxchg call sites, Chuck noted that gcc was optimizing
    away some of the desired LDs.
    
    |	do {
    |		new = old = *ipi_data_ptr;
    |		new |= 1U << msg;
    |	} while (cmpxchg(ipi_data_ptr, old, new) != old);
    
    was generating to below
    
    | 8015cef8:	ld         r2,[r4,0]  <-- First LD
    | 8015cefc:	bset       r1,r2,r1
    |
    | 8015cf00:	llock      r3,[r4]  <-- atomic op
    | 8015cf04:	brne       r3,r2,8015cf10
    | 8015cf08:	scond      r1,[r4]
    | 8015cf0c:	bnz        8015cf00
    |
    | 8015cf10:	brne       r3,r2,8015cf00  <-- Branch doesn't go to orig LD
    
    Although this was fixed by adding a ACCESS_ONCE in this call site, it
    seems safer (for now at least) to add compiler barrier to LLSC based
    cmpxchg
    
    Reported-by: Chuck Jordan <cjordan@synopsys.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdbbeb69d4b93455a73edff725639216d7fe0b38
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jun 10 01:33:36 2015 +0200

    ACPI / init: Switch over platform to the ACPI mode later
    
    commit b064a8fa77dfead647564c46ac8fc5b13bd1ab73 upstream.
    
    Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
    timekeeping_init()" moved the ACPI subsystem initialization,
    including the ACPI mode enabling, to an earlier point in the
    initialization sequence, to allow the timekeeping subsystem
    use ACPI early.  Unfortunately, that resulted in boot regressions
    on some systems and the early ACPI initialization was moved toward
    its original position in the kernel initialization code by commit
    c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
    
    However, that turns out to be insufficient, as boot is still broken
    on the Tyan S8812 mainboard.
    
    To fix that issue, split the ACPI early initialization code into
    two pieces so the majority of it still located in acpi_early_init()
    and the part switching over the platform into the ACPI mode goes into
    a new function, acpi_subsystem_init(), executed at the original early
    ACPI initialization spot.
    
    That fixes the Tyan S8812 boot problem, but still allows ACPI
    tables to be loaded earlier which is useful to the EFI code in
    efi_enter_virtual_mode().
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
    Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
    Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Toshi Kani <toshi.kani@hp.com>
    Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
    Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ee34eafcc8e3bbeb724c9a46957ab91524cabd0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 29 08:38:02 2015 +0200

    ALSA: hda - Fix the dock headphone output on Fujitsu Lifebook E780
    
    commit 4df3fd1700abbb53bd874143dfd1f9ac9e7cbf4b upstream.
    
    Fujitsu Lifebook E780 sets the sequence number 0x0f to only only of
    the two headphones, thus the driver tries to assign another as the
    line-out, and this results in the inconsistent mapping between the
    created jack ctl and the actual I/O.  Due to this, PulseAudio doesn't
    handle it properly and gets the silent output.
    
    The fix is to ignore the non-HP sequencer checks.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99681
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c362b8bd80e2abbda334a330fc68a0b0ad69162
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Jun 27 10:21:13 2015 +0200

    ALSA: hda - Add headset support to Acer Aspire V5
    
    commit 7819717b11346b8a5420b223b46600e394049c66 upstream.
    
    Acer Aspire V5 with ALC282 codec needs the similar quirk like Dell
    laptops to support the headset mic.  The headset mic pin is 0x19 and
    it's not exposed by BIOS, thus we need to fix the pincfg as well.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1d4aea6b724e0d3fad391eee16e55caa1693b63
Author: Ryan Underwood <nemesis@icequake.net>
Date:   Sun Jan 25 16:07:09 2015 -0800

    Disable write buffering on Toshiba ToPIC95
    
    commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.
    
    Disable write buffering on the Toshiba ToPIC95 if it is enabled by
    somebody (it is not supposed to be a power-on default according to
    the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
    will work under heavy load without locking up the whole system if
    this is left enabled. I tried about a dozen. It does not affect
    16-bit cards. This is similar to the O2 bugs in early controller
    revisions it seems.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961
    Signed-off-by: Ryan C. Underwood <nemesis@icequake.net>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6caff0d979b9beca56bd67974fdacb48b4f5ca9f
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Wed May 13 08:50:27 2015 -0500

    ipr: Increase default adapter init stage change timeout
    
    commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream.
    
    Increase the default init stage change timeout from 15 seconds to 30 seconds.
    This resolves issues we have seen with some adapters not transitioning
    to the first init stage within 15 seconds, which results in adapter
    initialization failures.
    
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b39286e0ab7ca991d63af20a3f72ff3f7985d429
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Mon May 11 11:13:05 2015 -0700

    rcu: Correctly handle non-empty Tiny RCU callback list with none ready
    
    commit 6e91f8cb138625be96070b778d9ba71ce520ea7e upstream.
    
    If, at the time __rcu_process_callbacks() is invoked,  there are callbacks
    in Tiny RCU's callback list, but none of them are ready to be invoked,
    the current list-management code will knit the non-ready callbacks out
    of the list.  This can result in hangs and possibly worse.  This commit
    therefore inserts a check for there being no callbacks that can be
    invoked immediately.
    
    This bug is unlikely to occur -- you have to get a new callback between
    the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to
    __rcu_process_callbacks().  It was detected by the addition of RCU-bh
    testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's
    mutation testing.  Although this bug was made much more likely by
    915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this
    did not cause the bug, but rather made it much more probable.   That
    said, it takes more than 40 hours of rcutorture testing, on average,
    for this bug to appear, so this fix cannot be considered an emergency.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Reviewed-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>