commit e9fd6ddcabf8695329f2462d3ece5a8442f2a8cf
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Fri Aug 7 15:08:04 2015 -0400

    Linux 3.18.20
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit df0e5109cfea25f842bf99f567aac20ac9ef78fe
Author: Ming Lei <ming.lei@canonical.com>
Date:   Tue Apr 21 10:00:20 2015 +0800

    blk-mq: fix CPU hotplug handling
    
    [ Upstream commit 2a34c0872adf252f23a6fef2d051a169ac796cef ]
    
    hctx->tags has to be set as NULL in case that it is to be unmapped
    no matter if set->tags[hctx->queue_num] is NULL or not in blk_mq_map_swqueue()
    because shared tags can be freed already from another request queue.
    
    The same situation has to be considered during handling CPU online too.
    Unmapped hw queue can be remapped after CPU topo is changed, so we need
    to allocate tags for the hw queue in blk_mq_map_swqueue(). Then tags
    allocation for hw queue can be removed in hctx cpu online notifier, and it
    is reasonable to do that after mapping is updated.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Dongsu Park <dongsu.park@profitbricks.com>
    Tested-by: Dongsu Park <dongsu.park@profitbricks.com>
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit bda69f1aaee53837ba22e2ea149219dff486f542
Author: Mike Christie <michaelc@cs.wisc.edu>
Date:   Mon Apr 20 22:42:24 2015 -0500

    SCSI: add 1024 max sectors black list flag
    
    [ Upstream commit 35e9a9f93994d7f7d12afa41169c7ba05513721b ]
    
    This works around a issue with qnap iscsi targets not handling large IOs
    very well.
    
    The target returns:
    
    VPD INQUIRY: Block limits page (SBC)
      Maximum compare and write length: 1 blocks
      Optimal transfer length granularity: 1 blocks
      Maximum transfer length: 4294967295 blocks
      Optimal transfer length: 4294967295 blocks
      Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
      Maximum unmap LBA count: 8388607
      Maximum unmap block descriptor count: 1
      Optimal unmap granularity: 16383
      Unmap granularity alignment valid: 0
      Unmap granularity alignment: 0
      Maximum write same length: 0xffffffff blocks
      Maximum atomic transfer length: 0
      Atomic alignment: 0
      Atomic transfer length granularity: 0
    
    and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
    have seen in traces where it will sometimes work, but other times it
    looks like it fails and it looks like it returns failures if we send
    multiple large IOs sometimes. Also it looks like it can return 2 different
    errors. It will sometimes send iscsi reject errors indicating out of
    resources or it will send invalid cdb illegal requests check conditions.
    And then when it sends iscsi rejects it does not seem to handle retries
    when there are command sequence holes, so I could not just add code to
    try and gracefully handle that error code.
    
    The problem is that we do not have a good contact for the company,
    so we are not able to determine under what conditions it returns
    which error and why it sometimes works.
    
    So, this patch just adds a new black list flag to set targets like this to
    the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
    caused this regression, so I also ccing stable.
    
    Reported-by: Christian Hesse <list@eworm.de>
    Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
    Cc: stable@vger.kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    Fix firmware loader uevent buffer NULL pointer dereference
    
    [ Upstream commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c ]
    
    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>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3e35337a4ba284ce6a338ee0de8c0fbb2932bc2c
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
    
    [ Upstream commit fd28f5d439fca77348c129d5b73043a56f8a0296 ]
    
    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.")
    Cc: <stable@vger.kernel.org> # 3.11+
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 388d75e1e885e8fe0c705a6aa1ed818cf6396df3
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
    
    [ Upstream commit 0a73d0a204a4a04a1e110539c5a524ae51f91d6d ]
    
    Cc: stable@vger.kernel.org # all branches
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 82bec81e4d7d53b46fca391774271f801b18d6e5
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
    
    [ Upstream commit a84b69cb6e0a41e86bc593904faa6def3b957343 ]
    
    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.
    
    Cc: stable@vger.kernel.org # v3.2 and later
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    NFS: Fix size of NFSACL SETACL operations
    
    [ Upstream commit d683cc49daf7c5afca8cd9654aaa1bf63cdf2ad9 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 448d34256e77574e0d0b8ffdc35ec3239d9acfa0
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
    
    [ Upstream commit 530c11d432727c697629ad5f9d00ee8e2864d453 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit dd95eaaea493d74df5ae81c7e5846e6b33ee91b1
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()
    
    [ Upstream commit c8fff7bc5bba6bd59cad40441c189c4efe7190f6 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 3e2003cccc9fb5f73a0d251dbb595f4c6e3a08bd
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
    
    [ Upstream commit 3f2cee73b650921b2e214bf487b2061a1c266504 ]
    
    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 <greg@kroah.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit bb91f0ab2a32dc6afa29e17e9ba865e5335ffb0e
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
    
    [ Upstream commit b8830a4e71b15d0364ac8e6c55301eea73f211da ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    mac80211: prevent possible crypto tx tailroom corruption
    
    [ Upstream commit ab499db80fcf07c18e4053f91a619500f663e90e ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

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

    security_syslog() should be called once only
    
    [ Upstream commit d194e5d666225b04c7754471df0948f645b6ab3a ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

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

    __bitmap_parselist: fix bug in empty string handling
    
    [ Upstream commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit f078fd1dae84e8695fdd717554addd0e13d2dc35
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
    
    [ Upstream commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 3e2ee0584b7c688bbc2c1951e8348b2302ab4873
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
    
    [ Upstream commit 4a579da2586bd3b79b025947ea24ede2bbfede62 ]
    
    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>
    Cc: <stable@vger.kernel.org> # v3.10+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit cf57073b8687f6984366cbb158e2609bb1f9b614
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
    
    [ Upstream commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca ]
    
    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>
    Cc: <stable@vger.kernel.org> # v3.10+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit bc29d0be4238aafed6dafd70a252cddc213bf3e9
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
    
    [ Upstream commit c04be18448355441a0c424362df65b6422e27bda ]
    
    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
    Cc: All applicable <stable@vger.kernel.org> # All applicable
    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: Sasha Levin <sasha.levin@oracle.com>

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

    Btrfs: fix memory leak in the extent_same ioctl
    
    [ Upstream commit 497b4050e0eacd4c746dd396d14916b1e669849d ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Mark Fasheh <mfasheh@suse.de>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 3c668a81f9214f32e521baa89e4b0d7b00dd09f9
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
    
    [ Upstream commit c3f4a1685bb87e59c886ee68f7967eae07d4dffa ]
    
    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().
    
    Cc: stable@vger.kernel.org
    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: Sasha Levin <sasha.levin@oracle.com>

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

    md: fix a build warning
    
    [ Upstream commit 4e023612325a9034a542bfab79f78b1fe5ebb841 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 96558f2fbefed1b3b05d9f8f85fc40f6d74dac3e
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
    
    [ Upstream commit 6224beb12e190ff11f3c7d4bf50cb2922878f600 ]
    
    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
    
    Cc: stable@vger.kernel.org # 3.10+
    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: Sasha Levin <sasha.levin@oracle.com>

commit 8c9482a9bc47fee04173956f1fa05eada7779d82
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
    
    [ Upstream commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 ]
    
    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>
    Cc: stable@vger.kernel.org # 2.6.33+
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    libata: force disable trim for SuperSSpeed S238
    
    [ Upstream commit cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    libata: add ATA_HORKAGE_NOTRIM
    
    [ Upstream commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    evm: labeling pseudo filesystems exception
    
    [ Upstream commit 5101a1850bb7ccbf107929dee9af0cd2f400940f ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 66db51c9f7b2fe7ebdfa753b2aa9abbb9feddc87
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
    
    [ Upstream commit HEAD ]
    
    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>
    
    (cherry picked from commit c9cd9b18dac801040ada16562dc579d5ac366d75)
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 6a85c7b5fdf5a300a25a5f804f24b8fb09e472f9
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
    
    [ Upstream commit 01447e9f04ba1c49a9534ae6a5a6f26c2bb05226 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 04e685d86e0c3fd7b47bebb6efdd488222b500e1
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
    
    [ Upstream commit 5dfc71bc44d91d1620505c064fa22b0b3db58a9d ]
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=76490
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 0e1b8effa553cc8f07c1a53b93f1ea9ce20b551d
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()
    
    [ Upstream commit 9098f84cced870f54d8c410dd2444cfa61467fa0 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 50ca84670e1c8c72b2e4c37e7abfaff0fde42180
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()
    
    [ Upstream commit 1c7518794a3647eb345d59ee52844e8a40405198 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    dm btree remove: fix bug in redistribute3
    
    [ Upstream commit 4c7e309340ff85072e96f529582d159002c36734 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 8b338c3a9df7ca4b6b9729eef90d7b2e7ba7b800
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
    
    [ Upstream commit 3496810663922617d4b706ef2780c279252ddd6a ]
    
    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;
    
    Cc: <stable@vger.kernel.org>
    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>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    USB: serial: Destroy serial_minors IDR on module exit
    
    [ Upstream commit d23f47d4927fd2f61b3a754d83c7bcec215b5cfe ]
    
    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>
    Cc: stable <stable@vger.kernel.org>	# v3.11
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    USB: option: add 2020:4000 ID
    
    [ Upstream commit f6d7fb37f92622479ef6da604f27561f5045ba1e ]
    
    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>
    Cc: stable <stable@vger.kernel.org>
    [johan: amend commit message with devices info ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    USB: cp210x: add ID for Aruba Networks controllers
    
    [ Upstream commit f98a7aa81eeeadcad25665c3501c236d531d4382 ]
    
    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>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 689488fc565537d2e2de46ee78e59903768b1385
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()
    
    [ Upstream commit be9d39881fc4fa39a64b6eed6bab5d9ee5125344 ]
    
    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>
    Cc: <stable@vger.kernel.org> # v3.11+
    Tested-by: Sekhar Nori <nsekhar@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    USB: devio: fix a condition in async_completed()
    
    [ Upstream commit 83ed07c5db71bc02bd646d6eb60b48908235cdf9 ]
    
    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>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a0c760181ca874bc8b42fceafcb4aad7000d891a
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
    
    [ Upstream commit aebda618718157a69c0dc0adb978d69bc2b8723c ]
    
    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)
    Cc: <stable@vger.kernel.org> # v3.2+
    Signed-off-by: John Youn <johnyoun@synopsys.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    libata: increase the timeout when setting transfer mode
    
    [ Upstream commit d531be2ca2f27cca5f041b6a140504999144a617 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit dba1319c94b1d257b5883e1db8b3f0b4fa940d54
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
    
    [ Upstream commit 08c85d2a599d967ede38a847f5594447b6100642 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    ASoC: imx-wm8962: Add a missing error check
    
    [ Upstream commit 474ff0ae23b834e9fc18374d14bb5f3e7b3828b4 ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 3f6aa9f86f11b733f067c68e3fc66bc54522d915
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
    
    [ Upstream commit 815983e9afcb21552e1b9d77e3755d394cbf5249 ]
    
    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>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    iio: tmp006: Check channel info on write
    
    [ Upstream commit f451957dafe712ab2cd4b7ca8ba9197798115fbe ]
    
    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>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit b217d7a8e1fcf13a010933d8b7ce34f0d197278c
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
    
    [ Upstream commit 09f4dcc9443c4731b6669066bd1bc4312ef17bcc ]
    
    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>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 908e65906a2e1f938f0972bbf7b058c6dd945628
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()
    
    [ Upstream commit 7444a072c387a93ebee7066e8aee776954ab0e41 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit f164c7de2710059aae7b66f668f0a2ab5a7689c2
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
    
    [ Upstream commit 8974fec7d72e3e02752fe0f27b4c3719c78d9a15 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit 694fd43fb701e0db5d3cdefc49725a1154a605a7
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
    
    [ Upstream commit d6f123a9297496ad0b6335fe881504c4b5b2a5e5 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

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

    ext4: fix reservation release on invalidatepage for delalloc fs
    
    [ Upstream commit 9705acd63b125dee8b15c705216d7186daea4625 ]
    
    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>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ae241ca5155667c947f6a19ea5c370c964768ac7
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
    
    [ Upstream commit ea6055c46eda1e19e02209814955e13f334bbe1b ]
    
    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: Sasha Levin <sasha.levin@oracle.com>

commit 79e215ad098a57b3bc1e82b6891d999ddfc77f73
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Tue Aug 4 13:32:39 2015 -0400

    Revert "can: fix loss of CAN frames in raw_rcv"
    
    This reverts commit c215cf258214858a5a6c3e63cd7ee78b92d210b2.
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>