commit 9b8b905951bde404f20a7bd4b37a5134f3484569
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Aug 10 12:22:57 2015 -0700

    Linux 3.14.50

commit 9a9f238fd717519adf1ecc54d66763b06d81e6e3
Author: Fupan Li <fupan.li@windriver.com>
Date:   Tue Aug 4 09:51:21 2015 +0800

    efi: fix 32bit kernel boot failed problem using efi
    
    Commit 35d5134b7d5a
    ("x86/efi: Correct EFI boot stub use of code32_start")
    imported a bug, which will cause 32bit kernel boot failed
    using efi method. It should use the label's address instead
    of the value stored in the label to caculate the address of
    code32_start.
    
    Signed-off-by: Fupan Li <fupan.li@windriver.com>
    Reviewed-by: Matt Fleming <matt.fleming@intel.com>

commit 00e59335e5d7e36ad36b4702a9dc6038ab9c0198
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jul 23 22:30:31 2015 +0000

    iscsi-target: Fix iser explicit logout TX kthread leak
    
    commit 007d038bdf95ccfe2491d0078be54040d110fd06 upstream.
    
    This patch fixes a regression introduced with the following commit
    in v4.0-rc1 code, where an explicit iser-target logout would result
    in ->tx_thread_active being incorrectly cleared by the logout post
    handler, and subsequent TX kthread leak:
    
        commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca
        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
    
    To address this bug, change iscsit_logout_post_handler_closesession()
    and iscsit_logout_post_handler_samecid() to only cmpxchg() on
    ->tx_thread_active for traditional iscsi/tcp connections.
    
    This is required because iscsi/tcp connections are invoking logout
    post handler logic directly from TX kthread context, while iser
    connections are invoking logout post handler logic from a seperate
    workqueue context.
    
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 557538d827039c12d7862fa0be562a2192fae742
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 22 00:24:09 2015 -0700

    iscsi-target: Fix use-after-free during TPG session shutdown
    
    commit 417c20a9bdd1e876384127cf096d8ae8b559066c upstream.
    
    This patch fixes a use-after-free bug in iscsit_release_sessions_for_tpg()
    where se_portal_group->session_lock was incorrectly released/re-acquired
    while walking the active se_portal_group->tpg_sess_list.
    
    The can result in a NULL pointer dereference when iscsit_close_session()
    shutdown happens in the normal path asynchronously to this code, causing
    a bogus dereference of an already freed list entry to occur.
    
    To address this bug, walk the session list checking for the same state
    as before, but move entries to a local list to avoid dropping the lock
    while walking the active list.
    
    As before, signal using iscsi_session->session_restatement=1 for those
    list entries to be released locally by iscsit_free_session() code.
    
    Reported-by: Sunilkumar Nadumuttlu <sjn@datera.io>
    Cc: Sunilkumar Nadumuttlu <sjn@datera.io>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 062a0294618b855d77f24ecd8037b8d3017c3949
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Jul 24 13:49:48 2015 +0300

    avr32: handle NULL as a valid clock object
    
    commit 5c02a4206538da12c040b51778d310df84c6bf6c upstream.
    
    Since NULL is used as valid clock object on optional clocks we have to handle
    this case in avr32 implementation as well.
    
    Fixes: e1824dfe0d8e (net: macb: Adjust tx_clk when link speed changes)
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0a45c374d8478fb4ec2e3b4949e394d75ceb11a
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date:   Fri Jul 17 15:32:03 2015 +0200

    vhost: actually track log eventfd file
    
    commit 7932c0bd7740f4cd2aa168d3ce0199e7af7d72d5 upstream.
    
    While reviewing vhost log code, I found out that log_file is never
    set. Note: I haven't tested the change (QEMU doesn't use LOG_FD yet).
    
    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 037177a84b46940f83fa39d3fd963c5aa8b465c5
