commit 804a935963a91acd1764ba914f825dd2a29c5871
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 15 09:57:56 2017 +0800

    Linux 4.4.54

commit 4cdfa660c82b57828ffcca94950eccc9458e18e4
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Wed Feb 8 18:30:56 2017 -0700

    drivers: hv: Turn off write permission on the hypercall page
    
    commit 372b1e91343e657a7cc5e2e2bcecd5140ac28119 upstream.
    
    The hypercall page only needs to be executable but currently it is setup to
    be writable as well. Fix the issue.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Reported-by: Stephen Hemminger <stephen@networkplumber.org>
    Tested-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8353f338def1df3b58150cf1d6f42d1a51902b55
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date:   Thu Mar 9 16:17:37 2017 -0800

    fat: fix using uninitialized fields of fat_inode/fsinfo_inode
    
    commit c0d0e351285161a515396b7b1ee53ec9ffd97e3c upstream.
    
    Recently fallocate patch was merged and it uses
    MSDOS_I(inode)->mmu_private at fat_evict_inode().  However,
    fat_inode/fsinfo_inode that was introduced in past didn't initialize
    MSDOS_I(inode) properly.
    
    With those combinations, it became the cause of accessing random entry
    in FAT area.
    
    Link: http://lkml.kernel.org/r/87pohrj4i8.fsf@mail.parknet.co.jp
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Reported-by: Moreno Bartalucci <moreno.bartalucci@tecnorama.it>
    Tested-by: Moreno Bartalucci <moreno.bartalucci@tecnorama.it>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13ef90e1bb7963ec2fb9d3680fe418a4b7dedfa3
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jan 16 12:06:09 2017 +0100

    libceph: use BUG() instead of BUG_ON(1)
    
    commit d24cdcd3e40a6825135498e11c20c7976b9bf545 upstream.
    
    I ran into this compile warning, which is the result of BUG_ON(1)
    not always leading to the compiler treating the code path as
    unreachable:
    
        include/linux/ceph/osdmap.h: In function 'ceph_can_shift_osds':
        include/linux/ceph/osdmap.h:62:1: error: control reaches end of non-void function [-Werror=return-type]
    
    Using BUG() here avoids the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7952b6490bbce45e078c8c0e669df7a0a8f8948a
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Dec 2 15:29:04 2016 +0100

    drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
    
    commit bb98e72adaf9d19719aba35f802d4836f5d5176c upstream.
    
    On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
    i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
    Once the i915 driver has successfully loaded, the panel can be disabled /
    enabled without hitting this issue.
    
    The getting stuck is caused by vlv_init_display_clock_gating() clearing
    the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
    chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled
    driving the DSI LCD by the BIOS.
    
    Clearing this bit while DSI is in use is a known issue and
    intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
    as appropriate.
    
    This commit modifies vlv_init_display_clock_gating() to leave the
    DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck.
    
    Changes in v2:
    -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and
    comment
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    (cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: River Zhou <riverzhou2000@163.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77fec8bc7a0fbee3bf5893d8c1ce755c029f2b40
Author: Alexander Aring <aar@pengutronix.de>
Date:   Thu Sep 1 11:24:57 2016 +0200

    fakelb: fix schedule while atomic
    
    commit bdca1fd9a6df745857e23c6056494b7fe062b4e6 upstream.
    
    This patch changes the spinlock to mutex for the available fakelb phy
    list. When holding the spinlock the ieee802154_unregister_hw is called
    which holding the rtnl_mutex, in that case we get a "BUG: sleeping function
    called from invalid context" error. We simple change the spinlock to
    mutex which allows to hold the rtnl lock there.
    
    Signed-off-by: Alexander Aring <aar@pengutronix.de>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb5b96344ed378a1d5b8cf3bd149bb86919f3b9f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Feb 8 02:46:01 2017 +0300

    drm/atomic: fix an error code in mode_fixup()
    
    commit f9ad86e42d0303eeb8e0d41bb208153022ebd9d2 upstream.
    
    Having "ret" be a bool type works for everything except
    ret = funcs->atomic_check().  The other functions all return zero on
    error but ->atomic_check() returns negative error codes.  We want to
    propagate the error code but instead we return 1.
    
    I found this bug with static analysis and I don't know if it affects
    run time.
    
    Fixes: 4cd4df8080a3 ("drm/atomic: Add ->atomic_check() to encoder helpers")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170207234601.GA23981@mwanda
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59fc34fc69066bfabf8bed21f4ce5bf312e68bb3
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Jan 25 17:21:31 2017 +0900

    drm/ttm: Make sure BOs being swapped out are cacheable
    
    commit 239ac65fa5ffab71adf66e642750f940e7241d99 upstream.
    
    The current caching state may not be tt_cached, even though the
    placement contains TTM_PL_FLAG_CACHED, because placement can contain
    multiple caching flags. Trying to swap out such a BO would trip up the
    
            BUG_ON(ttm->caching_state != tt_cached);
    
    in ttm_tt_swapout.
    
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>.
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36fd36b900b9382af54a1e49a81cd99663b83eda
Author: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Date:   Mon Feb 20 16:25:45 2017 +0100

    drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
    
    commit 36fc579761b50784b63dafd0f2e796b659e0f5ee upstream.
    
    Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
    1.1.
    
    When a sink that supports deep color is connected to the output, the
    receiver will send EDIDs that advertise this capability, even if it
    isn't possible with HDMI versions earlier than 1.3.
    
    Currently the kernel is assuming that deep color is possible and the
    sink displays an error.
    
    This quirk will make sure that deep color isn't used with this
    particular receiver.
    
    Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
    Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170220152545.13153-1-tomeu.vizoso@collabora.com
    Cc: Matt Horan <matt@matthoran.com>
    Tested-by: Matt Horan <matt@matthoran.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9cfd5517b309513e50d80b89eaae98a82a2c3b1
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Thu Feb 23 15:52:33 2017 +0800

    drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS
    
    commit 3856081eede297b617560b85e948cfb00bb395ec upstream.
    
    The current POST code for the AST2300/2400 family doesn't work properly
    if the chip hasn't been initialized previously by either the BMC own FW
    or the VBIOS. This fixes it.
    
    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Tested-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Acked-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93eab4f5259485e9cad0339a298b6da1dd2e6e40
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Wed Feb 22 15:14:19 2017 +1100

    drm/ast: Call open_key before enable_mmio in POST code
    
    commit 9bb92f51558f2ef5f56c257bdcea0588f31d857e upstream.
    
    open_key enables access the registers used by enable_mmio
    
    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Joel Stanley <joel@jms.id.au>
    Tested-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b787652386e26c7974092f11bd477126b0d53ce
Author: Y.C. Chen <yc_chen@aspeedtech.com>
Date:   Wed Feb 22 15:10:50 2017 +1100

    drm/ast: Fix test for VGA enabled
    
    commit 905f21a49d388de3e99438235f3301cabf0c0ef4 upstream.
    
    The test to see if VGA was already enabled is doing an unnecessary
    second test from a register that may or may not have been initialized
    to a valid value. Remove it.
    
    Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Joel Stanley <joel@jms.id.au>
    Tested-by: Y.C. Chen <yc_chen@aspeedtech.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d80ac62b609bce00b78a656b7cdde2d8f587345
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Feb 10 00:00:52 2017 -0500

    drm/amdgpu: add more cases to DCE11 possible crtc mask setup
    
    commit 4ce3bd45b351633f2a0512c587f7fcba2ce044e8 upstream.
    
    Add cases for asics with 3 and 5 crtcs.  Fixes an artificial
    limitation on asics with 3 or 5 crtcs.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=99744
    
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.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 8650af261d6c119062da542c70881653db0a0b20
Author: Matt Chen <matt.chen@intel.com>
Date:   Sun Jan 22 02:16:58 2017 +0800

    mac80211: flush delayed work when entering suspend
    
    commit a9e9200d8661c1a0be8c39f93deb383dc940de35 upstream.
    
    The issue was found when entering suspend and resume.
    It triggers a warning in:
    mac80211/key.c: ieee80211_enable_keys()
    ...
    WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt ||
                 sdata->crypto_tx_tailroom_pending_dec);
    ...
    
    It points out sdata->crypto_tx_tailroom_pending_dec isn't cleaned up successfully
    in a delayed_work during suspend. Add a flush_delayed_work to fix it.
    
    Signed-off-by: Matt Chen <matt.chen@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21096328c97e707f2190b26a06d8b805551a543d
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Tue Jan 3 09:37:34 2017 -0800

    xtensa: move parse_tag_fdt out of #ifdef CONFIG_BLK_DEV_INITRD
    
    commit 4ab18701c66552944188dbcd0ce0012729baab84 upstream.
    
    FDT tag parsing is not related to whether BLK_DEV_INITRD is configured
    or not, move it out of the corresponding #ifdef/#endif block.
    This fixes passing external FDT to the kernel configured w/o
    BLK_DEV_INITRD support.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ef213d6219456ea5e4df7d201b4a3384e06783b
