commit efcfbfb1d8bf756d1b58fe215bf4e419d176435b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 27 15:08:24 2017 -0700

    Linux 4.9.40

commit 91af5f04cd5b498ccafa1fa554be8d22e953bc82
Author: Greg Hackmann <ghackmann@google.com>
Date:   Mon Jul 24 10:19:24 2017 -0700

    alarmtimer: don't rate limit one-shot timers
    
    Commit ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") sets a
    minimum bound on the alarm timer interval.  This minimum bound shouldn't
    be applied if the interval is 0.  Otherwise, one-shot timers will be
    converted into periodic ones.
    
    Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals")
    Reported-by: Ben Fennema <fennema@google.com>
    Signed-off-by: Greg Hackmann <ghackmann@google.com>
    Cc: stable@vger.kernel.org
    Cc: John Stultz <john.stultz@linaro.org>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 919e481152ce86bf1960a71b39a29ef643aaff03
Author: Chunyu Hu <chuhu@redhat.com>
Date:   Thu Jul 20 18:36:09 2017 +0800

    tracing: Fix kmemleak in instance_rmdir
    
    commit db9108e054700c96322b0f0028546aa4e643cf0b upstream.
    
    Hit the kmemleak when executing instance_rmdir, it forgot releasing
    mem of tracing_cpumask. With this fix, the warn does not appear any
    more.
    
    unreferenced object 0xffff93a8dfaa7c18 (size 8):
      comm "mkdir", pid 1436, jiffies 4294763622 (age 9134.308s)
      hex dump (first 8 bytes):
        ff ff ff ff ff ff ff ff                          ........
      backtrace:
        [<ffffffff88b6567a>] kmemleak_alloc+0x4a/0xa0
        [<ffffffff8861ea41>] __kmalloc_node+0xf1/0x280
        [<ffffffff88b505d3>] alloc_cpumask_var_node+0x23/0x30
        [<ffffffff88b5060e>] alloc_cpumask_var+0xe/0x10
        [<ffffffff88571ab0>] instance_mkdir+0x90/0x240
        [<ffffffff886e5100>] tracefs_syscall_mkdir+0x40/0x70
        [<ffffffff886565c9>] vfs_mkdir+0x109/0x1b0
        [<ffffffff8865b1d0>] SyS_mkdir+0xd0/0x100
        [<ffffffff88403857>] do_syscall_64+0x67/0x150
        [<ffffffff88b710e7>] return_from_SYSCALL_64+0x0/0x6a
        [<ffffffffffffffff>] 0xffffffffffffffff
    
    Link: http://lkml.kernel.org/r/1500546969-12594-1-git-send-email-chuhu@redhat.com
    
    Fixes: ccfe9e42e451 ("tracing: Make tracing_cpumask available for all instances")
    Signed-off-by: Chunyu Hu <chuhu@redhat.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bd804a05eb00954891abf66c6125d054b8a0f93
Author: Sudeep Holla <Sudeep.Holla@arm.com>
Date:   Fri Jul 14 11:51:48 2017 +0100

    PM / Domains: defer dev_pm_domain_set() until genpd->attach_dev succeeds if present
    
    commit 975e83cfb8dc16e7a2fdc58188c77c0c605876c2 upstream.
    
    If the genpd->attach_dev or genpd->power_on fails, genpd_dev_pm_attach
    may return -EPROBE_DEFER initially. However genpd_alloc_dev_data sets
    the PM domain for the device unconditionally.
    
    When subsequent attempts are made to call genpd_dev_pm_attach, it may
    return -EEXISTS checking dev->pm_domain without re-attempting to call
    attach_dev or power_on.
    
    platform_drv_probe then attempts to call drv->probe as the return value
    -EEXIST != -EPROBE_DEFER, which may end up in a situation where the
    device is accessed without it's power domain switched on.
    
    Fixes: f104e1e5ef57 (PM / Domains: Re-order initialization of generic_pm_domain_data)
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69fbb442144abc4a7288d42edb6eb8a1ee799d87
Author: Jan Kara <jack@suse.cz>
Date:   Thu Jun 22 09:32:49 2017 +0200

    reiserfs: Don't clear SGID when inheriting ACLs
    
    commit 6883cd7f68245e43e91e5ee583b7550abf14523f upstream.
    
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
    
    Fix the problem by moving posix_acl_update_mode() out of
    __reiserfs_set_acl() into reiserfs_set_acl(). That way the function will
    not be called when inheriting ACLs which is what we want as it prevents
    SGID bit clearing and the mode has been properly set by
    posix_acl_create() anyway.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    CC: reiserfs-devel@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c7e5ca092c08bd2fde78a4eaad4a8afc5dc3555
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Thu Jun 29 14:46:44 2017 -0700

    spmi: Include OF based modalias in device uevent
    
    commit d50daa2af2618dab6d21634e65a5fbcf4ae437d6 upstream.
    
    Include the OF-based modalias in the uevent sent when registering SPMI
    devices, so that user space has a chance to autoload the kernel module
    for the device.
    
    Tested-by: Rob Clark <robdclark@gmail.com>
    Reported-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a18935b45e9700b5d21fce80ea82c1cb5efb4f9e
Author: Stephen Boyd <stephen.boyd@linaro.org>
Date:   Wed Dec 28 14:56:48 2016 -0800

    of: device: Export of_device_{get_modalias, uvent_modalias} to modules
    
    commit 7a3b7cd332db08546f3cdd984f11773e0d1999e7 upstream.
    
    The ULPI bus can be built as a module, and it will soon be
    calling these functions when it supports probing devices from DT.
    Export them so they can be used by the ULPI module.
    
    Acked-by: Rob Herring <robh@kernel.org>
    Cc: <devicetree@vger.kernel.org>
    Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b50bca7cdb0822628f45bea2bb028630999aa13
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Wed May 31 13:32:00 2017 -0400

    acpi/nfit: Fix memory corruption/Unregister mce decoder on failure
    
    commit 7e700d2c59e5853c9126642976b4f5768f64c9b3 upstream.
    
    nfit_init() calls nfit_mce_register() on module load.  When the module
    load fails the nfit mce decoder is not unregistered.  The module's
    memory is freed leaving the decoder chain referencing junk.  This will
    cause panics as future registrations will reference the free'd memory.
    
    Unregister the nfit mce decoder on module init failure.
    
    [v2]: register and then unregister mce handler to avoid losing mce events
    [v3]: also cleanup nfit workqueue
    
    Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Len Brown <lenb@kernel.org>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Cc: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>
    Cc: Linda Knippers <linda.knippers@hpe.com>
    Cc: lszubowi@redhat.com
    Acked-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97de6f34b42b079befb14e58e7f8b0d6e989c014
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Tue Jul 11 15:58:35 2017 +0300

    ovl: fix random return value on mount
    
    commit 8fc646b44385ff0a9853f6590497e43049eeb311 upstream.
    
    On failure to prepare_creds(), mount fails with a random
    return value, as err was last set to an integer cast of
    a valid lower mnt pointer or set to 0 if inodes index feature
    is enabled.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 3fe6e52f0626 ("ovl: override creds with the ones from ...")
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cf84432b422e92775aef5c43b0dfc58585fabb0
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 21 15:02:47 2017 +0200

    hfsplus: Don't clear SGID when inheriting ACLs
    
    commit 84969465ddc4f8aeb3b993123b571aa01c5f2683 upstream.
    
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
    
    Fix the problem by creating __hfsplus_set_posix_acl() function that does
    not call posix_acl_update_mode() and use it when inheriting ACLs. That
    prevents SGID bit clearing and the mode has been properly set by
    posix_acl_create() anyway.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b33da556255ce9703ab06805200bff244697b014
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Mon Apr 24 15:15:28 2017 -0700

    mlx5: Avoid that mlx5_ib_sg_to_klms() overflows the klms[] array
    
    commit 99975cd4fda52974a767aa44fe0b1a8f74950d9d upstream.
    
    ib_map_mr_sg() can pass an SG-list to .map_mr_sg() that is larger
    than what fits into a single MR. .map_mr_sg() must not attempt to
    map more SG-list elements than what fits into a single MR.
    Hence make sure that mlx5_ib_sg_to_klms() does not write outside
    the MR klms[] array.
    
    Fixes: b005d3164713 ("mlx5: Add arbitrary sg list support")
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
    Cc: Sagi Grimberg <sagi@grimberg.me>
    Cc: Leon Romanovsky <leonro@mellanox.com>
    Cc: Israel Rukshin <israelr@mellanox.com>
    Acked-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a440425194692f9b1d65728615b8599b9b517c0b
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Jul 19 16:46:32 2017 +0300

    drm/mst: Avoid processing partially received up/down message transactions
    
    commit 636c4c3e762b62aa93632c645ca65879285b16e3 upstream.
    
    Currently we may process up/down message transactions containing
    uninitialized data. This can happen if there was an error during the
    reception of any message in the transaction, but we happened to receive
    the last message correctly with the end-of-message flag set.
    
    To avoid this abort the reception of the transaction when the first
    error is detected, rejecting any messages until a message with the
    start-of-message flag is received (which will start a new transaction).
    This is also what the DP 1.4 spec 2.11.8.2 calls for in this case.
    
    In addtion this also prevents receiving bogus transactions without the
    first message with the the start-of-message flag set.
    
    v2:
    - unchanged
    v3:
    - git add the part that actually skips messages after an error in
      drm_dp_sideband_msg_build()
    
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Lyude <lyude@redhat.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Lyude <lyude@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170719134632.13366-1-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48376e6b71a67616db860872c1fa3b2eae4ad359
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Jul 19 14:43:29 2017 +0300

    drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()
    
    commit 7f8b3987da54cb4d41ad2545cd4d7958b9a36bdf upstream.
    
    In case of an unknown broadcast message is sent mstb will remain unset,
    so check for this.
    
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Lyude <lyude@redhat.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Lyude <lyude@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-3-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc3bd649ebb45c9b8cac19d1703fe012ba067600
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Jul 19 14:43:28 2017 +0300

    drm/mst: Fix error handling during MST sideband message reception
    
    commit 448421b5e93b9177c5698f0cf6f5e72d2995eeca upstream.
    
    Handle any error due to partial reads, timeouts etc. to avoid parsing
    uninitialized data subsequently. Also bail out if the parsing itself
    fails.
    
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Lyude <lyude@redhat.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Lyude <lyude@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170719114330.26540-2-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db29753960904012acfb8958bda5bc53c97f7e56
Author: Ismail, Mustafa <mustafa.ismail@intel.com>
Date:   Fri Jul 14 09:41:31 2017 -0500

    RDMA/core: Initialize port_num in qp_attr
    
    commit a62ab66b13a0f9bcb17b7b761f6670941ed5cd62 upstream.
    
    Initialize the port_num for iWARP in rdma_init_qp_attr.
    
    Fixes: 5ecce4c9b17b("Check port number supplied by user verbs cmds")
    Reviewed-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acccf01a807abddda5ceb2fe3b72a38429044d0e
Author: Yan, Zheng <zyan@redhat.com>
Date:   Thu Jul 6 11:12:21 2017 +0800

    ceph: fix race in concurrent readdir
    
    commit 84583cfb973c4313955c6231cc9cb3772d280b15 upstream.
    
    For a large directory, program needs to issue multiple readdir
    syscalls to get all dentries. When there are multiple programs
    read the directory concurrently. Following sequence of events
    can happen.
    
     - program calls readdir with pos = 2. ceph sends readdir request
       to mds. The reply contains N1 entries. ceph adds these N1 entries
       to readdir cache.
     - program calls readdir with pos = N1+2. The readdir is satisfied
       by the readdir cache, N2 entries are returned. (Other program
       calls readdir in the middle, which fills the cache)
     - program calls readdir with pos = N1+N2+2. ceph sends readdir
       request to mds. The reply contains N3 entries and it reaches
       directory end. ceph adds these N3 entries to the readdir cache
       and marks directory complete.
    
    The second readdir call does not update fi->readdir_cache_idx.
    ceph add the last N3 entries to wrong places.
    
    Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d42f9c7435c06c370966281782fd0e33a2eff460
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sat Jul 15 11:32:08 2017 -0400

    staging: lustre: ko2iblnd: check copy_from_iter/copy_to_iter return code
    
    commit 566e1ce22e04426fa52328b2adcdf1df49acd98e upstream.
    
    We now get a helpful warning for code that calls copy_{from,to}_iter
    without checking the return value, introduced by commit aa28de275a24
    ("iov_iter/hardening: move object size checks to inlined part").
    
    drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function 'kiblnd_send':
    drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1643:2: error: ignoring return value of 'copy_from_iter', declared with attribute warn_unused_result [-Werror=unused-result]
    drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function 'kiblnd_recv':
    drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c:1744:3: error: ignoring return value of 'copy_to_iter', declared with attribute warn_unused_result [-Werror=unused-result]
    
    In case we get short copies here, we may get incorrect behavior.
    I've added failure handling for both rx and tx now, returning
    -EFAULT as expected.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: James Simmons <jsimmons@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85643f6f50282d52c8d8cedbf958092b2a03cf7a