Author: Wengang Wang <wen.gang.wang@oracle.com>
Date:   Mon Jul 6 14:35:11 2015 +0800

    rds: rds_ib_device.refcount overflow
    
    commit 4fabb59449aa44a585b3603ffdadd4c5f4d0c033 upstream.
    
    Fixes: 3e0249f9c05c ("RDS/IB: add refcount tracking to struct rds_ib_device")
    
    There lacks a dropping on rds_ib_device.refcount in case rds_ib_alloc_fmr
    failed(mr pool running out). this lead to the refcount overflow.
    
    A complain in line 117(see following) is seen. From vmcore:
    s_ib_rdma_mr_pool_depleted is 2147485544 and rds_ibdev->refcount is -2147475448.
    That is the evidence the mr pool is used up. so rds_ib_alloc_fmr is very likely
    to return ERR_PTR(-EAGAIN).
    
    115 void rds_ib_dev_put(struct rds_ib_device *rds_ibdev)
    116 {
    117         BUG_ON(atomic_read(&rds_ibdev->refcount) <= 0);
    118         if (atomic_dec_and_test(&rds_ibdev->refcount))
    119                 queue_work(rds_wq, &rds_ibdev->free_work);
    120 }
    
    fix is to drop refcount when rds_ib_alloc_fmr failed.
    
    Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
    Reviewed-by: Haggai Eran <haggaie@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 199db4c3e92be998d490d7c59cc684ba0d88f3e3
Author: Dmitry Skorodumov <sdmitry@parallels.com>
Date:   Tue Jul 28 18:38:32 2015 +0400

    x86/efi: Use all 64 bit of efi_memmap in setup_e820()
    
    commit 7cc03e48965453b5df1cce5062c826189b04b960 upstream.
    
    The efi_info structure stores low 32 bits of memory map
    in efi_memmap and high 32 bits in efi_memmap_hi.
    
    While constructing pointer in the setup_e820(), need
    to take into account all 64 bit of the pointer.
    
    It is because on 64bit machine the function
    efi_get_memory_map() may return full 64bit pointer and before
    the patch that pointer was truncated.
    
    The issue is triggered on Parallles virtual machine and
    fixed with this patch.
    
    Signed-off-by: Dmitry Skorodumov <sdmitry@parallels.com>
    Cc: Denis V. Lunev <den@openvz.org>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e10c27c9f0f42268259543d011f36f1ea03d3946
Author: Zhuang Jin Can <jin.can.zhuang@intel.com>
Date:   Tue Jul 21 17:20:31 2015 +0300

    xhci: do not report PLC when link is in internal resume state
    
    commit aca3a0489ac019b58cf32794d5362bb284cb9b94 upstream.
    
    Port link change with port in resume state should not be
    reported to usbcore, as this is an internal state to be
    handled by xhci driver. Reporting PLC to usbcore may
    cause usbcore clearing PLC first and port change event irq
    won't be generated.
    
    Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0a3f81285858389db73c91cb960f4e473cce0be
Author: Zhuang Jin Can <jin.can.zhuang@intel.com>
Date:   Tue Jul 21 17:20:30 2015 +0300

    xhci: prevent bus_suspend if SS port resuming in phase 1
    
    commit fac4271d1126c45ceaceb7f4a336317b771eb121 upstream.
    
    When the link is just waken, it's in Resume state, and driver sets PLS to
    U0. This refers to Phase 1. Phase 2 refers to when the link has completed
    the transition from Resume state to U0.
    
    With the fix of xhci: report U3 when link is in resume state, it also
    exposes an issue that usb3 roothub and controller can suspend right
    after phase 1, and this causes a hard hang in controller.
    
    To fix the issue, we need to prevent usb3 bus suspend if any port is
    resuming in phase 1.
    
    [merge separate USB2 and USB3 port resume checking to one -Mathias]
    Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcaa3320f90404d5d61c38ba635c090deb0ea24e
Author: Zhuang Jin Can <jin.can.zhuang@intel.com>
Date:   Tue Jul 21 17:20:29 2015 +0300

    xhci: report U3 when link is in resume state
    
    commit 243292a2ad3dc365849b820a64868927168894ac upstream.
    
    xhci_hub_report_usb3_link_state() returns pls as U0 when the link
    is in resume state, and this causes usb core to think the link is in
    U0 while actually it's in resume state. When usb core transfers
    control request on the link, it fails with TRB error as the link
    is not ready for transfer.
    
    To fix the issue, report U3 when the link is in resume state, thus
    usb core knows the link it's not ready for transfer.
    
    Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16da0ed9993056d465c4b55a9f6ee3cc19edfb70