Author: Clemens Gruber <clemens.gruber@pqgruber.com>
Date:   Tue Dec 13 16:52:50 2016 +0100

    pwm: pca9685: Fix period change with same duty cycle
    
    commit 8d254a340efb12b40c4c1ff25a48a4f48f7bbd6b upstream.
    
    When first implementing support for changing the output frequency, an
    optimization was added to continue the PWM after changing the prescaler
    without having to reprogram the ON and OFF registers for the duty cycle,
    in case the duty cycle stayed the same. This was flawed, because we
    compared the absolute value of the duty cycle in nanoseconds instead of
    the ratio to the period.
    
    Fix the problem by removing the shortcut.
    
    Fixes: 01ec8472009c9 ("pwm-pca9685: Support changing the output frequency")
    Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1c924e85a937de5e1d0dd6c47f094b089952e0c
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Feb 11 10:37:38 2017 -0500

    nlm: Ensure callback code also checks that the files match
    
    commit 251af29c320d86071664f02c76f0d063a19fefdf upstream.
    
    It is not sufficient to just check that the lock pids match when
    granting a callback, we also need to ensure that we're granting
    the callback on the right file.
    
    Reported-by: Pankaj Singh <psingh.ait@gmail.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca739e3fd7dc803d526ea5bb9b80c0d07fbca55f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Feb 22 22:06:32 2017 -0800

    target: Fix NULL dereference during LUN lookup + active I/O shutdown
    
    commit bd4e2d2907fa23a11d46217064ecf80470ddae10 upstream.
    
    When transport_clear_lun_ref() is shutting down a se_lun via
    configfs with new I/O in-flight, it's possible to trigger a
    NULL pointer dereference in transport_lookup_cmd_lun() due
    to the fact percpu_ref_get() doesn't do any __PERCPU_REF_DEAD
    checking before incrementing lun->lun_ref.count after
    lun->lun_ref has switched to atomic_t mode.
    
    This results in a NULL pointer dereference as LUN shutdown
    code in core_tpg_remove_lun() continues running after the
    existing ->release() -> core_tpg_lun_ref_release() callback
    completes, and clears the RCU protected se_lun->lun_se_dev
    pointer.
    
    During the OOPs, the state of lun->lun_ref in the process
    which triggered the NULL pointer dereference looks like
    the following on v4.1.y stable code:
    
    struct se_lun {
      lun_link_magic = 4294932337,
      lun_status = TRANSPORT_LUN_STATUS_FREE,
    
      .....
    
      lun_se_dev = 0x0,
      lun_sep = 0x0,
    
      .....
    
      lun_ref = {
        count = {
          counter = 1
        },
        percpu_count_ptr = 3,
        release = 0xffffffffa02fa1e0 <core_tpg_lun_ref_release>,
        confirm_switch = 0x0,
        force_atomic = false,
        rcu = {
          next = 0xffff88154fa1a5d0,
          func = 0xffffffff8137c4c0 <percpu_ref_switch_to_atomic_rcu>
        }
      }
    }
    
    To address this bug, use percpu_ref_tryget_live() to ensure
    once __PERCPU_REF_DEAD is visable on all CPUs and ->lun_ref
    has switched to atomic_t, all new I/Os will fail to obtain
    a new lun->lun_ref reference.
    
    Also use an explicit percpu_ref_kill_and_confirm() callback
    to block on ->lun_ref_comp to allow the first stage and
    associated RCU grace period to complete, and then block on
    ->lun_ref_shutdown waiting for the final percpu_ref_put()
    to drop the last reference via transport_lun_remove_cmd()
    before continuing with core_tpg_remove_lun() shutdown.
    
    Reported-by: Rob Millner <rlm@daterainc.com>
    Tested-by: Rob Millner <rlm@daterainc.com>
    Cc: Rob Millner <rlm@daterainc.com>
    Tested-by: Vaibhav Tandon <vst@datera.io>
    Cc: Vaibhav Tandon <vst@datera.io>
    Tested-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05a9143edb47e7799f191f1015f56eb2dacfee0d
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Feb 14 10:09:40 2017 -0500

    ceph: remove req from unsafe list when unregistering it
    
    commit df963ea8a082d31521a120e8e31a29ad8a1dc215 upstream.
    
    There's no reason a request should ever be on a s_unsafe list but not
    in the request tree.
    
    Link: http://tracker.ceph.com/issues/18474
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Reviewed-by: Yan, Zheng <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 485171b1ee8c7cc74cff9881b92b178b1c709663
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Feb 7 12:05:25 2017 -0500

    ktest: Fix child exit code processing
    
    commit 32677207dcc5e594254b7fb4fb2352b1755b1d5b upstream.
    
    The child_exit errno needs to be shifted by 8 bits to compare against the
    return values for the bisect variables.
    
    Fixes: c5dacb88f0a64 ("ktest: Allow overriding bisect test results")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 696255449b89af5487bce53b1a65eddedc72aeff
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Tue Feb 14 10:56:31 2017 -0800

    IB/srp: Fix race conditions related to task management
    
    commit 0a6fdbdeb1c25e31763c1fb333fa2723a7d2aba6 upstream.
    
    Avoid that srp_process_rsp() overwrites the status information
    in ch if the SRP target response timed out and processing of
    another task management function has already started. Avoid that
    issuing multiple task management functions concurrently triggers
    list corruption. This patch prevents that the following stack
    trace appears in the system log:
    
    WARNING: CPU: 8 PID: 9269 at lib/list_debug.c:52 __list_del_entry_valid+0xbc/0xc0
    list_del corruption. prev->next should be ffffc90004bb7b00, but was ffff8804052ecc68
    CPU: 8 PID: 9269 Comm: sg_reset Tainted: G        W       4.10.0-rc7-dbg+ #3
    Call Trace:
     dump_stack+0x68/0x93
     __warn+0xc6/0xe0
     warn_slowpath_fmt+0x4a/0x50
     __list_del_entry_valid+0xbc/0xc0
     wait_for_completion_timeout+0x12e/0x170
     srp_send_tsk_mgmt+0x1ef/0x2d0 [ib_srp]
     srp_reset_device+0x5b/0x110 [ib_srp]
     scsi_ioctl_reset+0x1c7/0x290
     scsi_ioctl+0x12a/0x420
     sd_ioctl+0x9d/0x100
     blkdev_ioctl+0x51e/0x9f0
     block_ioctl+0x38/0x40
     do_vfs_ioctl+0x8f/0x700
     SyS_ioctl+0x3c/0x70
     entry_SYSCALL_64_fastpath+0x18/0xad
    
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: Israel Rukshin <israelr@mellanox.com>
    Cc: Max Gurtovoy <maxg@mellanox.com>
    Cc: Laurence Oberman <loberman@redhat.com>
    Cc: Steve Feeley <Steve.Feeley@sandisk.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 944690cdb5f48d03842365b7359fe090d6c2b1fa
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Tue Feb 14 10:56:30 2017 -0800

    IB/srp: Avoid that duplicate responses trigger a kernel bug
    
    commit 6cb72bc1b40bb2c1750ee7a5ebade93bed49a5fb upstream.
    
    After srp_process_rsp() returns there is a short time during which
    the scsi_host_find_tag() call will return a pointer to the SCSI
    command that is being completed. If during that time a duplicate
    response is received, avoid that the following call stack appears:
    
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: srp_recv_done+0x450/0x6b0 [ib_srp]
    Oops: 0000 [#1] SMP
    CPU: 10 PID: 0 Comm: swapper/10 Not tainted 4.10.0-rc7-dbg+ #1
    Call Trace:
     <IRQ>
     __ib_process_cq+0x4b/0xd0 [ib_core]
     ib_poll_handler+0x1d/0x70 [ib_core]
     irq_poll_softirq+0xba/0x120
     __do_softirq+0xba/0x4c0
     irq_exit+0xbe/0xd0
     smp_apic_timer_interrupt+0x38/0x50
     apic_timer_interrupt+0x90/0xa0
     </IRQ>
    RIP: srp_recv_done+0x450/0x6b0 [ib_srp] RSP: ffff88046f483e20
    
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: Israel Rukshin <israelr@mellanox.com>
    Cc: Max Gurtovoy <maxg@mellanox.com>
    Cc: Laurence Oberman <loberman@redhat.com>
    Cc: Steve Feeley <Steve.Feeley@sandisk.com>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb4a21dcb6fb57892eea7c941fdfd57e55ba5dbe
Author: Erez Shitrit <erezsh@mellanox.com>
Date:   Wed Feb 1 19:10:05 2017 +0200

    IB/IPoIB: Add destination address when re-queue packet
    
    commit 2b0841766a898aba84630fb723989a77a9d3b4e6 upstream.
    
    When sending packet to destination that was not resolved yet
    via path query, the driver keeps the skb and tries to re-send it
    again when the path is resolved.
    
    But when re-sending via dev_queue_xmit the kernel doesn't call
    to dev_hard_header, so IPoIB needs to keep 20 bytes in the skb
    and to put the destination address inside them.
    
    In that way the dev_start_xmit will have the correct destination,
    and the driver won't take the destination from the skb->data, while
    nothing exists there, which causes to packet be be dropped.
    
    The test flow is:
    1. Run the SM on remote node,
    2. Restart the driver.
    4. Ping some destination,
    3. Observe that first ICMP request will be dropped.
    
    Fixes: fc791b633515 ("IB/ipoib: move back IB LL address into the hard header")
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Signed-off-by: Noa Osherovich <noaos@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Tested-by: Yuval Shaia <yuval.shaia@oracle.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10beca53745eff651209fbd6d8ddbbc0f46c30a4
Author: Feras Daoud <ferasda@mellanox.com>
Date:   Wed Dec 28 14:47:23 2016 +0200

    IB/ipoib: Fix deadlock between rmmod and set_mode
    
    commit 0a0007f28304cb9fc87809c86abb80ec71317f20 upstream.
    
    When calling set_mode from sys/fs, the call flow locks the sys/fs lock
    first and then tries to lock rtnl_lock (when calling ipoib_set_mod).
    On the other hand, the rmmod call flow takes the rtnl_lock first
    (when calling unregister_netdev) and then tries to take the sys/fs
    lock. Deadlock a->b, b->a.
    
    The problem starts when ipoib_set_mod frees it's rtnl_lck and tries
    to get it after that.
    
        set_mod:
        [<ffffffff8104f2bd>] ? check_preempt_curr+0x6d/0x90
        [<ffffffff814fee8e>] __mutex_lock_slowpath+0x13e/0x180
        [<ffffffff81448655>] ? __rtnl_unlock+0x15/0x20
        [<ffffffff814fed2b>] mutex_lock+0x2b/0x50
        [<ffffffff81448675>] rtnl_lock+0x15/0x20
        [<ffffffffa02ad807>] ipoib_set_mode+0x97/0x160 [ib_ipoib]
        [<ffffffffa02b5f5b>] set_mode+0x3b/0x80 [ib_ipoib]
        [<ffffffff8134b840>] dev_attr_store+0x20/0x30
        [<ffffffff811f0fe5>] sysfs_write_file+0xe5/0x170
        [<ffffffff8117b068>] vfs_write+0xb8/0x1a0
        [<ffffffff8117ba81>] sys_write+0x51/0x90
        [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
    
        rmmod:
        [<ffffffff81279ffc>] ? put_dec+0x10c/0x110
        [<ffffffff8127a2ee>] ? number+0x2ee/0x320
        [<ffffffff814fe6a5>] schedule_timeout+0x215/0x2e0
        [<ffffffff8127cc04>] ? vsnprintf+0x484/0x5f0
        [<ffffffff8127b550>] ? string+0x40/0x100
        [<ffffffff814fe323>] wait_for_common+0x123/0x180
        [<ffffffff81060250>] ? default_wake_function+0x0/0x20
        [<ffffffff8119661e>] ? ifind_fast+0x5e/0xb0
        [<ffffffff814fe43d>] wait_for_completion+0x1d/0x20
        [<ffffffff811f2e68>] sysfs_addrm_finish+0x228/0x270
        [<ffffffff811f2fb3>] sysfs_remove_dir+0xa3/0xf0
        [<ffffffff81273f66>] kobject_del+0x16/0x40
        [<ffffffff8134cd14>] device_del+0x184/0x1e0
        [<ffffffff8144e59b>] netdev_unregister_kobject+0xab/0xc0
        [<ffffffff8143c05e>] rollback_registered+0xae/0x130
        [<ffffffff8143c102>] unregister_netdevice+0x22/0x70
        [<ffffffff8143c16e>] unregister_netdev+0x1e/0x30
        [<ffffffffa02a91b0>] ipoib_remove_one+0xe0/0x120 [ib_ipoib]
        [<ffffffffa01ed95f>] ib_unregister_device+0x4f/0x100 [ib_core]
        [<ffffffffa021f5e1>] mlx4_ib_remove+0x41/0x180 [mlx4_ib]
        [<ffffffffa01ab771>] mlx4_remove_device+0x71/0x90 [mlx4_core]
    
    Fixes: 862096a8bbf8 ("IB/ipoib: Add more rtnl_link_ops callbacks")
    Cc: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 839d42687dfce0ed0ea2c6bd8d707cc0e276fbe7
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Jan 20 18:28:35 2017 +1300

    mnt: Tuck mounts under others instead of creating shadow/side mounts.
    
    commit 1064f874abc0d05eeed8993815f584d847b72486 upstream.
    
    Ever since mount propagation was introduced in cases where a mount in
    propagated to parent mount mountpoint pair that is already in use the
    code has placed the new mount behind the old mount in the mount hash
    table.
    
    This implementation detail is problematic as it allows creating
    arbitrary length mount hash chains.
    
    Furthermore it invalidates the constraint maintained elsewhere in the
    mount code that a parent mount and a mountpoint pair will have exactly
    one mount upon them.  Making it hard to deal with and to talk about
    this special case in the mount code.
    
    Modify mount propagation to notice when there is already a mount at
    the parent mount and mountpoint where a new mount is propagating to
    and place that preexisting mount on top of the new mount.
    
    Modify unmount propagation to notice when a mount that is being
    unmounted has another mount on top of it (and no other children), and
    to replace the unmounted mount with the mount on top of it.
    
    Move the MNT_UMUONT test from __lookup_mnt_last into
    __propagate_umount as that is the only call of __lookup_mnt_last where
    MNT_UMOUNT may be set on any mount visible in the mount hash table.
    
    These modifications allow:
     - __lookup_mnt_last to be removed.
     - attach_shadows to be renamed __attach_mnt and its shadow
       handling to be removed.
     - commit_tree to be simplified
     - copy_tree to be simplified
    
    The result is an easier to understand tree of mounts that does not
    allow creation of arbitrary length hash chains in the mount hash table.
    
    The result is also a very slight userspace visible difference in semantics.
    The following two cases now behave identically, where before order
    mattered:
    
    case 1: (explicit user action)
            B is a slave of A
            mount something on A/a , it will propagate to B/a
            and than mount something on B/a
    
    case 2: (tucked mount)
            B is a slave of A
            mount something on B/a
            and than mount something on A/a
    
    Histroically umount A/a would fail in case 1 and succeed in case 2.
    Now umount A/a succeeds in both configurations.
    
    This very small change in semantics appears if anything to be a bug
    fix to me and my survey of userspace leads me to believe that no programs
    will notice or care of this subtle semantic change.
    
    v2: Updated to mnt_change_mountpoint to not call dput or mntput
    and instead to decrement the counts directly.  It is guaranteed
    that there will be other references when mnt_change_mountpoint is
    called so this is safe.
    
    v3: Moved put_mountpoint under mount_lock in attach_recursive_mnt
        As the locking in fs/namespace.c changed between v2 and v3.
    
    v4: Reworked the logic in propagate_mount_busy and __propagate_umount
        that detects when a mount completely covers another mount.
    
    v5: Removed unnecessary tests whose result is alwasy true in
        find_topper and attach_recursive_mnt.
    
    v6: Document the user space visible semantic difference.
    
    Fixes: b90fa9ae8f51 ("[PATCH] shared mount handling: bind and rbind")
    Tested-by: Andrei Vagin <avagin@virtuozzo.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b57ffb2a8466a7628b316c8e3a5ce34b8ee4e519
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Tue Feb 21 11:28:01 2017 +0100

    net: mvpp2: fix DMA address calculation in mvpp2_txq_inc_put()
    
    commit 239a3b663647869330955ec59caac0100ef9b60a upstream.
    
    When TX descriptors are filled in, the buffer DMA address is split
    between the tx_desc->buf_phys_addr field (high-order bits) and
    tx_desc->packet_offset field (5 low-order bits).
    
    However, when we re-calculate the DMA address from the TX descriptor in
    mvpp2_txq_inc_put(), we do not take tx_desc->packet_offset into
    account. This means that when the DMA address is not aligned on a 32
    bytes boundary, we end up calling dma_unmap_single() with a DMA address
    that was not the one returned by dma_map_single().
    
    This inconsistency is detected by the kernel when DMA_API_DEBUG is
    enabled. We fix this problem by properly calculating the DMA address in
    mvpp2_txq_inc_put().
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 376a12eb7f608fad96b13fab3f151eb4c9b40c7c
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Sun Feb 5 23:03:18 2017 +0100

    s390: use correct input data address for setup_randomness
    
    commit 4920e3cf77347d7d7373552d4839e8d832321313 upstream.
    
    The current implementation of setup_randomness uses the stack address
    and therefore the pointer to the SYSIB 3.2.2 block as input data
    address. Furthermore the length of the input data is the number of
    virtual-machine description blocks which is typically one.
    
    This means that typically a single zero byte is fed to
    add_device_randomness.
    
    Fix both of these and use the address of the first virtual machine
    description block as input data address and also use the correct
    length.
    
    Fixes: bcfcbb6bae64 ("s390: add system information as device randomness")
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 296f7bd7f1dbd2379489ea779779ef437d9e6c6f
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Sat Feb 4 11:40:36 2017 +0100

    s390: make setup_randomness work
    
    commit da8fd820f389a0e29080b14c61bf5cf1d8ef5ca1 upstream.
    
    Commit bcfcbb6bae64 ("s390: add system information as device
    randomness") intended to add some virtual machine specific information
    to the randomness pool.
    
    Unfortunately it uses the page allocator before it is ready to use. In
    result the page allocator always returns NULL and the setup_randomness
    function never adds anything to the randomness pool.
    
    To fix this use memblock_alloc and memblock_free instead.
    
    Fixes: bcfcbb6bae64 ("s390: add system information as device randomness")
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cf431dbd8f78d4e78d4aa3ef4fb453cd71e2978
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Fri Feb 24 07:43:51 2017 +0100

    s390: TASK_SIZE for kernel threads
    
    commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.
    
    Return a sensible value if TASK_SIZE if called from a kernel thread.
    
    This gets us around an issue with copy_mount_options that does a magic
    size calculation "TASK_SIZE - (unsigned long)data" while in a kernel
    thread and data pointing to kernel space.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 792bd1fb5b0338232e47412bce2a9b6f0f1fbdaf
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Mon Jan 30 15:52:14 2017 +0100

    s390/dcssblk: fix device size calculation in dcssblk_direct_access()
    
    commit a63f53e34db8b49675448d03ae324f6c5bc04fe6 upstream.
    
    Since commit dd22f551 "block: Change direct_access calling convention",
    the device size calculation in dcssblk_direct_access() is off-by-one.
    This results in bdev_direct_access() always returning -ENXIO because the
    returned value is not page aligned.
    
    Fix this by adding 1 to the dev_sz calculation.
    
    Fixes: dd22f551 ("block: Change direct_access calling convention")
    Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec50c80c780152d2058c23d9e246fc81f73742da
Author: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date:   Mon Nov 21 13:37:48 2016 +0100

    s390/qdio: clear DSCI prior to scanning multiple input queues
    
    commit 1e4a382fdc0ba8d1a85b758c0811de3a3631085e upstream.
    
    For devices with multiple input queues, tiqdio_call_inq_handlers()
    iterates over all input queues and clears the device's DSCI
    during each iteration. If the DSCI is re-armed during one
    of the later iterations, we therefore do not scan the previous
    queues again.
    The re-arming also raises a new adapter interrupt. But its
    handler does not trigger a rescan for the device, as the DSCI
    has already been erroneously cleared.
    This can result in queue stalls on devices with multiple
    input queues.
    
    Fix it by clearing the DSCI just once, prior to scanning the queues.
    
    As the code is moved in front of the loop, we also need to access
    the DSCI directly (ie irq->dsci) instead of going via each queue's
    parent pointer to the same irq. This is not a functional change,
    and a follow-up patch will clean up the other users.
    
    In practice, this bug only affects CQ-enabled HiperSockets devices,
    ie. devices with sysfs-attribute "hsuid" set. Setting a hsuid is
    needed for AF_IUCV socket applications that use HiperSockets
    communication.
    
    Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks")
    Reviewed-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00cfdbf5ab6e3285bb4589e6e5d241c8db8cd3ed
Author: Dmitry Tunin <hanipouspilot@gmail.com>
Date:   Thu Jan 5 13:19:53 2017 +0300

    Bluetooth: Add another AR3012 04ca:3018 device
    
    commit 441ad62d6c3f131f1dbd7dcdd9cbe3f74dbd8501 upstream.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#=  5 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=3018 Rev=00.01
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cae929bd8d807457997bec4e9fbc61885cc582f7
Author: Chao Peng <chao.p.peng@linux.intel.com>
Date:   Tue Feb 21 03:50:01 2017 -0500

    KVM: VMX: use correct vmcs_read/write for guest segment selector/base
    
    commit 96794e4ed4d758272c486e1529e431efb7045265 upstream.
    
    Guest segment selector is 16 bit field and guest segment base is natural
    width field. Fix two incorrect invocations accordingly.
    
    Without this patch, build fails when aggressive inlining is used with ICC.
    
    Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a3df0418d90d7be1abf8e41191c3caa26f2ad4e
Author: Janosch Frank <frankja@linux.vnet.ibm.com>
Date:   Thu Feb 2 16:39:31 2017 +0100

    KVM: s390: Disable dirty log retrieval for UCONTROL guests
    
    commit e1e8a9624f7ba8ead4f056ff558ed070e86fa747 upstream.
    
    User controlled KVM guests do not support the dirty log, as they have
    no single gmap that we can check for changes.
    
    As they have no single gmap, kvm->arch.gmap is NULL and all further
    referencing to it for dirty checking will result in a NULL
    dereference.
    
    Let's return -EINVAL if a caller tries to sync dirty logs for a
    UCONTROL guest.
    
    Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
    Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
    Reported-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b34572e98f1b0d0df4ea084347b89b5a20fbede
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Fri Feb 3 20:25:00 2017 +0000

    serial: 8250_pci: Add MKS Tenta SCOM-0800 and SCOM-0801 cards
    
    commit 1c9c858e2ff8ae8024a3d75d2ed080063af43754 upstream.
    
    The MKS Instruments SCOM-0800 and SCOM-0801 cards (originally by Tenta
    Technologies) are 3U CompactPCI serial cards with 4 and 8 serial ports,
    respectively.  The first 4 ports are implemented by an OX16PCI954 chip,
    and the second 4 ports are implemented by an OX16C954 chip on a local
    bus, bridged by the second PCI function of the OX16PCI954.  The ports
    are jumper-selectable as RS-232 and RS-422/485, and the UARTs use a
    non-standard oscillator frequency of 20 MHz (base_baud = 1250000).
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 999853d941b99ca2ac4a331552c388e2603a9b1d
Author: Alexander Popov <alex.popov@linux.com>
Date:   Tue Feb 28 19:54:40 2017 +0300

    tty: n_hdlc: get rid of racy n_hdlc.tbuf
    
    commit 82f2341c94d270421f383641b7cd670e474db56b upstream.
    
    Currently N_HDLC line discipline uses a self-made singly linked list for
    data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
    an error.
    
    The commit be10eb7589337e5defbe214dae038a53dd21add8
    ("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
    After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
    one data buffer to tx_free_buf_list twice. That causes double free in
    n_hdlc_release().
    
    Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
    in case of tx error put current data buffer after the head of tx_buf_list.
    
    Signed-off-by: Alexander Popov <alex.popov@linux.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59c4d7838e3e526f3e253c536727e3539321fbd6
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Nov 26 19:28:26 2015 +0100

    TTY: n_hdlc, fix lockdep false positive
    
    commit e9b736d88af1a143530565929390cadf036dc799 upstream.
    
    The class of 4 n_hdls buf locks is the same because a single function
    n_hdlc_buf_list_init is used to init all the locks. But since
    flush_tx_queue takes n_hdlc->tx_buf_list.spinlock and then calls
    n_hdlc_buf_put which takes n_hdlc->tx_free_buf_list.spinlock, lockdep
    emits a warning:
    =============================================
    [ INFO: possible recursive locking detected ]
    4.3.0-25.g91e30a7-default #1 Not tainted
    ---------------------------------------------
    a.out/1248 is trying to acquire lock:
     (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
    
    but task is already holding lock:
     (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&(&list->spinlock)->rlock);
      lock(&(&list->spinlock)->rlock);
    
     *** DEADLOCK ***
    
     May be due to missing lock nesting notation
    
    2 locks held by a.out/1248:
     #0:  (&tty->ldisc_sem){++++++}, at: [<ffffffff814c9eb0>] tty_ldisc_ref_wait+0x20/0x50
     #1:  (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
    ...
    Call Trace:
    ...
     [<ffffffff81738fd0>] _raw_spin_lock_irqsave+0x50/0x70
     [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
     [<ffffffffa01fdc24>] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc]
     [<ffffffff814c25c1>] tty_ioctl+0x3f1/0xe40
    ...
    
    Fix it by initializing the spin_locks separately. This removes also
    reduntand memset of a freshly kzallocated space.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>