Author: Teddy Wang <teddy.wang@siliconmotion.com>
Date:   Fri Jun 30 21:57:43 2017 +0100

    staging: sm750fb: avoid conflicting vesafb
    
    commit 740c433ec35187b45abe08bb6c45a321a791be8e upstream.
    
    If vesafb is enabled in the config then /dev/fb0 is created by vesa
    and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
    effectively work with xorg.
    So if it has been alloted fb1, then try to remove the other fb0.
    
    In the previous send, why #ifdef is used was asked.
    https://lkml.org/lkml/2017/6/25/57
    
    Answered at: https://lkml.org/lkml/2017/6/25/69
    Also pasting here for reference.
    
    'Did a quick research into "why".
    The patch d8801e4df91e ("x86/PCI: Set IORESOURCE_ROM_SHADOW only for the
    default VGA device") has started setting IORESOURCE_ROM_SHADOW in flags
    for a default VGA device and that is being done only for x86.
    And so, we will need that #ifdef to check IORESOURCE_ROM_SHADOW as that
    needs to be checked only for a x86 and not for other arch.'
    
    Signed-off-by: Teddy Wang <teddy.wang@siliconmotion.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc52403da8a940d3ecc1b4c770cab9a650167ae
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Fri Jun 30 12:02:18 2017 +0100

    staging: comedi: ni_mio_common: fix AO timer off-by-one regression
    
    commit 15d5193104a457d5151840247e3bce561c42e3e9 upstream.
    
    As reported by Éric Piel on the Comedi mailing list (see
    <https://groups.google.com/forum/#!topic/comedi_list/ueZiR7vTLOU/discussion>),
    the analog output asynchronous commands are running too fast with a
    period 50 ns shorter than it should be.  This affects all boards with AO
    command support that are supported by the "ni_pcimio", "ni_atmio", and
    "ni_mio_cs" drivers.
    
    This is a regression bug introduced by commit 080e6795cba3 ("staging:
    comedi: ni_mio_common: Cleans up/clarifies ni_ao_cmd"), specifically,
    this line in `ni_ao_cmd_set_update()`:
    
                    /* following line: N-1 per STC */
                    ni_stc_writel(dev, trigvar - 1, NISTC_AO_UI_LOADA_REG);
    
    The `trigvar` variable value comes from a call to `ni_ns_to_timer()`
    which converts a timer period in nanoseconds to a hardware divisor
    value. The function already reduces the divisor by 1 as required by the
    hardware, so the above line should not reduce it further by 1.  Fix it
    by replacing `trigvar` by `trigvar - 1` in the above line, and remove
    the misleading comment.
    
    Reported-by: Éric Piel <piel@delmic.com>
    Fixes: 080e6795cba3 ("staging: comedi: ni_mio_common: Cleans up/clarifies ni_ao_cmd")
    Cc: Éric Piel <piel@delmic.com>
    Cc: Spencer E. Olson <olsonse@umich.edu>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 964a21a1300c2857483e85f1d013c5867ee4d433
Author: Michael Gugino <michael.gugino.2@gmail.com>
Date:   Mon Jul 17 13:29:09 2017 -0400

    staging: rtl8188eu: add TL-WN722N v2 support
    
    commit 5a1d4c5dd4eb2f1f8a9b30e61762f3b3b564df70 upstream.
    
    Add support for USB Device TP-Link TL-WN722N v2.
    VendorID: 0x2357, ProductID: 0x010c
    
    Signed-off-by: Michael Gugino <michael.gugino.2@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a76a032300e26ecbc398dcaaeb10b5a850a95f76
Author: Ingo Molnar <mingo@kernel.org>
Date:   Tue Jul 11 10:56:54 2017 +0200

    Revert "perf/core: Drop kernel samples even though :u is specified"
    
    commit 6a8a75f3235724c5941a33e287b2f98966ad14c5 upstream.
    
    This reverts commit cc1582c231ea041fbc68861dfaf957eaf902b829.
    
    This commit introduced a regression that broke rr-project, which uses sampling
    events to receive a signal on overflow (but does not care about the contents
    of the sample). These signals are critical to the correct operation of rr.
    
    There's been some back and forth about how to fix it - but to not keep
    applications in limbo queue up a revert.
    
    Reported-by: Kyle Huey <me@kylehuey.com>
    Acked-by: Kyle Huey <me@kylehuey.com>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Jin Yao <yao.jin@linux.intel.com>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Link: http://lkml.kernel.org/r/20170628105600.GC5981@leverpostej
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61415418cdba50d37db8a474e2c30af1aba30092
Author: Jin Yao <yao.jin@linux.intel.com>
Date:   Thu Jun 8 14:01:44 2017 +0800

    perf annotate: Fix broken arrow at row 0 connecting jmp instruction to its target
    
    commit 80f62589fa52f530cffc50e78c0b5a2ae572d61e upstream.
    
    When the jump instruction is displayed at the row 0 in annotate view,
    the arrow is broken. An example:
    
     16.86 │   ┌──je     82
      0.01 │      movsd  (%rsp),%xmm0
           │      movsd  0x8(%rsp),%xmm4
           │      movsd  0x8(%rsp),%xmm1
           │      movsd  (%rsp),%xmm3
           │      divsd  %xmm4,%xmm0
           │      divsd  %xmm3,%xmm1
           │      movsd  (%rsp),%xmm2
           │      addsd  %xmm1,%xmm0
           │      addsd  %xmm2,%xmm0
           │      movsd  %xmm0,(%rsp)
           │82:   sub    $0x1,%ebx
     83.03 │    ↑ jne    38
           │      add    $0x10,%rsp
           │      xor    %eax,%eax
           │      pop    %rbx
           │    ← retq
    
    The patch increments the row number before checking with 0.
    
    Signed-off-by: Yao Jin <yao.jin@linux.intel.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Fixes: 944e1abed9e1 ("perf ui browser: Add method to draw up/down arrow line")
    Link: http://lkml.kernel.org/r/1496901704-30275-1-git-send-email-yao.jin@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5f9cd081c66f0b3187626c1c9f7b89949aae71f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jun 29 22:21:31 2017 -0700

    iser-target: Avoid isert_conn->cm_id dereference in isert_login_recv_done
    
    commit fce50a2fa4e9c6e103915c351b6d4a98661341d6 upstream.
    
    This patch fixes a NULL pointer dereference in isert_login_recv_done()
    of isert_conn->cm_id due to isert_cma_handler() -> isert_connect_error()
    resetting isert_conn->cm_id = NULL during a failed login attempt.
    
    As per Sagi, we will always see the completion of all recv wrs posted
    on the qp (given that we assigned a ->done handler), this is a FLUSH
    error completion, we just don't get to verify that because we deref
    NULL before.
    
    The issue here, was the assumption that dereferencing the connection
    cm_id is always safe, which is not true since:
    
        commit 4a579da2586bd3b79b025947ea24ede2bbfede62
        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
    
    As I see it, we have a direct reference to the isert_device from
    isert_conn which is the one-liner fix that we actually need like
    we do in isert_rdma_read_done() and isert_rdma_write_done().
    
    Reported-by: Andrea Righi <righi.andrea@gmail.com>
    Tested-by: Andrea Righi <righi.andrea@gmail.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 672145dfae842fe31dfaedd965a23e051a4722b5
Author: Jiang Yi <jiangyilism@gmail.com>
Date:   Sun Jun 25 12:28:50 2017 -0700

    target: Fix COMPARE_AND_WRITE caw_sem leak during se_cmd quiesce
    
    commit 1d6ef276594a781686058802996e09c8550fd767 upstream.
    
    This patch addresses a COMPARE_AND_WRITE se_device->caw_sem leak,
    that would be triggered during normal se_cmd shutdown or abort
    via __transport_wait_for_tasks().
    
    This would occur because target_complete_cmd() would catch this
    early and do complete_all(&cmd->t_transport_stop_comp), but since
    target_complete_ok_work() or target_complete_failure_work() are
    never called to invoke se_cmd->transport_complete_callback(),
    the COMPARE_AND_WRITE specific callbacks never release caw_sem.
    
    To address this special case, go ahead and release caw_sem
    directly from target_complete_cmd().
    
    (Remove '&& success' from check, to release caw_sem regardless
     of scsi_status - nab)
    
    Signed-off-by: Jiang Yi <jiangyilism@gmail.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa67ac18eff4b59b7937c59e821f8b4be812113c
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jun 13 16:20:25 2017 +0200

    udf: Fix deadlock between writeback and udf_setsize()
    
    commit f2e95355891153f66d4156bf3a142c6489cd78c6 upstream.
    
    udf_setsize() called truncate_setsize() with i_data_sem held. Thus
    truncate_pagecache() called from truncate_setsize() could lock a page
    under i_data_sem which can deadlock as page lock ranks below
    i_data_sem - e. g. writeback can hold page lock and try to acquire
    i_data_sem to map a block.
    
    Fix the problem by moving truncate_setsize() calls from under
    i_data_sem. It is safe for us to change i_size without holding
    i_data_sem as all the places that depend on i_size being stable already
    hold inode_lock.
    
    Fixes: 7e49b6f2480cb9a9e7322a91592e56a5c85361f5
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ebfb4fa3ab7ea99b5d93305b10ee3714501b465
Author: NeilBrown <neilb@suse.com>
Date:   Wed Jul 5 12:22:20 2017 +1000

    NFS: only invalidate dentrys that are clearly invalid.
    
    commit cc89684c9a265828ce061037f1f79f4a68ccd3f7 upstream.
    
    Since commit bafc9b754f75 ("vfs: More precise tests in d_invalidate")
    in v3.18, a return of '0' from ->d_revalidate() will cause the dentry
    to be invalidated even if it has filesystems mounted on or it or on a
    descendant.  The mounted filesystem is unmounted.
    
    This means we need to be careful not to return 0 unless the directory
    referred to truly is invalid.  So -ESTALE or -ENOENT should invalidate
    the directory.  Other errors such a -EPERM or -ERESTARTSYS should be
    returned from ->d_revalidate() so they are propagated to the caller.
    
    A particular problem can be demonstrated by:
    
    1/ mount an NFS filesystem using NFSv3 on /mnt
    2/ mount any other filesystem on /mnt/foo
    3/ ls /mnt/foo
    4/ turn off network, or otherwise make the server unable to respond
    5/ ls /mnt/foo &
    6/ cat /proc/$!/stack # note that nfs_lookup_revalidate is in the call stack
    7/ kill -9 $! # this results in -ERESTARTSYS being returned
    8/ observe that /mnt/foo has been unmounted.
    
    This patch changes nfs_lookup_revalidate() to only treat
      -ESTALE from nfs_lookup_verify_inode() and
      -ESTALE or -ENOENT from ->lookup()
    as indicating an invalid inode.  Other errors are returned.
    
    Also nfs_check_inode_attributes() is changed to return -ESTALE rather
    than -EIO.  This is consistent with the error returned in similar
    circumstances from nfs_update_inode().
    
    As this bug allows any user to unmount a filesystem mounted on an NFS
    filesystem, this fix is suitable for stable kernels.
    
    Fixes: bafc9b754f75 ("vfs: More precise tests in d_invalidate")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4dd0aa9ae6d0e948848f87b4c040cea8163a59bf
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Jun 10 04:59:07 2017 +0200

    sunrpc: use constant time memory comparison for mac
    
    commit 15a8b93fd5690de017ce665382ea45e5d61811a4 upstream.
    
    Otherwise, we enable a MAC forgery via timing attack.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: "J. Bruce Fields" <bfields@fieldses.org>
    Cc: Jeff Layton <jlayton@poochiereds.net>
    Cc: Trond Myklebust <trond.myklebust@primarydata.com>
    Cc: Anna Schumaker <anna.schumaker@netapp.com>
    Cc: linux-nfs@vger.kernel.org
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd0d6509cbf4ad5624300083ed7f98dcdac55e2a
Author: Moni Shoua <monis@mellanox.com>
Date:   Tue May 23 10:48:44 2017 +0300

    IB/core: Namespace is mandatory input for address resolution
    
    commit bebb2a473a43c8f84a8210687d1cbdde503046d7 upstream.
    
    In function addr_resolve() the namespace is a required input parameter
    and not an output. It is passed later for searching the routing table
    and device addresses. Also, it shouldn't be copied back to the caller.
    
    Fixes: 565edd1d5555 ('IB/addr: Pass network namespace as a parameter')
    Signed-off-by: Moni Shoua <monis@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 5c2717f4154502779e696b303cf8dcfb94b2e5f5
Author: Vladimir Neyelov <vladimirn@mellanox.com>
Date:   Sun May 21 19:17:31 2017 +0300

    IB/iser: Fix connection teardown race condition
    
    commit c8c16d3bae967f1c7af541e8d016e5c51e4f010a upstream.
    
    Under heavy iser target(scst) start/stop stress during login/logout
    on iser intitiator side happened trace call provided below.
    
    The function iscsi_iser_slave_alloc iser_conn pointer could be NULL,
    due to the fact that function iscsi_iser_conn_stop can be called before
    and free iser connection. Let's protect that flow by introducing global mutex.
    
    BUG: unable to handle kernel paging request at 0000000000001018
    IP: [<ffffffffc0426f7e>] iscsi_iser_slave_alloc+0x1e/0x50 [ib_iser]
    Call Trace:
    ? scsi_alloc_sdev+0x242/0x300
    scsi_probe_and_add_lun+0x9e1/0xea0
    ? kfree_const+0x21/0x30
    ? kobject_set_name_vargs+0x76/0x90
    ? __pm_runtime_resume+0x5b/0x70
    __scsi_scan_target+0xf6/0x250
    scsi_scan_target+0xea/0x100
    iscsi_user_scan_session.part.13+0x101/0x130 [scsi_transport_iscsi]
    ? iscsi_user_scan_session.part.13+0x130/0x130 [scsi_transport_iscsi]
    iscsi_user_scan_session+0x1e/0x30 [scsi_transport_iscsi]
    device_for_each_child+0x50/0x90
    iscsi_user_scan+0x44/0x60 [scsi_transport_iscsi]
    store_scan+0xa8/0x100
    ? common_file_perm+0x5d/0x1c0
    dev_attr_store+0x18/0x30
    sysfs_kf_write+0x37/0x40
    kernfs_fop_write+0x12c/0x1c0
    __vfs_write+0x18/0x40
    vfs_write+0xb5/0x1a0
    SyS_write+0x55/0xc0
    
    Fixes: 318d311e8f01 ("iser: Accept arbitrary sg lists mapping if the device supports it")
    Signed-off-by: Vladimir Neyelov <vladimirn@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Reviewed-by: Sagi Grimberg <sagi@grimbeg.me>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b50e0e74e2e5f084d18a03f6dedc67cfdb8db49
Author: Chen Hong <chenhong3@huawei.com>
Date:   Sun Jul 2 15:11:10 2017 -0700

    Input: i8042 - fix crash at boot time
    
    commit 340d394a789518018f834ff70f7534fc463d3226 upstream.
    
    The driver checks port->exists twice in i8042_interrupt(), first when
    trying to assign temporary "serio" variable, and second time when deciding
    whether it should call serio_interrupt(). The value of port->exists may
    change between the 2 checks, and we may end up calling serio_interrupt()
    with a NULL pointer:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
    IP: [<ffffffff8150feaf>] _spin_lock_irqsave+0x1f/0x40
    PGD 0
    Oops: 0002 [#1] SMP
    last sysfs file:
    CPU 0
    Modules linked in:
    
    Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard PC (i440FX + PIIX, 1996)
    RIP: 0010:[<ffffffff8150feaf>]  [<ffffffff8150feaf>] _spin_lock_irqsave+0x1f/0x40
    RSP: 0018:ffff880028203cc0  EFLAGS: 00010082
    RAX: 0000000000010000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000000282 RSI: 0000000000000098 RDI: 0000000000000050
    RBP: ffff880028203cc0 R08: ffff88013e79c000 R09: ffff880028203ee0
    R10: 0000000000000298 R11: 0000000000000282 R12: 0000000000000050
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000098
    FS:  0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000050 CR3: 0000000001a85000 CR4: 00000000001407f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper (pid: 1, threadinfo ffff88013e79c000, task ffff88013e79b500)
    Stack:
    ffff880028203d00 ffffffff813de186 ffffffffffffff02 0000000000000000
    <d> 0000000000000000 0000000000000000 0000000000000000 0000000000000098
    <d> ffff880028203d70 ffffffff813e0162 ffff880028203d20 ffffffff8103b8ac
    Call Trace:
    <IRQ>
     [<ffffffff813de186>] serio_interrupt+0x36/0xa0
    [<ffffffff813e0162>] i8042_interrupt+0x132/0x3a0
    [<ffffffff8103b8ac>] ? kvm_clock_read+0x1c/0x20
    [<ffffffff8103b8b9>] ? kvm_clock_get_cycles+0x9/0x10
    [<ffffffff810e1640>] handle_IRQ_event+0x60/0x170
    [<ffffffff8103b154>] ? kvm_guest_apic_eoi_write+0x44/0x50
    [<ffffffff810e3d8e>] handle_edge_irq+0xde/0x180
    [<ffffffff8100de89>] handle_irq+0x49/0xa0
    [<ffffffff81516c8c>] do_IRQ+0x6c/0xf0
    [<ffffffff8100b9d3>] ret_from_intr+0x0/0x11
    [<ffffffff81076f63>] ? __do_softirq+0x73/0x1e0
    [<ffffffff8109b75b>] ? hrtimer_interrupt+0x14b/0x260
    [<ffffffff8100c1cc>] ? call_softirq+0x1c/0x30
    [<ffffffff8100de05>] ? do_softirq+0x65/0xa0
    [<ffffffff81076d95>] ? irq_exit+0x85/0x90
    [<ffffffff81516d80>] ? smp_apic_timer_interrupt+0x70/0x9b
    [<ffffffff8100bb93>] ? apic_timer_interrupt+0x13/0x20
    
    To avoid the issue let's change the second check to test whether serio is
    NULL or not.
    
    Also, let's take i8042_lock in i8042_start() and i8042_stop() instead of
    trying to be overly smart and using memory barriers.
    
    Signed-off-by: Chen Hong <chenhong3@huawei.com>
    [dtor: take lock in i8042_start()/i8042_stop()]
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d77ac4bc514568b98762f3a35b83a4de3e966b8
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:15:22 2017 +0100

    MIPS: Fix a typo: s/preset/present/ in r2-to-r6 emulation error message
    
    commit 27fe2200dad2de8207a694024a7b9037dff1b280 upstream.
    
    This is a user-visible message, so we want it to be spelled correctly.
    
    Fixes: 5f9f41c474be ("MIPS: kernel: Prepare the JR instruction for emulation on MIPS R6")
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16400/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3330a05c5c6ebb6134479bca4758d9766d1c9663
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:14:12 2017 +0100

    MIPS: Send SIGILL for R6 branches in `__compute_return_epc_for_insn'
    
    commit a60b1a5bf88a250f1a77977c0224e502c901c77b upstream.
    
    Fix:
    
    * commit 8467ca0122e2 ("MIPS: Emulate the new MIPS R6 branch compact
    (BC) instruction"),
    
    * commit 84fef630127a ("MIPS: Emulate the new MIPS R6 BALC
    instruction"),
    
    * commit 69b9a2fd05a3 ("MIPS: Emulate the new MIPS R6 BEQZC and JIC
    instructions"),
    
    * commit 28d6f93d201d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC
    instructions"),
    
    * commit c893ce38b265 ("MIPS: Emulate the new MIPS R6 BOVC, BEQC and
    BEQZALC instructions")
    
    and send SIGILL rather than returning -SIGILL for R6 branch and jump
    instructions.  Returning -SIGILL is never correct as the API defines
    this function's result upon error to be -EFAULT and a signal actually
    issued.
    
    Fixes: 8467ca0122e2 ("MIPS: Emulate the new MIPS R6 branch compact (BC) instruction")
    Fixes: 84fef630127a ("MIPS: Emulate the new MIPS R6 BALC instruction")
    Fixes: 69b9a2fd05a3 ("MIPS: Emulate the new MIPS R6 BEQZC and JIC instructions")
    Fixes: 28d6f93d201d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions")
    Fixes: c893ce38b265 ("MIPS: Emulate the new MIPS R6 BOVC, BEQC and BEQZALC instructions")
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16399/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4bd6a1df2c816b7027f9cf1a900ae52f528f300
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:12:53 2017 +0100

    MIPS: Send SIGILL for linked branches in `__compute_return_epc_for_insn'
    
    commit fef40be6da856afead4177aaa9d869a66fb3381f upstream.
    
    Fix commit 319824eabc3f ("MIPS: kernel: branch: Do not emulate the
    branch likelies on MIPS R6") and also send SIGILL rather than returning
    -SIGILL for BLTZAL, BLTZALL, BGEZAL and BGEZALL instruction encodings no
    longer supported in R6, except where emulated.  Returning -SIGILL is
    never correct as the API defines this function's result upon error to be
    -EFAULT and a signal actually issued.
    
    Fixes: 319824eabc3f ("MIPS: kernel: branch: Do not emulate the branch likelies on MIPS R6")
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16398/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99ce76144dee8dfbedeccfe7fed85f61d31c6379
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:09:23 2017 +0100

    MIPS: Rename `sigill_r6' to `sigill_r2r6' in `__compute_return_epc_for_insn'
    
    commit 1f4edde422961397cf4470b347958c13c6a740bb upstream.
    
    Use the more accurate `sigill_r2r6' name for the label used in the case
    of sending SIGILL in the absence of the instruction emulator for an
    earlier ISA level instruction that has been removed as from the R6 ISA,
    so that the `sigill_r6' name is freed for the situation where an R6
    instruction is not supposed to be interpreted, because the executing
    processor does not support the R6 ISA.
    
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16397/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86dd4aa3079058342b99289977cc06c681fb6a2d
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:08:29 2017 +0100

    MIPS: Send SIGILL for BPOSGE32 in `__compute_return_epc_for_insn'
    
    commit 7b82c1058ac1f8f8b9f2b8786b1f710a57a870a8 upstream.
    
    Fix commit e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.") and
    send SIGILL rather than SIGBUS whenever an unimplemented BPOSGE32 DSP
    ASE instruction has been encountered in `__compute_return_epc_for_insn'
    as our Reserved Instruction exception handler would in response to an
    attempt to actually execute the instruction.  Sending SIGBUS only makes
    sense for the unaligned PC case, since moved to `__compute_return_epc'.
    Adjust function documentation accordingly, correct formatting and use
    `pr_info' rather than `printk' as the other exit path already does.
    
    Fixes: e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.")
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16396/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d79354cc1bc912d623765781d570ddc398d792db
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:05:08 2017 +0100

    MIPS: math-emu: Prevent wrong ISA mode instruction emulation
    
    commit 13769ebad0c42738831787e27c7c7f982e7da579 upstream.
    
    Terminate FPU emulation immediately whenever an ISA mode switch has been
    observed.  This is so that we do not interpret machine code in the wrong
    mode, for example when a regular MIPS FPU instruction has been placed in
    a delay slot of a jump that switches into the MIPS16 mode, as with the
    following code (taken from a GCC test suite case):
    
    00400650 <set_fast_math>:
      400650:       3c020100        lui     v0,0x100
      400654:       03e00008        jr      ra
      400658:       44c2f800        ctc1    v0,c1_fcsr
      40065c:       00000000        nop
    
    [...]
    
    004012d0 <__libc_csu_init>:
      4012d0:       f000 6a02       li      v0,2
      4012d4:       f150 0b1c       la      v1,3f9430 <_DYNAMIC-0x6df0>
      4012d8:       f400 3240       sll     v0,16
      4012dc:       e269            addu    v0,v1
      4012de:       659a            move    gp,v0
      4012e0:       f00c 64f6       save    a0-a2,48,ra,s0-s1
      4012e4:       673c            move    s1,gp
      4012e6:       f010 9978       lw      v1,-32744(s1)
      4012ea:       d204            sw      v0,16(sp)
      4012ec:       eb40            jalr    v1
      4012ee:       653b            move    t9,v1
      4012f0:       f010 997c       lw      v1,-32740(s1)
      4012f4:       f030 9920       lw      s1,-32736(s1)
      4012f8:       e32f            subu    v1,s1
      4012fa:       326b            sra     v0,v1,2
      4012fc:       d206            sw      v0,24(sp)
      4012fe:       220c            beqz    v0,401318 <__libc_csu_init+0x48>
      401300:       6800            li      s0,0
      401302:       99e0            lw      a3,0(s1)
      401304:       4801            addiu   s0,1
      401306:       960e            lw      a2,56(sp)
      401308:       4904            addiu   s1,4
      40130a:       950d            lw      a1,52(sp)
      40130c:       940c            lw      a0,48(sp)
      40130e:       ef40            jalr    a3
      401310:       653f            move    t9,a3
      401312:       9206            lw      v0,24(sp)
      401314:       ea0a            cmp     v0,s0
      401316:       61f5            btnez   401302 <__libc_csu_init+0x32>
      401318:       6476            restore 48,ra,s0-s1
      40131a:       e8a0            jrc     ra
    
    Here `set_fast_math' is called from `40130e' (`40130f' with the ISA bit)
    and emulation triggers for the CTC1 instruction.  As it is in a jump
    delay slot emulation continues from `401312' (`401313' with the ISA
    bit).  However we have no path to handle MIPS16 FPU code emulation,
    because there are no MIPS16 FPU instructions.  So the default emulation
    path is taken, interpreting a 32-bit word fetched by `get_user' from
    `401313' as a regular MIPS instruction, which is:
    
      401313:       f5ea0a92        sdc1    $f10,2706(t7)
    
    This makes the FPU emulator proceed with the supposed SDC1 instruction
    and consequently makes the program considered here terminate with
    SIGSEGV.
    
    A similar although less severe issue exists with pure-microMIPS
    processors in the case where similarly an FPU instruction is emulated in
    a delay slot of a register jump that (incorrectly) switches into the
    regular MIPS mode.  A subsequent instruction fetch from the jump's
    target is supposed to cause an Address Error exception, however instead
    we proceed with regular MIPS FPU emulation.
    
    For simplicity then, always terminate the emulation loop whenever a mode
    change is detected, denoted by an ISA mode bit flip.  As from commit
    377cb1b6c16a ("MIPS: Disable MIPS16/microMIPS crap for platforms not
    supporting these ASEs.") the result of `get_isa16_mode' can be hardcoded
    to 0, so we need to examine the ISA mode bit by hand.
    
    This complements commit 102cedc32a6e ("MIPS: microMIPS: Floating point
    support.") which added JALX decoding to FPU emulation.
    
    Fixes: 102cedc32a6e ("MIPS: microMIPS: Floating point support.")
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16393/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 040078ad0fe82beff150dfd3b060a2ba7b47ea37
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:07:34 2017 +0100

    MIPS: Fix unaligned PC interpretation in `compute_return_epc'
    
    commit 11a3799dbeb620bf0400b1fda5cc2c6bea55f20a upstream.
    
    Fix a regression introduced with commit fb6883e5809c ("MIPS: microMIPS:
    Support handling of delay slots.") and defer to `__compute_return_epc'
    if the ISA bit is set in EPC with non-MIPS16, non-microMIPS hardware,
    which will then arrange for a SIGBUS due to an unaligned instruction
    reference.  Returning EPC here is never correct as the API defines this
    function's result to be either a negative error code on failure or one
    of 0 and BRANCH_LIKELY_TAKEN on success.
    
    Fixes: fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.")
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16395/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 434c9f2e3b4667859a705b48d53f23f5f629ecf1
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Jun 16 00:06:19 2017 +0100

    MIPS: Actually decode JALX in `__compute_return_epc_for_insn'
    
    commit a9db101b735a9d49295326ae41f610f6da62b08c upstream.
    
    Complement commit fb6883e5809c ("MIPS: microMIPS: Support handling of
    delay slots.") and actually decode the regular MIPS JALX major
    instruction opcode, the handling of which has been added with the said
    commit for EPC calculation in `__compute_return_epc_for_insn'.
    
    Fixes: fb6883e5809c ("MIPS: microMIPS: Support handling of delay slots.")
    Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16394/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8c331cbc937d849d93dc9f3f7cdc31d5fbac58e
Author: James Hogan <james.hogan@imgtec.com>
Date:   Wed May 31 16:19:48 2017 +0100

    MIPS: Save static registers before sysmips
    
    commit 49955d84cd9ccdca5a16a495e448e1a06fad9e49 upstream.
    
    The MIPS sysmips system call handler may return directly from the
    MIPS_ATOMIC_SET case (mips_atomic_set()) to syscall_exit. This path
    restores the static (callee saved) registers, however they won't have
    been saved on entry to the system call.
    
    Use the save_static_function() macro to create a __sys_sysmips wrapper
    function which saves the static registers before calling sys_sysmips, so
    that the correct static register state is restored by syscall_exit.
    
    Fixes: f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16149/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9db2f4f887c2cc9557fc2ae553ea24ecc65c6e0
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Sat Jul 8 23:24:44 2017 +0100

    MIPS: Fix MIPS I ISA /proc/cpuinfo reporting
    
    commit e5f5a5b06e51a36f6ddf31a4a485358263953a3d upstream.
    
    Correct a commit 515a6393dbac ("MIPS: kernel: proc: Add MIPS R6 support
    to /proc/cpuinfo") regression that caused MIPS I systems to show no ISA
    levels supported in /proc/cpuinfo, e.g.:
    
    system type             : Digital DECstation 2100/3100
    machine                 : Unknown
    processor               : 0
    cpu model               : R3000 V2.0  FPU V2.0
    BogoMIPS                : 10.69
    wait instruction        : no
    microsecond timers      : no
    tlb_entries             : 64
    extra interrupt vector  : no
    hardware watchpoint     : no
    isa                     :
    ASEs implemented        :
    shadow register sets    : 1
    kscratch registers      : 0
    package                 : 0
    core                    : 0
    VCED exceptions         : not available
    VCEI exceptions         : not available
    
    and similarly exclude `mips1' from the ISA list for any processors below
    MIPSr1.  This is because the condition to show `mips1' on has been made
    `cpu_has_mips_r1' rather than newly-introduced `cpu_has_mips_1'.  Use
    the correct condition then.
    
    Fixes: 515a6393dbac ("MIPS: kernel: proc: Add MIPS R6 support to /proc/cpuinfo")
    Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16758/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c69280e9018eaea65ab18cc9a231d913479a5ee3
Author: Seunghun Han <kkamagui@gmail.com>
Date:   Tue Jul 18 18:20:44 2017 +0900

    x86/ioapic: Pass the correct data to unmask_ioapic_irq()
    
    commit e708e35ba6d89ff785b225cd07dcccab04fa954a upstream.
    
    One of the rarely executed code pathes in check_timer() calls
    unmask_ioapic_irq() passing irq_get_chip_data(0) as argument.
    
    That's wrong as unmask_ioapic_irq() expects a pointer to the irq data of
    interrupt 0. irq_get_chip_data(0) returns NULL, so the following
    dereference in unmask_ioapic_irq() causes a kernel panic.
    
    The issue went unnoticed in the first place because irq_get_chip_data()
    returns a void pointer so the compiler cannot do a type check on the
    argument. The code path was added for machines with broken configuration,
    but it seems that those machines are either not running current kernels or
    simply do not longer exist.
    
    Hand in irq_get_irq_data(0) as argument which provides the correct data.
    
    [ tglx: Rewrote changelog ]
    
    Fixes: 4467715a44cc ("x86/irq: Move irq_cfg.irq_2_pin into io_apic.c")
    Signed-off-by: Seunghun Han <kkamagui@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1500369644-45767-1-git-send-email-kkamagui@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 036d59f40ac94964a1bbc8959f78f34efac71fd5
Author: Seunghun Han <kkamagui@gmail.com>
Date:   Tue Jul 18 20:03:51 2017 +0900

    x86/acpi: Prevent out of bound access caused by broken ACPI tables
    
    commit dad5ab0db8deac535d03e3fe3d8f2892173fa6a4 upstream.
    
    The bus_irq argument of mp_override_legacy_irq() is used as the index into
    the isa_irq_to_gsi[] array. The bus_irq argument originates from
    ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI
    tables, but is nowhere sanity checked.
    
    That allows broken or malicious ACPI tables to overwrite memory, which
    might cause malfunction, panic or arbitrary code execution.
    
    Add a sanity check and emit a warning when that triggers.
    
    [ tglx: Added warning and rewrote changelog ]
    
    Signed-off-by: Seunghun Han <kkamagui@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: security@kernel.org
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 456a997498cb5217a61fba0f1929be7d182b5338
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Wed Jul 12 11:09:17 2017 +0800

    Revert "ACPI / EC: Enable event freeze mode..." to fix a regression
    
    commit 9c40f956ce9b331493347d1b3cb7e384f7dc0581 upstream.
    
    On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier
    EC event freezing timing causes acpitz-virtual-0 to report a stuck
    48C temparature.  And with EC firmware revisioned as 1.14, without
    reverting back to old EC event freezing timing, the fan still blows
    up after a system resume.
    
    This reverts the culprit change so that the regression can be fixed
    without upgrading the EC firmware.
    
    Fixes: d30283057ecd (ACPI / EC: Enable event freeze mode to improve event handling)
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168
    Tested-by: Damjan Georgievski <gdamjan@gmail.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2966b109b1a2c23e626ad35fc03d4a52efd1aa4
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Wed Jul 12 11:09:09 2017 +0800

    ACPI / EC: Drop EC noirq hooks to fix a regression
    
    commit 662591461c4b9a1e3b9b159dbf37648a585ebaae upstream.
    
    According to bug reports, although the busy polling mode can make
    noirq stages execute faster, it causes abnormal fan blowing up after
    system resume (see the first link below for a video demonstration)
    on Lenovo ThinkPad X1 Carbon - the 5th Generation.  The problem can
    be fixed by upgrading the EC firmware on that machine.
    
    However, many reporters confirm that the problem can be fixed by
    stopping busy polling during suspend/resume and for some of them
    upgrading the EC firmware is not an option.
    
    For this reason, drop the noirq stage hooks from the EC driver
    to fix the regression.
    
    Fixes: c3a696b6e8f8 (ACPI / EC: Use busy polling mode when GPE is not enabled)
    Link: https://youtu.be/9NQ9x-Jm99Q
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129
    Reported-by: Andreas Lindhe <andreas@lindhe.io>
    Tested-by: Gjorgji Jankovski <j.gjorgji@gmail.com>
    Tested-by: Damjan Georgievski <gdamjan@gmail.com>
    Tested-by: Fernando Chaves <nanochaves@gmail.com>
    Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com>
    Tested-by: Denis P. <theoriginal.skullburner@gmail.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec469b5e2aafdcedbc80d9a7a8a4fa8632e584e3
Author: Richard Weinberger <richard@nod.at>
Date:   Fri Jun 16 16:21:44 2017 +0200

    ubifs: Don't leak kernel memory to the MTD
    
    commit 4acadda74ff8b949c448c0282765ae747e088c87 upstream.
    
    When UBIFS prepares data structures which will be written to the MTD it
    ensues that their lengths are multiple of 8. Since it uses kmalloc() the
    padded bytes are left uninitialized and we leak a few bytes of kernel
    memory to the MTD.
    To make sure that all bytes are initialized, let's switch to kzalloc().
    Kzalloc() is fine in this case because the buffers are not huge and in
    the IO path the performance bottleneck is anyway the MTD.
    
    Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02131aea6bd4d7a1414333160124b6a078b262fe
Author: James Hogan <james.hogan@imgtec.com>
Date:   Thu Jun 29 10:12:34 2017 +0100

    MIPS: Negate error syscall return in trace
    
    commit 4f32a39d49b25eaa66d2420f1f03d371ea4cd906 upstream.
    
    The sys_exit trace event takes a single return value for the system
    call, which MIPS passes the value of the $v0 (result) register, however
    MIPS returns positive error codes in $v0 with $a3 specifying that $v0
    contains an error code. As a result erroring system calls are traced
    returning positive error numbers that can't always be distinguished from
    success.
    
    Use regs_return_value() to negate the error code if $a3 is set.
    
    Fixes: 1d7bf993e073 ("MIPS: ftrace: Add support for syscall tracepoints.")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16651/
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f39f3b5d8260de549887f127ac5e99f0931b4990
Author: James Hogan <james.hogan@imgtec.com>
Date:   Wed May 31 16:19:49 2017 +0100

    MIPS: Fix mips_atomic_set() with EVA
    
    commit 4915e1b043d6286928207b1f6968197b50407294 upstream.
    
    EVA linked loads (LLE) and conditional stores (SCE) should be used on
    EVA kernels for the MIPS_ATOMIC_SET operation of the sysmips system
    call, or else the atomic set will apply to the kernel view of the
    virtual address space (potentially unmapped on EVA kernels) rather than
    the user view (TLB mapped).
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16151/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd2f83263dd8ecc4e325fe5f1aed5a930edbe643
Author: James Hogan <james.hogan@imgtec.com>
Date:   Wed May 31 16:19:47 2017 +0100

    MIPS: Fix mips_atomic_set() retry condition
    
    commit 2ec420b26f7b6ff332393f0bb5a7d245f7ad87f0 upstream.
    
    The inline asm retry check in the MIPS_ATOMIC_SET operation of the
    sysmips system call has been backwards since commit f1e39a4a616c ("MIPS:
    Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
    merged in v2.6.32, resulting in the non R10000_LLSC_WAR case retrying
    until the operation was inatomic, before returning the new value that
    was probably just written multiple times instead of the old value.
    
    Invert the branch condition to fix that particular issue.
    
    Fixes: f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16148/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 198bd494cebfad07c251d9fd26279393c81d8dec
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jul 12 10:35:57 2017 +0300

    ftrace: Fix uninitialized variable in match_records()
    
    commit 2e028c4fe12907f226b8221815f16c2486ad3aa7 upstream.
    
    My static checker complains that if "func" is NULL then "clear_filter"
    is uninitialized.  This seems like it could be true, although it's
    possible something subtle is happening that I haven't seen.
    
        kernel/trace/ftrace.c:3844 match_records()
        error: uninitialized symbol 'clear_filter'.
    
    Link: http://lkml.kernel.org/r/20170712073556.h6tkpjcdzjaozozs@mwanda
    
    Fixes: f0a3b154bd7 ("ftrace: Clarify code for mod command")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d17cc7b7a7522c908636b32beee7537f64e3c043
Author: Marta Rybczynska <mrybczyn@kalray.eu>
Date:   Tue Jun 6 13:27:21 2017 +0200

    nvme-rdma: remove race conditions from IB signalling
    
    commit 5e599d73c1c1816af07f94ddba879499aa39b43c upstream.
    
    This patch improves the way the RDMA IB signalling is done by using atomic
    operations for the signalling variable. This avoids race conditions on
    sig_count.
    
    The signalling interval changes slightly and is now the largest power of
    two not larger than queue depth / 2.
    
    ilog() usage idea by Bart Van Assche.
    
    Signed-off-by: Marta Rybczynska <marta.rybczynska@kalray.eu>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f9dec0c2dbb99aa36fa2d242828d853abde8eb0
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Wed Jun 28 13:50:05 2017 -0600

    vfio: New external user group/file match
    
    commit 5d6dee80a1e94cc284d03e06d930e60e8d3ecf7d upstream.
    
    At the point where the kvm-vfio pseudo device wants to release its
    vfio group reference, we can't always acquire a new reference to make
    that happen.  The group can be in a state where we wouldn't allow a
    new reference to be added.  This new helper function allows a caller
    to match a file to a group to facilitate this.  Given a file and
    group, report if they match.  Thus the caller needs to already have a
    group reference to match to the file.  This allows the deletion of a
    group without acquiring a new reference.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Tested-by: Eric Auger <eric.auger@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e91a55790ddfbda7f9f72963e561d9c738f14a52
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Jun 19 09:10:32 2017 -0600

    vfio: Fix group release deadlock
    
    commit 811642d8d8a82c0cce8dc2debfdaf23c5a144839 upstream.
    
    If vfio_iommu_group_notifier() acquires a group reference and that
    reference becomes the last reference to the group, then vfio_group_put
    introduces a deadlock code path where we're trying to unregister from
    the iommu notifier chain from within a callout of that chain.  Use a
    work_struct to release this reference asynchronously.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Tested-by: Eric Auger <eric.auger@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fee760fc6c79998efc48bd06afeec31824dfb2d4
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Tue Jan 10 21:30:21 2017 +0300

    ovl: drop CAP_SYS_RESOURCE from saved mounter's credentials
    
    commit 51f8f3c4e22535933ef9aecc00e9a6069e051b57 upstream.
    
    If overlay was mounted by root then quota set for upper layer does not work
    because overlay now always use mounter's credentials for operations.
    Also overlay might deplete reserved space and inodes in ext4.
    
    This patch drops capability SYS_RESOURCE from saved credentials.
    This affects creation new files, whiteouts, and copy-up operations.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Fixes: 1175b6b8d963 ("ovl: do operations on underlying file system in mounter's context")
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fb615f9cad7966267cd1904766a1b3059336f76
Author: John Brooks <john@fastquake.com>
Date:   Mon Jul 3 14:05:34 2017 -0400

    drm/ttm: Fix use-after-free in ttm_bo_clean_mm
    
    commit 8046e1955465e3f24e9154d0f2a2e0a8e3f8dccf upstream.
    
    We unref the man->move fence in ttm_bo_clean_mm() and then call
    ttm_bo_force_list_clean() which waits on it, except the refcount is now
    zero so a warning is generated (or worse):
    
    [149492.279301] refcount_t: increment on 0; use-after-free.
    [149492.279309] ------------[ cut here ]------------
    [149492.279315] WARNING: CPU: 3 PID: 18726 at lib/refcount.c:150 refcount_inc+0x2b/0x30
    [149492.279315] Modules linked in: vhost_net vhost tun x86_pkg_temp_thermal crc32_pclmul ghash_clmulni_intel efivarfs amdgpu(
    -) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm
    [149492.279326] CPU: 3 PID: 18726 Comm: rmmod Not tainted 4.12.0-rc5-drm-next-4.13-ttmpatch+ #1
    [149492.279326] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014
    [149492.279327] task: ffff8804ddfedcc0 task.stack: ffffc90008d20000
    [149492.279329] RIP: 0010:refcount_inc+0x2b/0x30
    [149492.279330] RSP: 0018:ffffc90008d23c30 EFLAGS: 00010286
    [149492.279331] RAX: 000000000000002b RBX: 0000000000000170 RCX: 0000000000000000
    [149492.279331] RDX: 0000000000000000 RSI: ffff88051ecccbe8 RDI: ffff88051ecccbe8
    [149492.279332] RBP: ffffc90008d23c30 R08: 0000000000000001 R09: 00000000000003ee
    [149492.279333] R10: ffffc90008d23bb0 R11: 00000000000003ee R12: ffff88043aaac960
    [149492.279333] R13: ffff8805005e28a8 R14: 0000000000000002 R15: ffff88050115e178
    [149492.279334] FS:  00007fc540168700(0000) GS:ffff88051ecc0000(0000) knlGS:0000000000000000
    [149492.279335] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [149492.279336] CR2: 00007fc3e8654140 CR3: 000000027ba77000 CR4: 00000000001426e0
    [149492.279337] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [149492.279337] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [149492.279338] Call Trace:
    [149492.279345]  ttm_bo_force_list_clean+0xb9/0x110 [ttm]
    [149492.279348]  ttm_bo_clean_mm+0x7a/0xe0 [ttm]
    [149492.279375]  amdgpu_ttm_fini+0xc9/0x1f0 [amdgpu]
    [149492.279392]  amdgpu_bo_fini+0x12/0x40 [amdgpu]
    [149492.279415]  gmc_v7_0_sw_fini+0x32/0x40 [amdgpu]
    [149492.279430]  amdgpu_fini+0x2c9/0x490 [amdgpu]
    [149492.279445]  amdgpu_device_fini+0x58/0x1b0 [amdgpu]
    [149492.279461]  amdgpu_driver_unload_kms+0x4f/0xa0 [amdgpu]
    [149492.279470]  drm_dev_unregister+0x3c/0xe0 [drm]
    [149492.279485]  amdgpu_pci_remove+0x19/0x30 [amdgpu]
    [149492.279487]  pci_device_remove+0x39/0xc0
    [149492.279490]  device_release_driver_internal+0x155/0x210
    [149492.279491]  driver_detach+0x38/0x70
    [149492.279493]  bus_remove_driver+0x4c/0xa0
    [149492.279494]  driver_unregister+0x2c/0x40
    [149492.279496]  pci_unregister_driver+0x21/0x90
    [149492.279520]  amdgpu_exit+0x15/0x406 [amdgpu]
    [149492.279523]  SyS_delete_module+0x1a8/0x270
    [149492.279525]  ? exit_to_usermode_loop+0x92/0xa0
    [149492.279528]  entry_SYSCALL_64_fastpath+0x13/0x94
    [149492.279529] RIP: 0033:0x7fc53fcb68e7
    [149492.279529] RSP: 002b:00007ffcfbfaabb8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [149492.279531] RAX: ffffffffffffffda RBX: 0000563117adb200 RCX: 00007fc53fcb68e7
    [149492.279531] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000563117adb268
    [149492.279532] RBP: 0000000000000003 R08: 0000000000000000 R09: 1999999999999999
    [149492.279533] R10: 0000000000000883 R11: 0000000000000206 R12: 00007ffcfbfa9ba0
    [149492.279533] R13: 0000000000000000 R14: 0000000000000000 R15: 0000563117adb200
    [149492.279534] Code: 55 48 89 e5 e8 77 fe ff ff 84 c0 74 02 5d c3 80 3d 40 f2 a4 00 00 75 f5 48 c7 c7 20 3c ca 81 c6 05 30 f2 a4 00 01 e8 91 f0 d7 ff <0f> ff 5d c3 90 55 48 89 fe bf 01 00 00 00 48 89 e5 e8 9f fe ff
    [149492.279557] ---[ end trace 2d4e0ffcb66a1016 ]---
    
    Unref the fence *after* waiting for it.
    
    v2: Set man->move to NULL after dropping the last ref (Christian König)
    
    Fixes: aff98ba1fdb8 (drm/ttm: wait for eviction in ttm_bo_force_list_clean)
    Signed-off-by: John Brooks <john@fastquake.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f97f9e94f666213b3cc59a6cff70b318154f2b09
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Jul 11 14:56:49 2017 -0700

    f2fs: Don't clear SGID when inheriting ACLs
    
    commit c925dc162f770578ff4a65ec9b08270382dba9e6 upstream.
    
    This patch copies commit b7f8a09f80:
    "btrfs: Don't clear SGID when inheriting ACLs" written by Jan.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19e117a50135efbb1d7c5ab1f24522162cc30bf0
Author: Jin Qian <jinqian@android.com>
Date:   Thu Jun 1 11:18:30 2017 -0700

    f2fs: sanity check size of nat and sit cache
    
    commit 21d3f8e1c3b7996ce239ab6fa82e9f7a8c47d84d upstream.
    
    Make sure number of entires doesn't exceed max journal size.
    
    Signed-off-by: Jin Qian <jinqian@android.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58d2eacd3b0ef6eb7d7a786021f1bcd7f147082d
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jun 26 08:48:18 2017 -0700

    xfs: Don't clear SGID when inheriting ACLs
    
    commit 8ba358756aa08414fa9e65a1a41d28304ed6fd7f upstream.
    
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
    
    Fix the problem by calling __xfs_set_acl() instead of xfs_set_acl() when
    setting up inode in xfs_generic_create(). That prevents SGID bit
    clearing and mode is properly set by posix_acl_create() anyway. We also
    reorder arguments of __xfs_set_acl() to match the ordering of
    xfs_set_acl() to make things consistent.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    CC: Darrick J. Wong <darrick.wong@oracle.com>
    CC: linux-xfs@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b9008cdae94e6c4ae42bc90bf031b9fefcf7a93
Author: Corey Minyard <cminyard@mvista.com>
Date:   Fri Jun 30 07:18:08 2017 -0500

    ipmi:ssif: Add missing unlock in error branch
    
    commit 4495ec6d770e1bca7a04e93ac453ab6720c56c5d upstream.
    
    When getting flags, a response to a different message would
    result in a deadlock because of a missing unlock.  Add that
    unlock and a comment.  Found by static analysis.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 685e124ebc7f11de248b68f883cd845523a63fc9
Author: Tony Camuso <tcamuso@redhat.com>
Date:   Mon Jun 19 13:17:33 2017 -0400

    ipmi: use rcu lock around call to intf->handlers->sender()
    
    commit cdea46566bb21ce309725a024208322a409055cc upstream.
    
    A vendor with a system having more than 128 CPUs occasionally encounters
    the following crash during shutdown. This is not an easily reproduceable
    event, but the vendor was able to provide the following analysis of the
    crash, which exhibits the same footprint each time.
    
    crash> bt
    PID: 0      TASK: ffff88017c70ce70  CPU: 5   COMMAND: "swapper/5"
     #0 [ffff88085c143ac8] machine_kexec at ffffffff81059c8b
     #1 [ffff88085c143b28] __crash_kexec at ffffffff811052e2
     #2 [ffff88085c143bf8] crash_kexec at ffffffff811053d0
     #3 [ffff88085c143c10] oops_end at ffffffff8168ef88
     #4 [ffff88085c143c38] no_context at ffffffff8167ebb3
     #5 [ffff88085c143c88] __bad_area_nosemaphore at ffffffff8167ec49
     #6 [ffff88085c143cd0] bad_area_nosemaphore at ffffffff8167edb3
     #7 [ffff88085c143ce0] __do_page_fault at ffffffff81691d1e
     #8 [ffff88085c143d40] do_page_fault at ffffffff81691ec5
     #9 [ffff88085c143d70] page_fault at ffffffff8168e188
        [exception RIP: unknown or invalid address]
        RIP: ffffffffa053c800  RSP: ffff88085c143e28  RFLAGS: 00010206
        RAX: ffff88017c72bfd8  RBX: ffff88017a8dc000  RCX: ffff8810588b5ac8
        RDX: ffff8810588b5a00  RSI: ffffffffa053c800  RDI: ffff8810588b5a00
        RBP: ffff88085c143e58   R8: ffff88017c70d408   R9: ffff88017a8dc000
        R10: 0000000000000002  R11: ffff88085c143da0  R12: ffff8810588b5ac8
        R13: 0000000000000100  R14: ffffffffa053c800  R15: ffff8810588b5a00
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
        <IRQ stack>
        [exception RIP: cpuidle_enter_state+82]
        RIP: ffffffff81514192  RSP: ffff88017c72be50  RFLAGS: 00000202
        RAX: 0000001e4c3c6f16  RBX: 000000000000f8a0  RCX: 0000000000000018
        RDX: 0000000225c17d03  RSI: ffff88017c72bfd8  RDI: 0000001e4c3c6f16
        RBP: ffff88017c72be78   R8: 000000000000237e   R9: 0000000000000018
        R10: 0000000000002494  R11: 0000000000000001  R12: ffff88017c72be20
        R13: ffff88085c14f8e0  R14: 0000000000000082  R15: 0000001e4c3bb400
        ORIG_RAX: ffffffffffffff10  CS: 0010  SS: 0018
    
    This is the corresponding stack trace
    
    It has crashed because the area pointed with RIP extracted from timer
    element is already removed during a shutdown process.
    
    The function is smi_timeout().
    
    And we think ffff8810588b5a00 in RDX is a parameter struct smi_info
    
    crash> rd ffff8810588b5a00 20
    ffff8810588b5a00:  ffff8810588b6000 0000000000000000   .`.X............
    ffff8810588b5a10:  ffff880853264400 ffffffffa05417e0   .D&S......T.....
    ffff8810588b5a20:  24a024a000000000 0000000000000000   .....$.$........
    ffff8810588b5a30:  0000000000000000 0000000000000000   ................
    ffff8810588b5a30:  0000000000000000 0000000000000000   ................
    ffff8810588b5a40:  ffffffffa053a040 ffffffffa053a060   @.S.....`.S.....
    ffff8810588b5a50:  0000000000000000 0000000100000001   ................
    ffff8810588b5a60:  0000000000000000 0000000000000e00   ................
    ffff8810588b5a70:  ffffffffa053a580 ffffffffa053a6e0   ..S.......S.....
    ffff8810588b5a80:  ffffffffa053a4a0 ffffffffa053a250   ..S.....P.S.....
    ffff8810588b5a90:  0000000500000002 0000000000000000   ................
    
    Unfortunately the top of this area is already detroyed by someone.
    But because of two reasonns we think this is struct smi_info
     1) The address included in between  ffff8810588b5a70 and ffff8810588b5a80:
      are inside of ipmi_si_intf.c  see crash> module ffff88085779d2c0
    
     2) We've found the area which point this.
      It is offset 0x68 of  ffff880859df4000
    
    crash> rd  ffff880859df4000 100
    ffff880859df4000:  0000000000000000 0000000000000001   ................
    ffff880859df4010:  ffffffffa0535290 dead000000000200   .RS.............
    ffff880859df4020:  ffff880859df4020 ffff880859df4020    @.Y.... @.Y....
    ffff880859df4030:  0000000000000002 0000000000100010   ................
    ffff880859df4040:  ffff880859df4040 ffff880859df4040   @@.Y....@@.Y....
    ffff880859df4050:  0000000000000000 0000000000000000   ................
    ffff880859df4060:  0000000000000000 ffff8810588b5a00   .........Z.X....
    ffff880859df4070:  0000000000000001 ffff880859df4078   ........x@.Y....
    
     If we regards it as struct ipmi_smi in shutdown process
     it looks consistent.
    
    The remedy for this apparent race is affixed below.
    
    Signed-off-by: Tony Camuso <tcamuso@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    This was first introduced in 7ea0ed2b5be817 ipmi: Make the
    message handler easier to use for SMI interfaces
    where some code was moved outside of the rcu_read_lock()
    and the lock was not added.
    
    Signed-off-by: Corey Minyard <cminyard@mvista.com>

commit 6e7b1eff91aa3bcc222e665328bea9988b453218
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Fri Jul 7 04:57:04 2017 +0200

    drm/radeon: Fix eDP for single-display iMac10,1 (v2)
    
    commit 564d8a2cf3abf16575af48bdc3e86e92ee8a617d upstream.
    
    The late 2009, 27 inch Apple iMac10,1 has an
    internal eDP display and an external Mini-
    Displayport output, driven by a DCE-3.2, RV730
    Radeon Mobility HD-4670.
    
    The machine worked fine in a dual-display setup
    with eDP panel + externally connected HDMI
    or DVI-D digital display sink, connected via
    MiniDP to DVI or HDMI adapter.
    
    However, booting the machine single-display with
    only eDP panel results in a completely black
    display - even backlight powering off, as soon as
    the radeon modesetting driver loads.
    
    This patch fixes the single dispay eDP case by
    assigning encoders based on dig->linkb, similar
    to DCE-4+. While this should not be generally
    necessary (Alex: "...atom on normal boards
    should be able to handle any mapping."), Apple
    seems to use some special routing here.
    
    One remaining problem not solved by this patch
    is that an external Minidisplayport->DP sink
    does still not work on iMac10,1, whereas external
    DVI and HDMI sinks continue to work.
    
    The problem affects at least all tested kernels
    since Linux 3.13 - didn't test earlier kernels, so
    backporting to stable probably makes sense.
    
    v2: With the original patch from 2016, Alex was worried it
        will break other DCE3.2 systems. Use dmi_match() to
        apply this special encoder assignment only for the
        Apple iMac 10,1 from late 2009.
    
    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a844f8d2a564d00d0043487d860a82d303b1a313
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu May 11 13:14:14 2017 -0400

    drm/radeon/ci: disable mclk switching for high refresh rates (v2)
    
    commit ab03d9fe508f4e2914a8f4a9eef1b21051cacd0f upstream.
    
    Even if the vblank period would allow it, it still seems to
    be problematic on some cards.
    
    v2: fix logic inversion (Nils)
    
    bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868
    
    Acked-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 b85007c9114a05c696c46c2aac6da68aeaed7bbc
Author: Tom St Denis <tom.stdenis@amd.com>
Date:   Tue May 23 11:35:22 2017 -0400

    drm/amd/amdgpu: Return error if initiating read out of range on vram
    
    commit 9156e723301c0a7a7def4cde820e018ce791b842 upstream.
    
    If you initiate a read that is out of the VRAM address space return
    ENXIO instead of 0.
    
    Reads that begin below that point will read upto the VRAM limit as
    before.
    
    Signed-off-by: Tom St Denis <tom.stdenis@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 8302e9d2f50b4358e4419deae2b09e0ccca766c6
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu Jun 29 11:38:11 2017 +0200

    s390/syscalls: Fix out of bounds arguments access
    
    commit c46fc0424ced3fb71208e72bd597d91b9169a781 upstream.
    
    Zorro reported following crash while having enabled
    syscall tracing (CONFIG_FTRACE_SYSCALLS):
    
      Unable to handle kernel pointer dereference at virtual ...
      Oops: 0011 [#1] SMP DEBUG_PAGEALLOC
    
      SNIP
    
      Call Trace:
      ([<000000000024d79c>] ftrace_syscall_enter+0xec/0x1d8)
       [<00000000001099c6>] do_syscall_trace_enter+0x236/0x2f8
       [<0000000000730f1c>] sysc_tracesys+0x1a/0x32
       [<000003fffcf946a2>] 0x3fffcf946a2
      INFO: lockdep is turned off.
      Last Breaking-Event-Address:
       [<000000000022dd44>] rb_event_data+0x34/0x40
      ---[ end trace 8c795f86b1b3f7b9 ]---
    
    The crash happens in syscall_get_arguments function for
    syscalls with zero arguments, that will try to access
    first argument (args[0]) in event entry, but it's not
    allocated.
    
    Bail out of there are no arguments.
    
    Reported-by: Zorro Lang <zlang@redhat.com>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e95148551f3ea57aef1a97d1b2a825be5a7704a
Author: Xiao Ni <xni@redhat.com>
Date:   Wed Jul 5 17:34:04 2017 +0800

    Raid5 should update rdev->sectors after reshape
    
    commit b5d27718f38843a74552e9a93d32e2391fd3999f upstream.
    
    The raid5 md device is created by the disks which we don't use the total size. For example,
    the size of the device is 5G and it just uses 3G of the devices to create one raid5 device.
    Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid
    and assemble it again. It fails.
    mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean
    mdadm /dev/md0 --grow --chunk=64
    wait reshape to finish
    mdadm -S /dev/md0
    mdadm -As
    The error messages:
    [197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing!
    [197519.821686] md: md_import_device returned -22
    
    After reshape the data offset is changed. It selects backwards direction in this condition.
    In function super_1_load it compares the available space of the underlying device with
    sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL.
    rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based
    on rdev->sectors. So add md_finish_reshape in end_reshape.
    
    Signed-off-by: Xiao Ni <xni@redhat.com>
    Acked-by: Guoqing Jiang <gqjiang@suse.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1f97eb59a472a11982d6fff9a722b681225e1a
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 21 14:34:15 2017 +0200

    ext2: Don't clear SGID when inheriting ACLs
    
    commit a992f2d38e4ce17b8c7d1f7f67b2de0eebdea069 upstream.
    
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
    
    Fix the problem by creating __ext2_set_acl() function that does not call
    posix_acl_update_mode() and use it when inheriting ACLs. That prevents
    SGID bit clearing and the mode has been properly set by
    posix_acl_create() anyway.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    CC: linux-ext4@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fa705dc61ee12e09827ac19225be3731b1cb988
Author: Toshi Kani <toshi.kani@hpe.com>
Date:   Fri Jul 7 17:44:26 2017 -0600

    libnvdimm: fix badblock range handling of ARS range
    
    commit 4e3f0701f25ab194c5362576b1146a1e6cc6c2e7 upstream.
    
    __add_badblock_range() does not account sector alignment when
    it sets 'num_sectors'.  Therefore, an ARS error record range
    spanning across two sectors is set to a single sector length,
    which leaves the 2nd sector unprotected.
    
    Change __add_badblock_range() to set 'num_sectors' properly.
    
    Fixes: 0caeef63e6d2 ("libnvdimm: Add a poison list and export badblocks")
    Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 891c31e16cb7aab2356625444f3eedebb96cde00
Author: Vishal Verma <vishal.l.verma@intel.com>
Date:   Thu Jun 29 16:59:11 2017 -0600

    libnvdimm, btt: fix btt_rw_page not returning errors
    
    commit c13c43d54f2c6a3be1c675766778ac1ad8dfbfcc upstream.
    
    btt_rw_page was not propagating errors frm btt_do_bvec, resulting in any
    IO errors via the rw_page path going unnoticed. the pmem driver recently
    fixed this in e10624f pmem: fail io-requests to known bad blocks
    but same problem in BTT went neglected.
    
    Fixes: 5212e11fde4d ("nd_btt: atomic sector updates")
    Cc: Toshi Kani <toshi.kani@hpe.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e82672f45ea3dd7511fcbe0098df3f4fe65c20e8
Author: Devin Heitmueller <dheitmueller@kernellabs.com>
Date:   Sat Sep 20 09:23:44 2014 -0300

    cx88: Fix regression in initial video standard setting
    
    commit 4e0973a918b9a42e217093f078e04a61e5dd95a5 upstream.
    
    Setting initial standard at the top of cx8800_initdev would cause the
    first call to cx88_set_tvnorm() to return without programming any
    registers (leaving the driver saying it's set to NTSC but the hardware
    isn't programmed).  Even worse, any subsequent attempt to explicitly
    set it to NTSC-M will return success but actually fail to program the
    underlying registers unless first changing the standard to something
    other than NTSC-M.
    
    Set the initial standard later in the process, and make sure the field
    is zero at the beginning to ensure that the call always goes through.
    
    This regression was introduced in the following commit:
    
    commit ccd6f1d488e7 ("[media] cx88: move width, height and field to core
    struct")
    
    Author: Hans Verkuil <hans.verkuil@cisco.com>
    
    [media] cx88: move width, height and field to core struct
    
    Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d3d3a1690c25205b36f6ec015458466e1ea6dae
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date:   Mon Jun 26 14:49:46 2017 +0200

    x86/xen: allow userspace access during hypercalls
    
    commit c54590cac51db8ab5fd30156bdaba34af915e629 upstream.
    
    Userspace application can do a hypercall through /dev/xen/privcmd, and
    some for some hypercalls argument is a pointers to user-provided
    structure. When SMAP is supported and enabled, hypervisor can't access.
    So, lets allow it.
    
    The same applies to HYPERVISOR_dm_op, where additionally privcmd driver
    carefully verify buffer addresses.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    [HYPERVISOR_dm_op dropped - not present until 4.11]
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03c1d9d45582e8a0991747a6f7a3a235b39b3e2b
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Jun 7 19:05:31 2017 -0400

    md: don't use flush_signals in userspace processes
    
    commit f9c79bc05a2a91f4fba8bfd653579e066714b1ec upstream.
    
    The function flush_signals clears all pending signals for the process. It
    may be used by kernel threads when we need to prepare a kernel thread for
    responding to signals. However using this function for an userspaces
    processes is incorrect - clearing signals without the program expecting it
    can cause misbehavior.
    
    The raid1 and raid5 code uses flush_signals in its request routine because
    it wants to prepare for an interruptible wait. This patch drops
    flush_signals and uses sigprocmask instead to block all signals (including
    SIGKILL) around the schedule() call. The signals are not lost, but the
    schedule() call won't respond to them.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Acked-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbc969ca944f1a3f61af083f4126bb5408d37b4c
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Wed Jul 19 16:16:55 2017 +0900

    usb: renesas_usbhs: gadget: disable all eps when the driver stops
    
    commit b8b9c974afee685789fcbb191b52d1790be3608c upstream.
    
    A gadget driver will not disable eps immediately when ->disconnect()
    is called. But, since this driver assumes all eps stop after
    the ->disconnect(), unexpected behavior happens (especially in system
    suspend).
    So, this patch disables all eps in usbhsg_try_stop(). After disabling
    eps by renesas_usbhs driver, since some functions will be called by
    both a gadget and renesas_usbhs driver, renesas_usbhs driver should
    protect uep->pipe. To protect uep->pipe easily, this patch adds a new
    lock in struct usbhsg_uep.
    
    Fixes: 2f98382dc ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5433bfcc85273a89c7c5a565a337697ff31ae499
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Wed Jul 19 16:16:54 2017 +0900

    usb: renesas_usbhs: fix usbhsc_resume() for !USBHSF_RUNTIME_PWCTRL
    
    commit 59a0879a0e17b2e43ecdc5e3299da85b8410d7ce upstream.
    
    This patch fixes an issue that some registers may be not initialized
    after resume if the USBHSF_RUNTIME_PWCTRL is not set. Otherwise,
    if a cable is not connected, the driver will not enable INTENB0.VBSE
    after resume. And then, the driver cannot detect the VBUS.
    
    Fixes: ca8a282a5373 ("usb: gadget: renesas_usbhs: add suspend/resume support")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a74779d8e1726da718e0a71066e5c4de5b07012c
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jul 12 15:08:39 2017 +0200

    USB: cdc-acm: add device-id for quirky printer
    
    commit fe855789d605590e57f9cd968d85ecce46f5c3fd upstream.
    
    Add device-id entry for DATECS FP-2000 fiscal printer needing the
    NO_UNION_NORMAL quirk.
    
    Reported-by: Anton Avramov <lukav@lukav.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8665f40a06a0794517f226cad694386faf9802c3
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Jul 6 16:06:32 2017 +0100

    usb: storage: return on error to avoid a null pointer dereference
    
    commit 446230f52a5bef593554510302465eabab45a372 upstream.
    
    When us->extra is null the driver is not initialized, however, a
    later call to osd200_scsi_to_ata is made that dereferences
    us->extra, causing a null pointer dereference.  The code
    currently detects and reports that the driver is not initialized;
    add a return to avoid the subsequent dereference issue in this
    check.
    
    Thanks to Alan Stern for pointing out that srb->result needs setting
    to DID_ERROR << 16
    
    Detected by CoverityScan, CID#100308 ("Dereference after null check")
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bc51b4f2a42187b4386974ef92add94acafe135
Author: Devin Heitmueller <dheitmueller@kernellabs.com>
Date:   Fri Apr 21 13:28:37 2017 -0300

    mxl111sf: Fix driver to use heap allocate buffers for USB messages
    
    commit d90b336f3f652ff0441e631a06236f785581c8f7 upstream.
    
    The recent changes in 4.9 to mandate USB buffers be heap allocated
    broke this driver, which was allocating the buffers on the stack.
    This resulted in the device failing at initialization.
    
    Introduce dedicated send/receive buffers as part of the state
    structure, and add a mutex to protect access to them.
    
    Note: we also had to tweak the API to mxl111sf_ctrl_msg to pass
    the pointer to the state struct rather than the device, since
    we need it inside the function to access the buffers and the
    mutex.  This patch adjusts the callers to match the API change.
    
    Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
    Reported-by: Doug Lung <dlung0@gmail.com>
    Cc: Michael Ira Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24a950e16eb54d42f25e4074bc00ee4a746877ac
Author: Jiahau Chang <jiahau@gmail.com>
Date:   Thu Jul 20 14:48:27 2017 +0300

    xhci: Bad Ethernet performance plugged in ASM1042A host
    
    commit 9da5a1092b13468839b1a864b126cacfb72ad016 upstream.
    
    When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
    performance was manifesting in Web browser use (like download
    large file such as ISO image). It is known limitation of
    ASM1042A that is not compatible with driver scheduling,
    As a workaround we can modify flow control handling of ASM1042A.
    The register we modify is changes the behavior
    
    [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias]
    Signed-off-by: Jiahau Chang <Lars_chang@asmedia.com.tw>
    Signed-off-by: Ian Pilcher <arequipeno@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01845a8347b73ddc89c0e7a81a108a4786ff07ea
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Jul 20 14:48:26 2017 +0300

    xhci: Fix NULL pointer dereference when cleaning up streams for removed host
    
    commit 4b895868bb2da60a386a17cde3bf9ecbc70c79f4 upstream.
    
    This off by one in stream_id indexing caused NULL pointer dereference and
    soft lockup on machines with USB attached SCSI devices connected to a
    hotpluggable xhci controller.
    
    The code that cleans up pending URBs for dead hosts tried to dereference
    a stream ring at the invalid stream_id 0.
    ep->stream_info->stream_rings[0] doesn't point to a ring.
    
    Start looping stream_id from 1 like in all the other places in the driver,
    and check that the ring exists before trying to kill URBs on it.
    
    Reported-by: rocko r <rockorequin@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf0440882ea94629b198b132ce89c11e25b4b91d
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Jul 20 14:48:29 2017 +0300

    xhci: fix 20000ms port resume timeout
    
    commit a54408d0a004757789863d74e29c2297edae0b4d upstream.
    
    A uncleared PLC (port link change) bit will prevent furuther port event
    interrupts for that port. Leaving it uncleared caused get_port_status()
    to timeout after 20000ms while waiting to get the final port event
    interrupt for resume -> U0 state change.
    
    This is a targeted fix for a specific case where we get a port resume event
    racing with xhci resume. The port event interrupt handler notices xHC is
    not yet running and bails out early, leaving PLC uncleared.
    
    The whole xhci port resuming needs more attention, but while working on it
    it anyways makes sense to always ensure PLC is cleared in get_port_status
    before setting a new link state and waiting for its completion.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 445ea10969aade3f9711b262756099717a5fe6bb
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sat Apr 29 20:33:09 2017 +0300

    ipvs: SNAT packet replies only for NATed connections
    
    commit 3c5ab3f395d66a9e4e937fcfdf6ebc63894f028b upstream.
    
    We do not check if packet from real server is for NAT
    connection before performing SNAT. This causes problems
    for setups that use DR/TUN and allow local clients to
    access the real server directly, for example:
    
    - local client in director creates IPVS-DR/TUN connection
    CIP->VIP and the request packets are routed to RIP.
    Talks are finished but IPVS connection is not expired yet.
    
    - second local client creates non-IPVS connection CIP->RIP
    with same reply tuple RIP->CIP and when replies are received
    on LOCAL_IN we wrongly assign them for the first client
    connection because RIP->CIP matches the reply direction.
    As result, IPVS SNATs replies for non-IPVS connections.
    
    The problem is more visible to local UDP clients but in rare
    cases it can happen also for TCP or remote clients when the
    real server sends the reply traffic via the director.
    
    So, better to be more precise for the reply traffic.
    As replies are not expected for DR/TUN connections, better
    to not touch them.
    
    Reported-by: Nick Moriarty <nick.moriarty@york.ac.uk>
    Tested-by: Nick Moriarty <nick.moriarty@york.ac.uk>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33780512d9fe64872b3c46596d2c6d812be98fc9
Author: Chen Yu <yu.c.chen@intel.com>
Date:   Thu May 25 16:49:07 2017 +0800

    PCI/PM: Restore the status of PCI devices across hibernation
    
    commit e60514bd4485c0c7c5a7cf779b200ce0b95c70d6 upstream.
    
    Currently we saw a lot of "No irq handler" errors during hibernation, which
    caused the system hang finally:
    
      ata4.00: qc timeout (cmd 0xec)
      ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
      ata4.00: revalidation failed (errno=-5)
      ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
      do_IRQ: 31.151 No irq handler for vector
    
    According to above logs, there is an interrupt triggered and it is
    dispatched to CPU31 with a vector number 151, but there is no handler for
    it, thus this IRQ will not get acked and will cause an IRQ flood which
    kills the system.  To be more specific, the 31.151 is an interrupt from the
    AHCI host controller.
    
    After some investigation, the reason why this issue is triggered is because
    the thaw_noirq() function does not restore the MSI/MSI-X settings across
    hibernation.
    
    The scenario is illustrated below:
    
      1. Before hibernation, IRQ 34 is the handler for the AHCI device, which
         is bound to CPU31.
    
      2. Hibernation starts, the AHCI device is put into low power state.
    
      3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to
         the last alive one - CPU0.
    
      4. After the snapshot has been created, all the nonboot CPUs are brought
         up again; IRQ 34 remains bound to CPU0.
    
      5. AHCI devices are put into D0.
    
      6. The snapshot is written to the disk.
    
    The issue is triggered in step 6.  The AHCI interrupt should be delivered
    to CPU0, however it is delivered to the original CPU31 instead, which
    causes the "No irq handler" issue.
    
    Ying Huang has provided a clue that, in step 3 it is possible that writing
    to the register might not take effect as the PCI devices have been
    suspended.
    
    In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but
    in fact it is not.  In __pci_write_msi_msg(), if the device is already in
    low power state, the low level MSI message entry will not be updated but
    cached.  During the device restore process after a normal suspend/resume,
    pci_restore_msi_state() writes the cached MSI back to the hardware.
    
    But this is not the case for hibernation.  pci_restore_msi_state() is not
    currently called in pci_pm_thaw_noirq(), although pci_save_state() has
    saved the necessary PCI cached information in pci_pm_freeze_noirq().
    
    Restore the PCI status for the device during hibernation.  Otherwise the
    status might be lost across hibernation (for example, settings for MSI,
    MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation.
    
    Suggested-by: Ying Huang <ying.huang@intel.com>
    Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Chen Yu <yu.c.chen@intel.com>
    [bhelgaas: changelog]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Len Brown <len.brown@intel.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Rui Zhang <rui.zhang@intel.com>
    Cc: Ying Huang <ying.huang@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f257f4bf6f0766725fd8bcb243ad9271aee7a106
Author: Shawn Lin <shawn.lin@rock-chips.com>
Date:   Mon Jul 3 17:21:02 2017 +0800

    PCI: rockchip: Use normal register bank for config accessors
    
    commit dc8cca5ef25ac4cb0dfc37467521a759767ff361 upstream.
    
    Rockchip's RC has two banks of registers for the root port: a normal bank
    that is strictly compatible with the PCIe spec, and a privileged bank that
    can be used to change RO bits of root port registers.
    
    When probing the RC driver, we use the privileged bank to do some basic
    setup work as some RO bits are hw-inited to wrong value.  But we didn't
    change to the normal bank after probing the driver.
    
    This leads to a serious problem when the PME code tries to clear the PME
    status by writing PCI_EXP_RTSTA_PME to the register of PCI_EXP_RTSTA.  Per
    PCIe 3.0 spec, section 7.8.14, the PME status bit is RW1C.  So the PME code
    is doing the right thing to clear the PME status but we find the RC doesn't
    clear it but actually setting it to one.  So finally the system trap in
    pcie_pme_work_fn() as PCI_EXP_RTSTA_PME is true now forever.  This issue
    can be reproduced by booting kernel with pci=nomsi.
    
    Use the normal register bank for the PCI config accessors.  The privileged
    bank is used only internally by this driver.
    
    Fixes: e77f847d ("PCI: rockchip: Add Rockchip PCIe controller support")
    Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
    Cc: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13b2f9f9b8aaa2085a2fcf946b8280f4e3d0f4f8
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Fri Aug 19 16:30:25 2016 +0800

    PCI: Work around poweroff & suspend-to-RAM issue on Macbook Pro 11
    
    commit 13cfc732160f7bc7e596128ce34cda361c556966 upstream.
    
    Neither soft poweroff (transition to ACPI power state S5) nor
    suspend-to-RAM (transition to state S3) works on the Macbook Pro 11,4 and
    11,5.
    
    The problem is related to the [mem 0x7fa00000-0x7fbfffff] space.  When we
    use that space, e.g., by assigning it to the 00:1c.0 Root Port, the ACPI
    Power Management 1 Control Register (PM1_CNT) at [io 0x1804] doesn't work
    anymore.
    
    Linux does a soft poweroff (transition to S5) by writing to PM1_CNT.  The
    theory about why this doesn't work is:
    
      - The write to PM1_CNT causes an SMI
      - The BIOS SMI handler depends on something in
        [mem 0x7fa00000-0x7fbfffff]
      - When Linux assigns [mem 0x7fa00000-0x7fbfffff] to the 00:1c.0 Port, it
        covers up whatever the SMI handler uses, so the SMI handler no longer
        works correctly
    
    Reserve the [mem 0x7fa00000-0x7fbfffff] space so we don't assign it to
    anything.
    
    This is voodoo programming, since we don't know what the real conflict is,
    but we've failed to find the root cause.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
    Tested-by: thejoe@gmail.com
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Rafael J. Wysocki <rafael@kernel.org>
    Cc: Lukas Wunner <lukas@wunner.de>
    Cc: Chen Yu <yu.c.chen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c17d418afb017792aa961e6eebb2ecc1ca5c775
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Apr 13 18:35:59 2017 +0800

    af_key: Fix sadb_x_ipsecrequest parsing
    
    commit 096f41d3a8fcbb8dde7f71379b1ca85fe213eded upstream.
    
    The parsing of sadb_x_ipsecrequest is broken in a number of ways.
    First of all we're not verifying sadb_x_ipsecrequest_len.  This
    is needed when the structure carries addresses at the end.  Worse
    we don't even look at the length when we parse those optional
    addresses.
    
    The migration code had similar parsing code that's better but
    it also has some deficiencies.  The length is overcounted first
    of all as it includes the header itself.  It also fails to check
    the length before dereferencing the sa_family field.
    
    This patch fixes those problems in parse_sockaddr_pair and then
    uses it in parse_ipsecrequest.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b7babc6be0aa56297b5d1dea0090339a2d5659d
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Sat Jul 8 07:45:32 2017 -0500

    powerpc/mm/radix: Properly clear process table entry
    
    commit c6bb0b8d426a8cf865ca9c8a532cc3a2927cfceb upstream.
    
    On radix, the process table entry we want to clear when destroying a
    context is entry 0, not entry 1. This has no *immediate* consequence
    on Power9, but it can cause other bugs to become worse.
    
    Fixes: 7e381c0ff618 ("powerpc/mm/radix: Add mmu context handling callback for radix")
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88481a2c40e49912d0671cc7e9a5bd3534662b49
Author: Oliver O'Halloran <oohall@gmail.com>
Date:   Thu Jul 6 18:46:43 2017 +1000

    powerpc/asm: Mark cr0 as clobbered in mftb()
    
    commit 2400fd822f467cb4c886c879d8ad99feac9cf319 upstream.
    
    The workaround for the CELL timebase bug does not correctly mark cr0 as
    being clobbered. This means GCC doesn't know that the asm block changes cr0 and
    might leave the result of an unrelated comparison in cr0 across the block, which
    we then trash, leading to basically random behaviour.
    
    Fixes: 859deea949c3 ("[POWERPC] Cell timebase bug workaround")
    Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
    [mpe: Tweak change log and flag for stable]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e35ee249e26e36cae641bee8d212fba0e1bb6e6
Author: Anton Blanchard <anton@samba.org>
Date:   Thu Jun 15 09:46:39 2017 +1000

    powerpc: Fix emulation of mfocrf in emulate_step()
    
    commit 64e756c55aa46fc18fd53e8f3598b73b528d8637 upstream.
    
    From POWER4 onwards, mfocrf() only places the specified CR field into
    the destination GPR, and the rest of it is set to 0. The PowerPC AS
    from version 3.0 now requires this behaviour.
    
    The emulation code currently puts the entire CR into the destination GPR.
    Fix it.
    
    Fixes: 6888199f7fe5 ("[POWERPC] Emulate more instructions in software")
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53a28216131762700d10eb4755562b10c8d2685b
Author: Anton Blanchard <anton@samba.org>
Date:   Thu Jun 15 09:46:38 2017 +1000

    powerpc: Fix emulation of mcrf in emulate_step()
    
    commit 87c4b83e0fe234a1f0eed131ab6fa232036860d5 upstream.
    
    The mcrf emulation code was using the CR field number directly as the shift
    value, without taking into account that CR fields are numbered from 0-7 starting
    at the high bits. That meant it was looking at the CR fields in the reverse
    order.
    
    Fixes: cf87c3f6b647 ("powerpc: Emulate icbi, mcrf and conditional-trap instructions")
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99fc5a2254ef6409947e21b7b829cd59eb8234c5
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Jul 11 22:10:54 2017 +1000

    powerpc/64: Fix atomic64_inc_not_zero() to return an int
    
    commit 01e6a61aceb82e13bec29502a8eb70d9574f97ad upstream.
    
    Although it's not documented anywhere, there is an expectation that
    atomic64_inc_not_zero() returns a result which fits in an int. This is
    the behaviour implemented on all arches except powerpc.
    
    This has caused at least one bug in practice, in the percpu-refcount
    code, where the long result from our atomic64_inc_not_zero() was
    truncated to an int leading to lost references and stuck systems. That
    was worked around in that code in commit 966d2b04e070 ("percpu-refcount:
    fix reference leak during percpu-atomic transition").
    
    To the best of my grepping abilities there are no other callers
    in-tree which truncate the value, but we should fix it anyway. Because
    the breakage is subtle and potentially very harmful I'm also tagging
    it for stable.
    
    Code generation is largely unaffected because in most cases the
    callers are just using the result for a test anyway. In particular the
    case of fget() that was mentioned in commit a6cf7ed5119f
    ("powerpc/atomic: Implement atomic*_inc_not_zero") generates exactly
    the same code.
    
    Fixes: a6cf7ed5119f ("powerpc/atomic: Implement atomic*_inc_not_zero")
    Noticed-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d638c8584462609237b4d12563f871f2323ac819
Author: Balbir Singh <bsingharora@gmail.com>
Date:   Thu Jun 29 03:04:07 2017 +1000

    powerpc/pseries: Fix passing of pp0 in updatepp() and updateboltedpp()
    
    commit e71ff982ae4c17d176e9f0132157d54973788377 upstream.
    
    Once upon a time there were only two PP (page protection) bits. In ISA
    2.03 an additional PP bit was added, but because of the layout of the
    HPTE it could not be made contiguous with the existing PP bits.
    
    The result is that we now have three PP bits, named pp0, pp1, pp2,
    where pp0 occupies bit 63 of dword 1 of the HPTE and pp1 and pp2
    occupy bits 1 and 0 respectively. Until recently Linux hasn't used
    pp0, however with the addition of _PAGE_KERNEL_RO we started using it.
    
    The problem arises in the LPAR code, where we need to translate the PP
    bits into the argument for the H_PROTECT hypercall. Currently the code
    only passes bits 0-2 of newpp, which covers pp1, pp2 and N (no
    execute), meaning pp0 is not passed to the hypervisor at all.
    
    We can't simply pass it through in bit 63, as that would collide with a
    different field in the flags argument, as defined in PAPR. Instead we
    have to shift it down to bit 8 (IBM bit 55).
    
    Fixes: e58e87adc8bf ("powerpc/mm: Update _PAGE_KERNEL_RO")
    Signed-off-by: Balbir Singh <bsingharora@gmail.com>
    [mpe: Simplify the test, rework change log]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71b1caea95a8ab5b2e5f868a68a454283ed51109
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Tue May 23 16:48:36 2017 -0700

    xen/scsiback: Fix a TMR related use-after-free
    
    commit 9f4ab18ac51dc87345a9cbd2527e6acf7a0a9335 upstream.
    
    scsiback_release_cmd() must not dereference se_cmd->se_tmr_req
    because that memory is freed by target_free_cmd_mem() before
    scsiback_release_cmd() is called. Fix this use-after-free by
    inlining struct scsiback_tmr into struct vscsibk_pend.
    
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: David Disseldorp <ddiss@suse.de>
    Cc: xen-devel@lists.xenproject.org
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 732e3c76cf97451e8b58f666c1f54cd8b3f9d26f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Jul 7 14:45:49 2017 -0700

    iscsi-target: Add login_keys_workaround attribute for non RFC initiators
    
    commit 138d351eefb727ab9e41a3dc5f112ceb4f6e59f2 upstream.
    
    This patch re-introduces part of a long standing login workaround that
    was recently dropped by:
    
      commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46
      Author: Nicholas Bellinger <nab@linux-iscsi.org>
      Date:   Sun Apr 2 13:36:44 2017 -0700
    
          iscsi-target: Drop work-around for legacy GlobalSAN initiator
    
    Namely, the workaround for FirstBurstLength ended up being required by
    Mellanox Flexboot PXE boot ROMs as reported by Robert.
    
    So this patch re-adds the work-around for FirstBurstLength within
    iscsi_check_proposer_for_optional_reply(), and makes the key optional
    to respond when the initiator does not propose, nor respond to it.
    
    Also as requested by Arun, this patch introduces a new TPG attribute
    named 'login_keys_workaround' that controls the use of both the
    FirstBurstLength workaround, as well as the two other existing
    workarounds for gPXE iSCSI boot client.
    
    By default, the workaround is enabled with login_keys_workaround=1,
    since Mellanox FlexBoot requires it, and Arun has verified the Qlogic
    MSFT initiator already proposes FirstBurstLength, so it's uneffected
    by this re-adding this part of the original work-around.
    
    Reported-by: Robert LeBlanc <robert@leblancnet.us>
    Cc: Robert LeBlanc <robert@leblancnet.us>
    Reviewed-by: Arun Easi <arun.easi@cavium.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc866b296a463661f90ea734c40b1049c4834eaa
Author: Ewan D. Milne <emilne@redhat.com>
Date:   Tue Jun 27 14:55:58 2017 -0400

    scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state
    
    commit f9279c968c257ee39b0d7bd2571a4d231a67bcc1 upstream.
    
    The addition of the STARGET_REMOVE state had the side effect of
    introducing a race condition that can cause a crash.
    
    scsi_target_reap_ref_release() checks the starget->state to
    see if it still in STARGET_CREATED, and if so, skips calling
    transport_remove_device() and device_del(), because the starget->state
    is only set to STARGET_RUNNING after scsi_target_add() has called
    device_add() and transport_add_device().
    
    However, if an rport loss occurs while a target is being scanned,
    it can happen that scsi_remove_target() will be called while the
    starget is still in the STARGET_CREATED state.  In this case, the
    starget->state will be set to STARGET_REMOVE, and as a result,
    scsi_target_reap_ref_release() will take the wrong path.  The end
    result is a panic:
    
    [ 1255.356653] Oops: 0000 [#1] SMP
    [ 1255.360154] Modules linked in: x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel ghash_clmulni_i
    [ 1255.393234] CPU: 5 PID: 149 Comm: kworker/u96:4 Tainted: G        W       4.11.0+ #8
    [ 1255.401879] Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013
    [ 1255.410327] Workqueue: scsi_wq_6 fc_scsi_scan_rport [scsi_transport_fc]
    [ 1255.417720] task: ffff88060ca8c8c0 task.stack: ffffc900048a8000
    [ 1255.424331] RIP: 0010:kernfs_find_ns+0x13/0xc0
    [ 1255.429287] RSP: 0018:ffffc900048abbf0 EFLAGS: 00010246
    [ 1255.435123] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [ 1255.443083] RDX: 0000000000000000 RSI: ffffffff8188d659 RDI: 0000000000000000
    [ 1255.451043] RBP: ffffc900048abc10 R08: 0000000000000000 R09: 0000012433fe0025
    [ 1255.459005] R10: 0000000025e5a4b5 R11: 0000000025e5a4b5 R12: ffffffff8188d659
    [ 1255.466972] R13: 0000000000000000 R14: ffff8805f55e5088 R15: 0000000000000000
    [ 1255.474931] FS:  0000000000000000(0000) GS:ffff880616b40000(0000) knlGS:0000000000000000
    [ 1255.483959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1255.490370] CR2: 0000000000000068 CR3: 0000000001c09000 CR4: 00000000000406e0
    [ 1255.498332] Call Trace:
    [ 1255.501058]  kernfs_find_and_get_ns+0x31/0x60
    [ 1255.505916]  sysfs_unmerge_group+0x1d/0x60
    [ 1255.510498]  dpm_sysfs_remove+0x22/0x60
    [ 1255.514783]  device_del+0xf4/0x2e0
    [ 1255.518577]  ? device_remove_file+0x19/0x20
    [ 1255.523241]  attribute_container_class_device_del+0x1a/0x20
    [ 1255.529457]  transport_remove_classdev+0x4e/0x60
    [ 1255.534607]  ? transport_add_class_device+0x40/0x40
    [ 1255.540046]  attribute_container_device_trigger+0xb0/0xc0
    [ 1255.546069]  transport_remove_device+0x15/0x20
    [ 1255.551025]  scsi_target_reap_ref_release+0x25/0x40
    [ 1255.556467]  scsi_target_reap+0x2e/0x40
    [ 1255.560744]  __scsi_scan_target+0xaa/0x5b0
    [ 1255.565312]  scsi_scan_target+0xec/0x100
    [ 1255.569689]  fc_scsi_scan_rport+0xb1/0xc0 [scsi_transport_fc]
    [ 1255.576099]  process_one_work+0x14b/0x390
    [ 1255.580569]  worker_thread+0x4b/0x390
    [ 1255.584651]  kthread+0x109/0x140
    [ 1255.588251]  ? rescuer_thread+0x330/0x330
    [ 1255.592730]  ? kthread_park+0x60/0x60
    [ 1255.596815]  ret_from_fork+0x29/0x40
    [ 1255.600801] Code: 24 08 48 83 42 40 01 5b 41 5c 5d c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90
    [ 1255.621876] RIP: kernfs_find_ns+0x13/0xc0 RSP: ffffc900048abbf0
    [ 1255.628479] CR2: 0000000000000068
    [ 1255.632756] ---[ end trace 34a69ba0477d036f ]---
    
    Fix this by adding another scsi_target state STARGET_CREATED_REMOVE
    to distinguish this case.
    
    Fixes: f05795d3d771 ("scsi: Add intermediate STARGET_REMOVE state to scsi_target_state")
    Reported-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Laurence Oberman <loberman@redhat.com>
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 542c097f1cb61f57ad42ffd8431371d69e76aa03
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Tue Jun 27 11:53:27 2017 +0200

    scsi: ses: do not add a device to an enclosure if enclosure_add_links() fails.
    
    commit 62e62ffd95539b9220894a7900a619e0f3ef4756 upstream.
    
    The enclosure_add_device() function should fail if it can't create the
    relevant sysfs links.
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Tested-by: Douglas Miller <dougmill@linux.vnet.ibm.com>
    Acked-by: James Bottomley <jejb@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2bb0af4463d0fd094385d8e15f8f18c9adaafa4
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Wed Jun 28 16:56:20 2017 +0200

    PM / Domains: Fix unsafe iteration over modified list of domains
    
    commit a7e2d1bce4c1db471f1cbc0c4666a3112bbf0994 upstream.
    
    of_genpd_remove_last() iterates over list of domains and removes
    matching element thus it has to use safe version of list iteration.
    
    Fixes: 17926551c98a (PM / Domains: Add support for removing nested PM domains by provider)
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 178aa241fc070e5b34c5bbe3f9ae0a6b0b335840
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Wed Jun 28 16:56:19 2017 +0200

    PM / Domains: Fix unsafe iteration over modified list of domain providers
    
    commit b556b15dc04e9b9b98790f04c21acf5e24f994b2 upstream.
    
    of_genpd_del_provider() iterates over list of domain provides and
    removes matching element thus it has to use safe version of list
    iteration.
    
    Fixes: aa42240ab254 (PM / Domains: Add generic OF-based PM domain look-up)
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b87a32175a22fae2b15750477c1397970deafd68
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Wed Jun 28 16:56:18 2017 +0200

    PM / Domains: Fix unsafe iteration over modified list of device links
    
    commit c6e83cac3eda5f7dd32ee1453df2f7abb5c6cd46 upstream.
    
    pm_genpd_remove_subdomain() iterates over domain's master_links list and
    removes matching element thus it has to use safe version of list
    iteration.
    
    Fixes: f721889ff65a ("PM / Domains: Support for generic I/O PM domains (v8)")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d94276155f8bbd63b4ff1b3dc3ae9e14c9964e1
Author: Satish Babu Patakokila <sbpata@codeaurora.org>
Date:   Fri Jun 16 17:33:40 2017 -0700

    ASoC: compress: Derive substream from stream based on direction
    
    commit 01b8cedfd0422326caae308641dcadaa85e0ca72 upstream.
    
    Currently compress driver hardcodes direction as playback to get
    substream from the stream. This results in getting the incorrect
    substream for compressed capture usecase.
    To fix this, remove the hardcoding and derive substream based on
    the stream direction.
    
    Signed-off-by: Satish Babu Patakokila <sbpata@codeaurora.org>
    Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
    Acked-By: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a81c136f486803b211c0e8d68a1fa9b0d8e8444
Author: Matwey V Kornilov <matwey@sai.msu.ru>
Date:   Thu Nov 24 13:32:48 2016 +0300

    igb: Explicitly select page 0 at initialization
    
    commit 440aeca4b9858248d8f16d724d9fa87a4f65fa33 upstream.
    
    The functions igb_read_phy_reg_gs40g/igb_write_phy_reg_gs40g (which were
    removed in 2a3cdea) explicitly selected the required page at every phy_reg
    access. Currently, igb_get_phy_id_82575 relays on the fact that page 0 is
    already selected. The assumption is not fulfilled for my Lex 3I380CW
    motherboard with integrated dual i211 based gigabit ethernet. This leads to igb
    initialization failure and network interfaces are not working:
    
        igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
        igb: Copyright (c) 2007-2014 Intel Corporation.
        igb: probe of 0000:01:00.0 failed with error -2
        igb: probe of 0000:02:00.0 failed with error -2
    
    In order to fix it, we explicitly select page 0 before first access to phy
    registers.
    
    See also: https://bugzilla.suse.com/show_bug.cgi?id=1009911
    See also: http://www.lex.com.tw/products/pdf/3I380A&3I380CW.pdf
    
    Fixes: 2a3cdea ("igb: Remove GS40G specific defines/functions")
    Signed-off-by: Matwey V Kornilov <matwey@sai.msu.ru>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 157302f97aaa6f79854622a9aab7749fe8661d20
Author: Jan Kara <jack@suse.cz>
Date:   Thu Jun 22 15:31:07 2017 +0200

    btrfs: Don't clear SGID when inheriting ACLs
    
    commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream.
    
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
    
    Fix the problem by moving posix_acl_update_mode() out of
    __btrfs_set_acl() into btrfs_set_acl(). That way the function will not be
    called when inheriting ACLs which is what we want as it prevents SGID
    bit clearing and the mode has been properly set by posix_acl_create()
    anyway.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    CC: linux-btrfs@vger.kernel.org
    CC: David Sterba <dsterba@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 754f4e05e9994e734bf620bfd77a9d04ac55e7b4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu May 11 13:52:09 2017 +0200

    wlcore: fix 64K page support
    
    commit 4a4274bf2dbbd1c7a45be0c89a1687c9d2eef4a0 upstream.
    
    In the stable linux-3.16 branch, I ran into a warning in the
    wlcore driver:
    
    drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write':
    drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
    
    Newer kernels no longer show the warning, but the bug is still there,
    as the allocation is based on the CPU page size rather than the
    actual capabilities of the hardware.
    
    This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes
    per buffer.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3da27a9d982798ece7f09dd3b259be8fe0bc3a11
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Jun 10 04:59:11 2017 +0200

    Bluetooth: use constant time memory comparison for secret values
    
    commit 329d82309824ff1082dc4a91a5bbed8c3bec1580 upstream.
    
    This file is filled with complex cryptography. Thus, the comparisons of
    MACs and secret keys and curve points and so forth should not add timing
    attacks, which could either result in a direct forgery, or, given the
    complexity, some other type of attack.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe5cdbcdafaae75418307485b5d0ff5c66e250c4
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:09 2017 +0300

    perf intel-pt: Clear FUP flag on error
    
    commit 6a558f12dbe85437acbdec5e149ea07b5554eced upstream.
    
    Sometimes a FUP packet is associated with a TSX transaction and a flag is
    set to indicate that. Ensure that flag is cleared on any error condition
    because at that point the decoder can no longer assume it is correct.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-9-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94c38cd0aff23b38a7e78f82141081e986f560b5
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:08 2017 +0300

    perf intel-pt: Use FUP always when scanning for an IP
    
    commit 622b7a47b843c78626f40c1d1aeef8483383fba2 upstream.
    
    The decoder will try to use branch packets to find an IP to start decoding
    or to recover from errors. Currently the FUP packet is used only in the
    case of an overflow, however there is no reason for that to be a special
    case. So just use FUP always when scanning for an IP.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-8-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a16bd39c5012940955afa708e98ffbb32be31ce
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:07 2017 +0300

    perf intel-pt: Ensure never to set 'last_ip' when packet 'count' is zero
    
    commit f952eaceb089b691eba7c4e13686e742a8f26bf5 upstream.
    
    Intel PT uses IP compression based on the last IP. For decoding purposes,
    'last IP' is not updated when a branch target has been suppressed, which is
    indicated by IPBytes == 0. IPBytes is stored in the packet 'count', so
    ensure never to set 'last_ip' when packet 'count' is zero.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-7-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit daa637832dd2c64751369a39d8ad69e993a42a42
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:06 2017 +0300

    perf intel-pt: Fix last_ip usage
    
    commit ee14ac0ef6827cd6f9a572cc83dd0191ea17812c upstream.
    
    Intel PT uses IP compression based on the last IP. For decoding
    purposes, 'last IP' is considered to be reset to zero whenever there is
    a synchronization packet (PSB). The decoder wasn't doing that, and was
    treating the zero value to mean that there was no last IP, whereas
    compression can be done against the zero value. Fix by setting last_ip
    to zero when a PSB is received and keep track of have_last_ip.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-6-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc0401375f7a7a27ad56e1b0fc19dc470cf0f8d9
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:05 2017 +0300

    perf intel-pt: Ensure IP is zero when state is INTEL_PT_STATE_NO_IP
    
    commit ad7167a8cd174ba7d8c0d0ed8d8410521206d104 upstream.
    
    A value of zero is used to indicate that there is no IP. Ensure the
    value is zero when the state is INTEL_PT_STATE_NO_IP.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-5-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b338b87f2277e9c1a71749ec6985afe64be9efe8
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:04 2017 +0300

    perf intel-pt: Fix missing stack clear
    
    commit 12b7080609097753fd8198cc1daf589be3ec1cca upstream.
    
    The return compression stack must be cleared whenever there is a PSB. Fix
    one case where that was not happening.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-4-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e6837f1f414ea98f574abc31f04a1a5acb68203
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:03 2017 +0300

    perf intel-pt: Improve sample timestamp
    
    commit 3f04d98e972b59706bd43d6cc75efac91f8fba50 upstream.
    
    The decoder uses its current timestamp in samples. Usually that is a
    timestamp that has already passed, but in some cases it is a timestamp
    for a branch that the decoder is walking towards, and consequently
    hasn't reached. Improve that situation by using the pkt_state to
    determine when to use the current or previous timestamp.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-3-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3503ef1a6147be68f6208af01a9f81b11cc4877
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 26 11:17:02 2017 +0300

    perf intel-pt: Move decoder error setting into one condition
    
    commit 22c06892332d8916115525145b78e606e9cc6492 upstream.
    
    Move decoder error setting into one condition.
    
    Cc'ed to stable because later fixes depend on it.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/1495786658-18063-2-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 244a7db0e9d584af63e1cfe4911d3200d1b180ee
Author: Mateusz Jurczyk <mjurczyk@google.com>
Date:   Tue Jun 13 18:44:28 2017 +0200

    NFC: Add sockaddr length checks before accessing sa_family in bind handlers
    
    commit f6a5885fc4d68e7f25ffb42b9d8d80aebb3bacbb upstream.
    
    Verify that the caller-provided sockaddr structure is large enough to
    contain the sa_family field, before accessing it in bind() handlers of the
    AF_NFC socket. Since the syscall doesn't enforce a minimum size of the
    corresponding memory region, very short sockaddrs (zero or one byte long)
    result in operating on uninitialized memory while referencing .sa_family.
    
    Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a142251a315e4df6f12a7c99a2a6dfe4ac273ec
Author: Mateusz Jurczyk <mjurczyk@google.com>
Date:   Wed May 24 12:26:20 2017 +0200

    nfc: Fix the sockaddr length sanitization in llcp_sock_connect
    
    commit 608c4adfcabab220142ee335a2a003ccd1c0b25b upstream.
    
    Fix the sockaddr length verification in the connect() handler of NFC/LLCP
    sockets, to compare against the size of the actual structure expected on
    input (sockaddr_nfc_llcp) instead of its shorter version (sockaddr_nfc).
    
    Both structures are defined in include/uapi/linux/nfc.h. The fields
    specific to the _llcp extended struct are as follows:
    
       276          __u8 dsap; /* Destination SAP, if known */
       277          __u8 ssap; /* Source SAP to be bound to */
       278          char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* Service name URI */;
       279          size_t service_name_len;
    
    If the caller doesn't provide a sufficiently long sockaddr buffer, these
    fields remain uninitialized (and they currently originate from the stack
    frame of the top-level sys_connect handler). They are then copied by
    llcp_sock_connect() into internal storage (nfc_llcp_sock structure), and
    could be subsequently read back through the user-mode getsockname()
    function (handled by llcp_sock_getname()). This would result in the
    disclosure of up to ~70 uninitialized bytes from the kernel stack to
    user-mode clients capable of creating AFC_NFC sockets.
    
    Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1ac8a98f312da20784723b53c62ad67766d5cb7
Author: Mateusz Jurczyk <mjurczyk@google.com>
Date:   Wed May 24 12:42:26 2017 +0200

    nfc: Ensure presence of required attributes in the activate_target handler
    
    commit a0323b979f81ad2deb2c8836eab506534891876a upstream.
    
    Check that the NFC_ATTR_TARGET_INDEX and NFC_ATTR_PROTOCOLS attributes (in
    addition to NFC_ATTR_DEVICE_INDEX) are provided by the netlink client
    prior to accessing them. This prevents potential unhandled NULL pointer
    dereference exceptions which can be triggered by malicious user-mode
    programs, if they omit one or both of these attributes.
    
    Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06be8e2767da8d2ffeaf490e05cda274935f7f89
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 30 12:15:39 2017 +0200

    NFC: nfcmrvl: fix firmware-management initialisation
    
    commit 45dd39b974f6632222dd5cdcbea7358a077ab0b0 upstream.
    
    The nci-device was never deregistered in the event that
    fw-initialisation failed.
    
    Fix this by moving the firmware initialisation before device
    registration since the firmware work queue should be available before
    registering.
    
    Note that this depends on a recent fix that moved device-name
    initialisation back to to nci_allocate_device() as the
    firmware-workqueue name is now derived from the nfc-device name.
    
    Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
    Cc: Vincent Cuissard <cuissard@marvell.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10f03f0f7ef0ee456369b2940e092e0225c754a6
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 30 12:15:38 2017 +0200

    NFC: nfcmrvl: use nfc-device for firmware download
    
    commit e5834ac22948169bbd7c45996d8d4905edd20f5e upstream.
    
    Use the nfc- rather than phy-device in firmware-management code that
    needs a valid struct device.
    
    This specifically fixes a NULL-pointer dereference in
    nfcmrvl_fw_dnld_init() during registration when the underlying tty is
    one end of a Unix98 pty.
    
    Note that the driver still uses the phy device for any debugging, which
    is fine for now.
    
    Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
    Cc: Vincent Cuissard <cuissard@marvell.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b4f74d6c4f801aee5add0cab1d68904e6141380
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 30 12:15:37 2017 +0200

    NFC: nfcmrvl: do not use device-managed resources
    
    commit 0cbe40112f42cf5e008f9127f6cd5952ba3946c7 upstream.
    
    This specifically fixes resource leaks in the registration error paths.
    
    Device-managed resources is a bad fit for this driver as devices can be
    registered from the n_nci line discipline. Firstly, a tty may not even
    have a corresponding device (should it be part of a Unix98 pty)
    something which would lead to a NULL-pointer dereference when
    registering resources.
    
    Secondly, if the tty has a class device, its lifetime exceeds that of
    the line discipline, which means that resources would leak every time
    the line discipline is closed (or if registration fails).
    
    Currently, the devres interface was only being used to request a reset
    gpio despite the fact that it was already explicitly freed in
    nfcmrvl_nci_unregister_dev() (along with the private data), something
    which also prevented the resource leak at close.
    
    Note that the driver treats gpio number 0 as invalid despite it being
    perfectly valid. This will be addressed in a follow-up patch.
    
    Fixes: b2fe288eac72 ("NFC: nfcmrvl: free reset gpio")
    Fixes: 4a2b947f56b3 ("NFC: nfcmrvl: add chip reset management")
    Cc: Vincent Cuissard <cuissard@marvell.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7de6ff402dd02cbfc6b963068efd6efecc0e4978
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 30 12:15:36 2017 +0200

    NFC: nfcmrvl_uart: add missing tty-device sanity check
    
    commit 15e0c59f1535926a939d1df66d6edcf997d7c1b9 upstream.
    
    Make sure to check the tty-device pointer before trying to access the
    parent device to avoid dereferencing a NULL-pointer when the tty is one
    end of a Unix98 pty.
    
    Fixes: e097dc624f78 ("NFC: nfcmrvl: add UART driver")
    Cc: Vincent Cuissard <cuissard@marvell.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f73de3f9915c997dd091cadcdbafbdb9835f2cf5
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 30 12:15:35 2017 +0200

    NFC: fix broken device allocation
    
    commit 20777bc57c346b6994f465e0d8261a7fbf213a09 upstream.
    
    Commit 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
    moved device-id allocation and struct-device initialisation from
    nfc_allocate_device() to nfc_register_device().
    
    This broke just about every nfc-device-registration error path, which
    continue to call nfc_free_device() that tries to put the device
    reference of the now uninitialised (but zeroed) struct device:
    
    kobject: '(null)' (ce316420): is not initialized, yet kobject_put() is being called.
    
    The late struct-device initialisation also meant that various work
    queues whose names are derived from the nfc device name were also
    misnamed:
    
      421 root         0 SW<  [(null)_nci_cmd_]
      422 root         0 SW<  [(null)_nci_rx_w]
      423 root         0 SW<  [(null)_nci_tx_w]
    
    Move the id-allocation and struct-device initialisation back to
    nfc_allocate_device() and fix up the single call site which did not use
    nfc_free_device() in its error path.
    
    Fixes: 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
    Cc: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48879676a8c3f481e1ae51ccde6d6e7515753476
Author: Miaoqing Pan <miaoqing@codeaurora.org>
Date:   Tue Jun 27 17:31:53 2017 +0300

    ath9k: fix an invalid pointer dereference in ath9k_rng_stop()
    
    commit 07246c115801c27652700e3679bb58661ef7ed65 upstream.
    
    The bug was triggered when do suspend/resuming continuously
    on Dell XPS L322X/0PJHXN version 9333 (2013) with kernel
    4.12.0-041200rc4-generic. But can't reproduce on DELL
    E5440 + AR9300 PCIE chips.
    
    The warning is caused by accessing invalid pointer sc->rng_task.
    sc->rng_task is not be cleared after kthread_stop(sc->rng_task)
    be called in ath9k_rng_stop(). Because the kthread is stopped
    before ath9k_rng_kthread() be scheduled.
    
    So set sc->rng_task to null after kthread_stop(sc->rng_task) to
    resolve this issue.
    
    WARNING: CPU: 0 PID: 984 at linux/kernel/kthread.c:71 kthread_stop+0xf1/0x100
    CPU: 0 PID: 984 Comm: NetworkManager Not tainted 4.12.0-041200rc4-generic #201706042031
    Hardware name: Dell Inc.          Dell System XPS L322X/0PJHXN, BIOS A09 05/15/2013
    task: ffff950170fdda00 task.stack: ffffa22c01538000
    RIP: 0010:kthread_stop+0xf1/0x100
    RSP: 0018:ffffa22c0153b5b0 EFLAGS: 00010246
    RAX: ffffffffa6257800 RBX: ffff950171b79560 RCX: 0000000000000000
    RDX: 0000000080000000 RSI: 000000007fffffff RDI: ffff9500ac9a9680
    RBP: ffffa22c0153b5c8 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffa22c0153b648 R11: ffff9501768004b8 R12: ffff9500ac9a9680
    R13: ffff950171b79f70 R14: ffff950171b78780 R15: ffff9501749dc018
    FS:  00007f0d6bfd5540(0000) GS:ffff95017f200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc190161a08 CR3: 0000000232906000 CR4: 00000000001406f0
    Call Trace:
      ath9k_rng_stop+0x1a/0x20 [ath9k]
      ath9k_stop+0x3b/0x1d0 [ath9k]
      drv_stop+0x33/0xf0 [mac80211]
      ieee80211_stop_device+0x43/0x50 [mac80211]
      ieee80211_do_stop+0x4f2/0x810 [mac80211]
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196043
    Reported-by: Giulio Genovese <giulio.genovese@gmail.com>
    Tested-by: Giulio Genovese <giulio.genovese@gmail.com>
    Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99f96831083bb23dff471ff1b4e16cc8370ecaec
Author: Miaoqing Pan <miaoqing@codeaurora.org>
Date:   Tue Jun 27 17:31:51 2017 +0300

    ath9k: fix tx99 bus error
    
    commit bde717ab473668377fc65872398a102d40cb2d58 upstream.
    
    The hard coded register 0x9864 and 0x9924 are invalid
    for ar9300 chips.
    
    Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b729a1aea14d482e8a29186bd4a930282961a43c
Author: Miaoqing Pan <miaoqing@codeaurora.org>
Date:   Tue Jun 27 17:31:49 2017 +0300

    ath9k: fix tx99 use after free
    
    commit cf8ce1ea61b75712a154c93e40f2a5af2e4dd997 upstream.
    
    One scenario that could lead to UAF is two threads writing
    simultaneously to the "tx99" debug file. One of them would
    set the "start" value to true and follow to ath9k_tx99_init().
    Inside the function it would set the sc->tx99_state to true
    after allocating sc->tx99skb. Then, the other thread would
    execute write_file_tx99() and call ath9k_tx99_deinit().
    sc->tx99_state would be freed. After that, the first thread
    would continue inside ath9k_tx99_init() and call
    r = ath9k_tx99_send(sc, sc->tx99_skb, &txctl);
    that would make use of the freed sc->tx99_skb memory.
    
    Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cd7b56037ae4cbdfe5e7fa9e41b67ba15199d7f
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Tue Apr 25 15:57:08 2017 +0530

    thermal: cpu_cooling: Avoid accessing potentially freed structures
    
    commit 289d72afddf83440117c35d864bf0c6309c1d011 upstream.
    
    After the lock is dropped, it is possible that the cpufreq_dev gets
    freed before we call get_level() and that can cause kernel to crash.
    
    Drop the lock after we are done using the structure.
    
    Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
    Tested-by: Lukasz Luba <lukasz.luba@arm.com>
    Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76572609e45895826f4bf49c376271dc62f125dc
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jun 6 17:59:03 2017 +0200

    thermal: max77620: fix device-node reference imbalance
    
    commit c592fafbdbb6b1279b76a54722d1465ca77e5bde upstream.
    
    The thermal child device reuses the parent MFD-device device-tree node
    when registering a thermal zone, but did not take a reference to the
    node.
    
    This leads to a reference imbalance, and potential use-after-free, when
    the node reference is dropped by the platform-bus device destructor
    (once for the child and later again for the parent).
    
    Fix this by dropping any reference already held to a device-tree node
    and getting a reference to the parent's node which will be balanced on
    reprobe or on platform-device release, whichever comes first.
    
    Note that simply clearing the of_node pointer on probe errors and on
    driver unbind would not allow the use of device-managed resources as
    specifically thermal_zone_of_sensor_unregister() claims that a valid
    device-tree node pointer is needed during deregistration (even if it
    currently does not seem to use it).
    
    Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting junction temp")
    Cc: Laxman Dewangan <ldewangan@nvidia.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60813b6a2ab40c8ad7f5e44819fe6e44fa4b459a
Author: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Date:   Thu May 18 10:40:00 2017 -0300

    s5p-jpeg: don't return a random width/height
    
    commit a16e37726c444cbda91e73ed5f742e717bfe866f upstream.
    
    Gcc 7.1 complains about:
    
    drivers/media/platform/s5p-jpeg/jpeg-core.c: In function 's5p_jpeg_parse_hdr.isra.9':
    drivers/media/platform/s5p-jpeg/jpeg-core.c:1207:12: warning: 'width' may be used uninitialized in this function [-Wmaybe-uninitialized]
      result->w = width;
      ~~~~~~~~~~^~~~~~~
    drivers/media/platform/s5p-jpeg/jpeg-core.c:1208:12: warning: 'height' may be used uninitialized in this function [-Wmaybe-uninitialized]
      result->h = height;
      ~~~~~~~~~~^~~~~~~~
    
    Indeed the code would allow it to return a random value (although
    it shouldn't happen, in practice). So, explicitly set both to zero,
    just in case.
    
    Acked-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63d32e8af0dd6343cde33993eabc9c7562d92fe9
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Fri Jan 6 15:33:14 2017 -0500

    dm mpath: cleanup -Wbool-operation warning in choose_pgpath()
    
    commit d19a55ccad15a486ffe03030570744e5d5bd9f8e upstream.
    
    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70ec6b3635d95983e1fbcfb1c765cd7d2abd0ac8
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu May 11 08:46:44 2017 -0300

    ir-core: fix gcc-7 warning on bool arithmetic
    
    commit bd7e31bbade02bc1e92aa00d5cf2cee2da66838a upstream.
    
    gcc-7 suggests that an expression using a bitwise not and a bitmask
    on a 'bool' variable is better written using boolean logic:
    
    drivers/media/rc/imon.c: In function 'imon_incoming_scancode':
    drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression [-Werror=bool-operation]
        ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
                          ^
    drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not?
    
    I agree.
    
    Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver")
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78fbe21d83e39e74f4b479a2978375ab7aaf3e37
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jul 12 19:25:47 2017 -0700

    disable new gcc-7.1.1 warnings for now
    
    commit bd664f6b3e376a8ef4990f87d08271cc2d01ba9a upstream.
    
    I made the mistake of upgrading my desktop to the new Fedora 26 that
    comes with gcc-7.1.1.
    
    There's nothing wrong per se that I've noticed, but I now have 1500
    lines of warnings, mostly from the new format-truncation warning
    triggering all over the tree.
    
    We use 'snprintf()' and friends in a lot of places, and often know that
    the numbers are fairly small (ie a controller index or similar), but gcc
    doesn't know that, and sees an 'int', and thinks that it could be some
    huge number.  And then complains when our buffers are not able to fit
    the name for the ten millionth controller.
    
    These warnings aren't necessarily bad per se, and we probably want to
    look through them subsystem by subsystem, but at least during the merge
    window they just mean that I can't even see if somebody is introducing
    any *real* problems when I pull.
    
    So warnings disabled for now.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>