Author: Brian Campbell <bacam@z273.org.uk>
Date:   Tue Jul 21 17:20:28 2015 +0300

    xhci: Calculate old endpoints correctly on device reset
    
    commit 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 upstream.
    
    When resetting a device the number of active TTs may need to be
    corrected by xhci_update_tt_active_eps, but the number of old active
    endpoints supplied to it was always zero, so the number of TTs and the
    bandwidth reserved for them was not updated, and could rise
    unnecessarily.
    
    This affected systems using Intel's Patherpoint chipset, which rely on
    software bandwidth checking.  For example, a Lenovo X230 would lose the
    ability to use ports on the docking station after enough suspend/resume
    cycles because the bandwidth calculated would rise with every cycle when
    a suitable device is attached.
    
    The correct number of active endpoints is calculated in the same way as
    in xhci_reserve_bandwidth.
    
    Signed-off-by: Brian Campbell <bacam@z273.org.uk>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb101c8e329027bed11db4ec7f437d2e77433414
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Jul 6 13:12:32 2015 +0200

    usb-storage: ignore ZTE MF 823 card reader in mode 0x1225
    
    commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream.
    
    This device automatically switches itself to another mode (0x1405)
    unless the specific access pattern of Windows is followed in its
    initial mode. That makes a dirty unmount of the internal storage
    devices inevitable if they are mounted. So the card reader of
    such a device should be ignored, lest an unclean removal become
    inevitable.
    
    This replaces an earlier patch that ignored all LUNs of this device.
    That patch was overly broad.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reviewed-by: Lars Melin <larsm17@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d30c6ffd66e05da681d800ae6fbf5f01b4b20064
Author: Lior Amsalem <alior@marvell.com>
Date:   Tue Jun 30 16:09:49 2015 +0200

    ata: pmp: add quirk for Marvell 4140 SATA PMP
    
    commit 945b47441d83d2392ac9f984e0267ad521f24268 upstream.
    
    This commit adds the necessary quirk to make the Marvell 4140 SATA PMP
    work properly. This PMP doesn't like SRST on port number 4 (the host
    port) so this commit marks this port as not supporting SRST.
    
    Signed-off-by: Lior Amsalem <alior@marvell.com>
    Reviewed-by: Nadav Haklai <nadavh@marvell.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdae476bfc87b92414a633211194e21100163404
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Jul 22 18:05:53 2015 -0400

    blkcg: fix gendisk reference leak in blkg_conf_prep()
    
    commit 5f6c2d2b7dbb541c1e922538c49fa04c494ae3d7 upstream.
    
    When a blkcg configuration is targeted to a partition rather than a
    whole device, blkg_conf_prep fails with -EINVAL; unfortunately, it
    forgets to put the gendisk ref in that case.  Fix it.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2670fc6fb3c98b75bf30a82c84ea0e89f268a811
Author: Bernhard Bender <bernhard.bender@bytecmed.com>
Date:   Thu Jul 23 13:58:08 2015 -0700

    Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen
    
    commit 968491709e5b1aaf429428814fff3d932fa90b60 upstream.
    
    This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30
    touch screen.  Due to a missing delay between the RESET and SET_RATE
    commands, the touch screen may become unresponsive during system startup or
    driver loading.
    
    According to the DMC documentation, a delay is needed after the RESET
    command to allow the chip to complete its internal initialization. As this
    delay is not guaranteed, we had a system where the touch screen
    occasionally did not send any touch data. There was no other indication of
    the problem.
    
    The patch fixes the problem by adding a 150ms delay between the RESET and
    SET_RATE commands.
    
    Suggested-by: Jakob Mustafa <jakob.mustafa@bytecmed.com>
    Signed-off-by: Bernhard Bender <bernhard.bender@bytecmed.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8af704c42356cf48ee4c989268463683c25bc69
Author: Chris Metcalf <cmetcalf@ezchip.com>
Date:   Thu Jul 23 14:11:09 2015 -0400

    tile: use free_bootmem_late() for initrd
    
    commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 upstream.
    
    We were previously using free_bootmem() and just getting lucky
    that nothing too bad happened.
    
    Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 504f5331b37e226f8f5e04a3f890a1247e9e825b
Author: NeilBrown <neilb@suse.com>
Date:   Fri Jul 24 09:22:16 2015 +1000

    md/raid1: fix test for 'was read error from last working device'.
    
    commit 34cab6f42003cb06f48f86a86652984dec338ae9 upstream.
    
    When we get a read error from the last working device, we don't
    try to repair it, and don't fail the device.  We simple report a
    read error to the caller.
    
    However the current test for 'is this the last working device' is
    wrong.
    When there is only one fully working device, it assumes that a
    non-faulty device is that device.  However a spare which is rebuilding
    would be non-faulty but so not the only working device.
    
    So change the test from "!Faulty" to "In_sync".  If ->degraded says
    there is only one fully working device and this device is in_sync,
    this must be the one.
    
    This bug has existed since we allowed read_balance to read from
    a recovering spare in v3.0
    
    Reported-and-tested-by: Alexander Lyakas <alex.bolshoy@gmail.com>
    Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1af2037e77e3c873bd85349c32e6f4cea02fa695
Author: Jingju Hou <houjingj@marvell.com>
Date:   Thu Jul 23 17:56:23 2015 +0800

    mmc: sdhci-pxav3: fix platform_data is not initialized
    
    commit 9cd76049f0d90ae241f5ad80e311489824527000 upstream.
    
    pdev->dev.platform_data is not initialized if match is true in function
    sdhci_pxav3_probe. Just local variable pdata is assigned the return value
    from function pxav3_get_mmc_pdata().
    
    static int sdhci_pxav3_probe(struct platform_device *pdev) {
    
        struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
        ...
        if (match) {
    		ret = mmc_of_parse(host->mmc);
    		if (ret)
    			goto err_of_parse;
    		sdhci_get_of_property(pdev);
    		pdata = pxav3_get_mmc_pdata(dev);
         }
         ...
    }
    
    Signed-off-by: Jingju Hou <houjingj@marvell.com>
    Fixes: b650352dd3df("mmc: sdhci-pxa: Add device tree support")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b42a4443fde7675b28529f0b508d5da0c182b11
Author: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date:   Wed Jul 22 16:44:26 2015 +0200

    mmc: sdhci-esdhc: Make 8BIT bus work
    
    commit 8e91125ff3f57f15c6568e2a6d32743b3f7815e4 upstream.
    
    Support for 8BIT bus with was added some time ago to sdhci-esdhc but
    then missed to remove the 8BIT from the reserved bit mask which made
    8BIT non functional.
    
    Fixes: 66b50a00992d ("mmc: esdhc: Add support for 8-bit bus width and..")
    Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cefd0dbbfae0ebb5563073681aaf77b2c43c9b8
Author: Tom Hughes <tom@compton.nu>
Date:   Mon Jun 29 19:41:49 2015 +0100

    mac80211: clear subdir_stations when removing debugfs
    
    commit 4479004e6409087d1b4986881dc98c6c15dffb28 upstream.
    
    If we don't do this, and we then fail to recreate the debugfs
    directory during a mode change, then we will fail later trying
    to add stations to this now bogus directory:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000006c
    IP: [<c0a92202>] mutex_lock+0x12/0x30
    Call Trace:
    [<c0678ab4>] start_creating+0x44/0xc0
    [<c0679203>] debugfs_create_dir+0x13/0xf0
    [<f8a938ae>] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211]
    
    Signed-off-by: Tom Hughes <tom@compton.nu>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e488e2f547b67cedb70a760d8d6368eb32d19b37
Author: Seymour, Shane M <shane.seymour@hp.com>
Date:   Thu Jul 2 12:01:10 2015 +0000

    st: null pointer dereference panic caused by use after kref_put by st_open
    
    commit e7ac6c6666bec0a354758a1298d3231e4a635362 upstream.
    
    Two SLES11 SP3 servers encountered similar crashes simultaneously
    following some kind of SAN/tape target issue:
    
    ...
    qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
    qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 --  1 2002.
    qla2xxx [0000:81:00.0]-8009:3: DEVICE RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800f:3: DEVICE RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-8009:3: TARGET RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-800f:3: TARGET RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
    qla2xxx [0000:81:00.0]-8012:3: BUS RESET ISSUED nexus=3:0:2.
    qla2xxx [0000:81:00.0]-802b:3: BUS RESET SUCCEEDED nexus=3:0:2.
    qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
    qla2xxx [0000:81:00.0]-8018:3: ADAPTER RESET ISSUED nexus=3:0:2.
    qla2xxx [0000:81:00.0]-00af:3: Performing ISP error recovery - ha=ffff88bf04d18000.
     rport-3:0-0: blocked FC remote port time out: removing target and saving binding
    qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
    qla2xxx [0000:81:00.0]-8017:3: ADAPTER RESET SUCCEEDED nexus=3:0:2.
     rport-2:0-0: blocked FC remote port time out: removing target and saving binding
    sg_rq_end_io: device detached
    BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8
    IP: [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
    PGD 7e6586f067 PUD 7e5af06067 PMD 0 [1739975.390354] Oops: 0002 [#1] SMP
    CPU 0
    ...
    Supported: No, Proprietary modules are loaded [1739975.390463]
    Pid: 27965, comm: ABCD Tainted: PF           X 3.0.101-0.29-default #1 HP ProLiant DL580 Gen8
    RIP: 0010:[<ffffffff8133b268>]  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
    RSP: 0018:ffff8839dc1e7c68  EFLAGS: 00010202
    RAX: 0000000000000000 RBX: ffff883f0592fc00 RCX: 0000000000000090
    RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000138
    RBP: 0000000000000138 R08: 0000000000000010 R09: ffffffff81bd39d0
    R10: 00000000000009c0 R11: ffffffff81025790 R12: 0000000000000001
    R13: ffff883022212b80 R14: 0000000000000004 R15: ffff883022212b80
    FS:  00007f8e54560720(0000) GS:ffff88407f800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 00000000000002a8 CR3: 0000007e6ced6000 CR4: 00000000001407f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process ABCD (pid: 27965, threadinfo ffff8839dc1e6000, task ffff883592e0c640)
    Stack:
     ffff883f0592fc00 00000000fffffffa 0000000000000001 ffff883022212b80
     ffff883eff772400 ffffffffa03fa309 0000000000000000 0000000000000000
     ffffffffa04003a0 ffff883f063196c0 ffff887f0379a930 ffffffff8115ea1e
    Call Trace:
     [<ffffffffa03fa309>] st_open+0x129/0x240 [st]
     [<ffffffff8115ea1e>] chrdev_open+0x13e/0x200
     [<ffffffff811588a8>] __dentry_open+0x198/0x310
     [<ffffffff81167d74>] do_last+0x1f4/0x800
     [<ffffffff81168fe9>] path_openat+0xd9/0x420
     [<ffffffff8116946c>] do_filp_open+0x4c/0xc0
     [<ffffffff8115a00f>] do_sys_open+0x17f/0x250
     [<ffffffff81468d92>] system_call_fastpath+0x16/0x1b
     [<00007f8e4f617fd0>] 0x7f8e4f617fcf
    Code: eb d3 90 48 83 ec 28 40 f6 c6 04 48 89 6c 24 08 4c 89 74 24 20 48 89 fd 48 89 1c 24 4c 89 64 24 10 41 89 f6 4c 89 6c 24 18 74 11 <f0> ff 8f 70 01 00 00 0f 94 c0 45 31 ed 84 c0 74 2b 4c 8d a5 a0
    RIP  [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
     RSP <ffff8839dc1e7c68>
    CR2: 00000000000002a8
    
    Analysis reveals the cause of the crash to be due to STp->device
    being NULL. The pointer was NULLed via scsi_tape_put(STp) when it
    calls scsi_tape_release(). In st_open() we jump to err_out after
    scsi_block_when_processing_errors() completes and returns the
    device as offline (sdev_state was SDEV_DEL):
    
    1180 /* Open the device. Needs to take the BKL only because of incrementing the SCSI host
    1181    module count. */
    1182 static int st_open(struct inode *inode, struct file *filp)
    1183 {
    1184         int i, retval = (-EIO);
    1185         int resumed = 0;
    1186         struct scsi_tape *STp;
    1187         struct st_partstat *STps;
    1188         int dev = TAPE_NR(inode);
    1189         char *name;
    ...
    1217         if (scsi_autopm_get_device(STp->device) < 0) {
    1218                 retval = -EIO;
    1219                 goto err_out;
    1220         }
    1221         resumed = 1;
    1222         if (!scsi_block_when_processing_errors(STp->device)) {
    1223                 retval = (-ENXIO);
    1224                 goto err_out;
    1225         }
    ...
    1264  err_out:
    1265         normalize_buffer(STp->buffer);
    1266         spin_lock(&st_use_lock);
    1267         STp->in_use = 0;
    1268         spin_unlock(&st_use_lock);
    1269         scsi_tape_put(STp); <-- STp->device = 0 after this
    1270         if (resumed)
    1271                 scsi_autopm_put_device(STp->device);
    1272         return retval;
    
    The ref count for the struct scsi_tape had already been reduced
    to 1 when the .remove method of the st module had been called.
    The kref_put() in scsi_tape_put() caused scsi_tape_release()
    to be called:
    
    0266 static void scsi_tape_put(struct scsi_tape *STp)
    0267 {
    0268         struct scsi_device *sdev = STp->device;
    0269
    0270         mutex_lock(&st_ref_mutex);
    0271         kref_put(&STp->kref, scsi_tape_release); <-- calls this
    0272         scsi_device_put(sdev);
    0273         mutex_unlock(&st_ref_mutex);
    0274 }
    
    In scsi_tape_release() the struct scsi_device in the struct
    scsi_tape gets set to NULL:
    
    4273 static void scsi_tape_release(struct kref *kref)
    4274 {
    4275         struct scsi_tape *tpnt = to_scsi_tape(kref);
    4276         struct gendisk *disk = tpnt->disk;
    4277
    4278         tpnt->device = NULL; <<<---- where the dev is nulled
    4279
    4280         if (tpnt->buffer) {
    4281                 normalize_buffer(tpnt->buffer);
    4282                 kfree(tpnt->buffer->reserved_pages);
    4283                 kfree(tpnt->buffer);
    4284         }
    4285
    4286         disk->private_data = NULL;
    4287         put_disk(disk);
    4288         kfree(tpnt);
    4289         return;
    4290 }
    
    Although the problem was reported on SLES11.3 the problem appears
    in linux-next as well.
    
    The crash is fixed by reordering the code so we no longer access
    the struct scsi_tape after the kref_put() is done on it in st_open().
    
    Signed-off-by: Shane Seymour <shane.seymour@hp.com>
    Signed-off-by: Darren Lavender <darren.lavender@hp.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.com>
    Acked-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
    Signed-off-by: James Bottomley <JBottomley@Odin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74c79fedfaa37b15f0d96d517094c61dbfeebed7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 30 22:30:29 2015 +0200

    ALSA: hda - Fix MacBook Pro 5,2 quirk
    
    commit 649ccd08534ee26deb2e5b08509800d0e95167f5 upstream.
    
    MacBook Pro 5,2 with ALC889 codec had already a fixup entry, but this
    seems not working correctly, a fix for pin NID 0x15 is needed in
    addition.  It's equivalent with the fixup for MacBook Air 1,1, so use
    this instead.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102131
    Reported-and-tested-by: Jeffery Miller <jefferym@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f3d08db059a3274e6a18d96907a3fb0899f7db3
Author: Yao-Wen Mao <yaowen@google.com>
Date:   Wed Jul 29 15:13:54 2015 +0800

    ALSA: usb-audio: add dB range mapping for some devices
    
    commit 2d1cb7f658fb9c3ba8f9dab8aca297d4dfdec835 upstream.
    
    Add the correct dB ranges of Bose Companion 5 and Drangonfly DAC 1.2.
    
    Signed-off-by: Yao-Wen Mao <yaowen@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8938e3a1e5ddad512a4d68015b72fdc1776654ac
Author: Dominic Sacré <dominic.sacre@gmx.de>
Date:   Tue Jun 30 17:41:33 2015 +0200

    ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4
    
    commit 0689a86ae814f39af94a9736a0a5426dd82eb107 upstream.
    
    The Steinberg MI2 and MI4 interfaces are compatible with the USB class
    audio spec, but the MIDI part of the devices is reported as a vendor
    specific interface.
    
    This patch adds entries to quirks-table.h to recognize the MIDI
    endpoints. Audio functionality was already working and is unaffected by
    this change.
    
    Signed-off-by: Dominic Sacré <dominic.sacre@gmx.de>
    Signed-off-by: Albert Huitsing <albert@huitsing.nl>
    Acked-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe4aeb98a2df873f4921ae398b31b297d454a760
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Jul 16 14:10:17 2015 +0200

    genirq: Prevent resend to interrupts marked IRQ_NESTED_THREAD
    
    commit 75a06189fc508a2acf470b0b12710362ffb2c4b1 upstream.
    
    The resend mechanism happily calls the interrupt handler of interrupts
    which are marked IRQ_NESTED_THREAD from softirq context. This can
    result in crashes because the interrupt handler is not the proper way
    to invoke the device handlers. They must be invoked via
    handle_nested_irq.
    
    Prevent the resend even if the interrupt has no valid parent irq
    set. Its better to have a lost interrupt than a crashing machine.
    
    Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06d4d08d6c4ed66c85170b326c67c2d941613e40
Author: Alexey Brodkin <abrodkin@synopsys.com>
Date:   Mon Jul 13 10:25:17 2015 +0300

    ARC: make sure instruction_pointer() returns unsigned value
    
    commit f51e2f1911122879eefefa4c592dea8bf794b39c upstream.
    
    Currently instruction_pointer() returns pt_regs->ret and so return value
    is of type "long", which implicitly stands for "signed long".
    
    While that's perfectly fine when dealing with 32-bit values if return
    value of instruction_pointer() gets assigned to 64-bit variable sign
    extension may happen.
    
    And at least in one real use-case it happens already.
    In perf_prepare_sample() return value of perf_instruction_pointer()
    (which is an alias to instruction_pointer() in case of ARC) is assigned
    to (struct perf_sample_data)->ip (which type is "u64").
    
    And what we see if instuction pointer points to user-space application
    that in case of ARC lays below 0x8000_0000 "ip" gets set properly with
    leading 32 zeros. But if instruction pointer points to kernel address
    space that starts from 0x8000_0000 then "ip" is set with 32 leadig
    "f"-s. I.e. id instruction_pointer() returns 0x8100_0000, "ip" will be
    assigned with 0xffff_ffff__8100_0000. Which is obviously wrong.
    
    In particular that issuse broke output of perf, because perf was unable
    to associate addresses like 0xffff_ffff__8100_0000 with anything from
    /proc/kallsyms.
    
    That's what we used to see:
     ----------->8----------
      6.27%  ls       [unknown]                [k] 0xffffffff8046c5cc
      2.96%  ls       libuClibc-0.9.34-git.so  [.] memcpy
      2.25%  ls       libuClibc-0.9.34-git.so  [.] memset
      1.66%  ls       [unknown]                [k] 0xffffffff80666536
      1.54%  ls       libuClibc-0.9.34-git.so  [.] 0x000224d6
      1.18%  ls       libuClibc-0.9.34-git.so  [.] 0x00022472
     ----------->8----------
    
    With that change perf output looks much better now:
     ----------->8----------
      8.21%  ls       [kernel.kallsyms]        [k] memset
      3.52%  ls       libuClibc-0.9.34-git.so  [.] memcpy
      2.11%  ls       libuClibc-0.9.34-git.so  [.] malloc
      1.88%  ls       libuClibc-0.9.34-git.so  [.] memset
      1.64%  ls       [kernel.kallsyms]        [k] _raw_spin_unlock_irqrestore
      1.41%  ls       [kernel.kallsyms]        [k] __d_lookup_rcu
     ----------->8----------
    
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Cc: arc-linux-dev@synopsys.com
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efe5471fe4845bac5a642f2e05e24718cdddd5be
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Jul 6 17:58:19 2015 +0200

    s390/sclp: clear upper register halves in _sclp_print_early
    
    commit f9c87a6f46d508eae0d9ae640be98d50f237f827 upstream.
    
    If the kernel is compiled with gcc 5.1 and the XZ compression option
    the decompress_kernel function calls _sclp_print_early in 64-bit mode
    while the content of the upper register half of %r6 is non-zero.
    This causes a specification exception on the servc instruction in
    _sclp_servc.
    
    The _sclp_print_early function saves and restores the upper registers
    halves but it fails to clear them for the 31-bit code of the mini sclp
    driver.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca3e884098a49f631ad16cf2759ac8592cd4b812
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Wed Jul 8 02:42:38 2015 +0100

    freeing unlinked file indefinitely delayed
    
    commit 75a6f82a0d10ef8f13cd8fe7212911a0252ab99e upstream.
    
    	Normally opening a file, unlinking it and then closing will have
    the inode freed upon close() (provided that it's not otherwise busy and
    has no remaining links, of course).  However, there's one case where that
    does *not* happen.  Namely, if you open it by fhandle with cold dcache,
    then unlink() and close().
    
    	In normal case you get d_delete() in unlink(2) notice that dentry
    is busy and unhash it; on the final dput() it will be forcibly evicted from
    dcache, triggering iput() and inode removal.  In this case, though, we end
    up with *two* dentries - disconnected (created by open-by-fhandle) and
    regular one (used by unlink()).  The latter will have its reference to inode
    dropped just fine, but the former will not - it's considered hashed (it
    is on the ->s_anon list), so it will stay around until the memory pressure
    will finally do it in.  As the result, we have the final iput() delayed
    indefinitely.  It's trivial to reproduce -
    
    void flush_dcache(void)
    {
            system("mount -o remount,rw /");
    }
    
    static char buf[20 * 1024 * 1024];
    
    main()
    {
            int fd;
            union {
                    struct file_handle f;
                    char buf[MAX_HANDLE_SZ];
            } x;
            int m;
    
            x.f.handle_bytes = sizeof(x);
            chdir("/root");
            mkdir("foo", 0700);
            fd = open("foo/bar", O_CREAT | O_RDWR, 0600);
            close(fd);
            name_to_handle_at(AT_FDCWD, "foo/bar", &x.f, &m, 0);
            flush_dcache();
            fd = open_by_handle_at(AT_FDCWD, &x.f, O_RDWR);
            unlink("foo/bar");
            write(fd, buf, sizeof(buf));
            system("df .");			/* 20Mb eaten */
            close(fd);
            system("df .");			/* should've freed those 20Mb */
            flush_dcache();
            system("df .");			/* should be the same as #2 */
    }
    
    will spit out something like
    Filesystem     1K-blocks   Used Available Use% Mounted on
    /dev/root         322023 303843      1131 100% /
    Filesystem     1K-blocks   Used Available Use% Mounted on
    /dev/root         322023 303843      1131 100% /
    Filesystem     1K-blocks   Used Available Use% Mounted on
    /dev/root         322023 283282     21692  93% /
    - inode gets freed only when dentry is finally evicted (here we trigger
    than by remount; normally it would've happened in response to memory
    pressure hell knows when).
    
    Acked-by: J. Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f7fa1bc5fb4414a75ea451859154a9930e47daf
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Jul 6 23:18:37 2015 +0300

    mm: avoid setting up anonymous pages into file mapping
    
    commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream.
    
    Reading page fault handler code I've noticed that under right
    circumstances kernel would map anonymous pages into file mappings: if
    the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated
    on ->mmap(), kernel would handle page fault to not populated pte with
    do_anonymous_page().
    
    Let's change page fault handler to use do_anonymous_page() only on
    anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not
    shared.
    
    For file mappings without vm_ops->fault() or shred VMA without vm_ops,
    page fault on pte_none() entry would lead to SIGBUS.
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>