commit bb61956d9d9fec64e6619470faafe10dadc43ecb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 16 20:07:01 2018 +0100

    Linux 4.15.4

commit f246c4e6d2862b5c37e6f1fff03cda21f8c7f3fe
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Thu Dec 7 09:40:38 2017 -0800

    rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
    
    commit 156baec39732f025dc778e00da95fc10d6e45885 upstream.
    
    Use of init_rcu_head() and destroy_rcu_head() from modules results in
    the following build-time error with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y:
    
            ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
            ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
    
    This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them to
    be used by GPL-licensed kernel modules.
    
    Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b159566ab29b01de43d912a760a1634b7b694e4
Author: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Date:   Wed Jan 3 16:54:02 2018 -0600

    scsi: cxlflash: Reset command ioasc
    
    commit 96cf727fe8f102bf92150b741db71ee39fb8c521 upstream.
    
    In the event of a command failure, cxlflash returns the failure to the upper
    layers to process. After processing the error, when the command is queued
    again, the private command structure will not be zeroed and the ioasc could be
    stale. Per the SISLite specification, the AFU only sets the ioasc in the
    presence of a failure. Thus, even though the original command succeeds the
    second time, the command is considered a failure due to stale ioasc. This
    cycle repeats indefinitely and can cause a hang or IO failure.
    
    To fix the issue, clear the ioasc before queuing any command.
    
    [mkp: added Cc: stable per request]
    
    Fixes: 479ad8e9d48c ("scsi: cxlflash: Remove zeroing of private command data")
    Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
    Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dbe7be7e522e3387c6d599fcc38aa56c299fcfb
Author: James Smart <jsmart2021@gmail.com>
Date:   Mon Nov 20 16:00:31 2017 -0800

    scsi: lpfc: Fix crash after bad bar setup on driver attachment
    
    commit e4b9794efdce13242f4af6682f3ed48ce3864a87 upstream.
    
    In test cases where an instance of the driver is detached and
    reattached, the driver will crash on reattachment. There is a compound
    if statement that will skip over the bar setup if the pci_resource_start
    call is not successful. The driver erroneously returns success to its
    bar setup in this scenario even though the bars aren't properly
    configured.
    
    Rework the offending code segment for proper initialization steps.  If
    the pci_resource_start call fails, -ENOMEM is now returned.
    
    Sample stack:
    
    rport-5:0-10: blocked FC remote port time out: removing rport
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
    ...
    ...  RIP: 0010:...  ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
     Call Trace:
      ... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc]
      ... ? __alloc_pages_nodemask+0x176/0x420
      ... ? __kmalloc+0x2e/0x230
      ... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc]
      ... ? mempool_alloc+0x69/0x170
      ... ? dma_generic_alloc_coherent+0x8f/0x140
      ... lpfc_sli_issue_mbox+0xf/0x20 [lpfc]
      ... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc]
      ... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc]
      ... lpfc_pci_probe_one+0x445/0x16f0 [lpfc]
      ... local_pci_probe+0x45/0xa0
      ... work_for_cpu_fn+0x14/0x20
      ... process_one_work+0x17a/0x440
    
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <james.smart@broadcom.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3dcf4935d1df95a712760c4db14cb26a91f3f400
Author: Bart Van Assche <bart.vanassche@wdc.com>
Date:   Mon Dec 4 10:06:23 2017 -0800

    scsi: core: Ensure that the SCSI error handler gets woken up
    
    commit 3bd6f43f5cb3714f70c591514f344389df593501 upstream.
    
    If scsi_eh_scmd_add() is called concurrently with
    scsi_host_queue_ready() while shost->host_blocked > 0 then it can
    happen that neither function wakes up the SCSI error handler. Fix
    this by making every function that decreases the host_busy counter
    wake up the error handler if necessary and by protecting the
    host_failed checks with the SCSI host lock.
    
    Reported-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    References: https://marc.info/?l=linux-kernel&m=150461610630736
    Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t")
    Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
    Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
    Cc: Konstantin Khorenko <khorenko@virtuozzo.com>
    Cc: Stuart Hayes <stuart.w.hayes@gmail.com>
    Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: 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 d73763b929449d80f4b60ac2552df282fe412965
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Mon Feb 5 22:05:31 2018 -0500

    ftrace: Remove incorrect setting of glob search field
    
    commit 7b6586562708d2b3a04fe49f217ddbadbbbb0546 upstream.
    
    __unregister_ftrace_function_probe() will incorrectly parse the glob filter
    because it resets the search variable that was setup by filter_parse_regex().
    
    Al Viro reported this:
    
        After that call of filter_parse_regex() we could have func_g.search not
        equal to glob only if glob started with '!' or '*'.  In the former case
        we would've buggered off with -EINVAL (not = 1).  In the latter we
        would've set func_g.search equal to glob + 1, calculated the length of
        that thing in func_g.len and proceeded to reset func_g.search back to
        glob.
    
        Suppose the glob is e.g. *foo*.  We end up with
                func_g.type = MATCH_MIDDLE_ONLY;
                func_g.len = 3;
                func_g.search = "*foo";
        Feeding that to ftrace_match_record() will not do anything sane - we
        will be looking for names containing "*foo" (->len is ignored for that
        one).
    
    Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
    
    Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
    Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d5d5e9612e7af09bb218d0dd2455873b6faca77
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 31 00:49:18 2018 -0800

    devpts: fix error handling in devpts_mntget()
    
    commit c9cc8d01fb04117928830449388512a5047569c9 upstream.
    
    If devpts_ptmx_path() returns an error code, then devpts_mntget()
    dereferences an ERR_PTR():
    
        BUG: unable to handle kernel paging request at fffffffffffffff5
        IP: devpts_mntget+0x13f/0x280 fs/devpts/inode.c:173
    
    Fix it by returning early in the error paths.
    
    Reproducer:
    
        #define _GNU_SOURCE
        #include <fcntl.h>
        #include <sched.h>
        #include <sys/ioctl.h>
        #define TIOCGPTPEER _IO('T', 0x41)
    
        int main()
        {
            for (;;) {
                int fd = open("/dev/ptmx", 0);
                unshare(CLONE_NEWNS);
                ioctl(fd, TIOCGPTPEER, 0);
            }
        }
    
    Fixes: 311fc65c9fb9 ("pty: Repair TIOCGPTPEER")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ec68ce24fd19bebabed20e3812d1befbd4be4d4
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Aug 1 05:02:38 2017 -0500

    mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
    
    commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.
    
    Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
    not correct.  With si_code set to SI_USER si_pid and si_uid will be copied to
    userspace instead of si_addr.  Which is very wrong.
    
    So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
    
    Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
    Cc: David Howells <dhowells@redhat.com>
    Cc: Masakazu Urade <urade.masakazu@jp.panasonic.com>
    Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2433367ce69eb80c90c0a7776f0292081ac8cf2a
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Sun Jan 14 18:35:40 2018 +0200

    ovl: hash directory inodes for fsnotify
    
    commit 31747eda41ef3c30c09c5c096b380bf54013746a upstream.
    
    fsnotify pins a watched directory inode in cache, but if directory dentry
    is released, new lookup will allocate a new dentry and a new inode.
    Directory events will be notified on the new inode, while fsnotify listener
    is watching the old pinned inode.
    
    Hash all directory inodes to reuse the pinned inode on lookup. Pure upper
    dirs are hashes by real upper inode, merge and lower dirs are hashed by
    real lower inode.
    
    The reference to lower inode was being held by the lower dentry object
    in the overlay dentry (oe->lowerstack[0]). Releasing the overlay dentry
    may drop lower inode refcount to zero. Add a refcount on behalf of the
    overlay inode to prevent that.
    
    As a by-product, hashing directory inodes also detects multiple
    redirected dirs to the same lower dir and uncovered redirected dir
    target on and returns -ESTALE on lookup.
    
    The reported issue dates back to initial version of overlayfs, but this
    patch depends on ovl_inode code that was introduced in kernel v4.13.
    
    Reported-by: Niklas Cassel <niklas.cassel@axis.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Tested-by: Niklas Cassel <niklas.cassel@axis.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06b4cf20d166fcd17e5d4a9da24861a61bf62689
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Jan 3 18:54:42 2018 +0200

    ovl: take mnt_want_write() for removing impure xattr
    
    commit a5a927a7c82e28ea76599dee4019c41e372c911f upstream.
    
    The optimization in ovl_cache_get_impure() that tries to remove an
    unneeded "impure" xattr needs to take mnt_want_write() on upper fs.
    
    Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs")
    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 65989bff55e8f2dae2b1ab4b13edbaabe9868da7
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Jan 3 18:54:41 2018 +0200

    ovl: take mnt_want_write() for work/index dir setup
    
    commit 2ba9d57e65044859f7ff133bcb0a902769bf3bc6 upstream.
    
    There are several write operations on upper fs not covered by
    mnt_want_write():
    
    - test set/remove OPAQUE xattr
    - test create O_TMPFILE
    - set ORIGIN xattr in ovl_verify_origin()
    - cleanup of index entries in ovl_indexdir_cleanup()
    
    Some of these go way back, but this patch only applies over the
    v4.14 re-factoring of ovl_fill_super().
    
    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 fc103afa339095bce84fe46e6224a631206f0f86
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Nov 8 09:39:46 2017 +0200

    ovl: fix failure to fsync lower dir
    
    commit d796e77f1dd541fe34481af2eee6454688d13982 upstream.
    
    As a writable mount, it is not expected for overlayfs to return
    EINVAL/EROFS for fsync, even if dir/file is not changed.
    
    This commit fixes the case of fsync of directory, which is easier to
    address, because overlayfs already implements fsync file operation for
    directories.
    
    The problem reported by Raphael is that new PostgreSQL 10.0 with a
    database in overlayfs where lower layer in squashfs fails to start.
    The failure is due to fsync error, when PostgreSQL does fsync on all
    existing db directories on startup and a specific directory exists
    lower layer with no changes.
    
    Reported-by: Raphael Hertzog <raphael@ouaza.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Tested-by: Raphaël Hertzog <hertzog@debian.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e14a5067b13c8d28b138ded9d89c4fd3a79637bd
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Tue Sep 19 12:14:18 2017 +0300

    ovl: force r/o mount when index dir creation fails
    
    commit 972d0093c2f7b1bd57e47a1780a552dde528fd16 upstream.
    
    When work dir creation fails, a warning is emitted and overlay is
    mounted r/o. Trying to remount r/w will fail with no work dir.
    
    When index dir creation fails, the same warning is emitted and overlay
    is mounted r/o, but trying to remount r/w will succeed. This may cause
    unintentional corruption of filesystem consistency.
    
    Adjust the behavior of index dir creation failure to that of work dir
    creation failure and do not allow to remount r/w. User needs to state
    an explicitly intention to work without an index by mounting with
    option 'index=off' to allow r/w mount with no index dir.
    
    When mounting with option 'index=on' and no 'upperdir', index is
    implicitly disabled, so do not warn about no file handle support.
    
    The issue was introduced with inodes index feature in v4.13, but this
    patch will not apply cleanly before ovl_fill_super() re-factoring in
    v4.15.
    
    Fixes: 02bcd1577400 ("ovl: introduce the inodes index dir feature")
    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 74ef3034525acd9330be48b57df74c67f92ede3a
Author: Toshi Kani <toshi.kani@hpe.com>
Date:   Fri Feb 2 14:00:36 2018 -0700

    acpi, nfit: fix register dimm error handling
    
    commit 23fbd7c70aec7600e3227eb24259fc55bf6e4881 upstream.
    
    A NULL pointer reference kernel bug was observed when
    acpi_nfit_add_dimm() called in acpi_nfit_register_dimms() failed. This
    error path does not set nfit_mem->nvdimm, but the 2nd
    list_for_each_entry() loop in the function assumes it's always set. Add
    a check to nfit_mem->nvdimm.
    
    Fixes: ba9c8dd3c222 ("acpi, nfit: add dimm device notification support")
    Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a9b65ce31654f5d4edd134c5ad21a0b0846ab1a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jan 19 10:06:03 2018 +0100

    ACPI: sbshc: remove raw pointer from printk() message
    
    commit 43cdd1b716b26f6af16da4e145b6578f98798bf6 upstream.
    
    There's no need to be printing a raw kernel pointer to the kernel log at
    every boot.  So just remove it, and change the whole message to use the
    correct dev_info() call at the same time.
    
    Reported-by: Wang Qize <wang_qize@venustech.com.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a18ff97b8fff2c87c50f567749d9e7bb9349b3fa
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Nov 29 19:51:37 2017 +0200

    drm/i915: Avoid PPS HW/SW state mismatch due to rounding
    
    commit 5643205c6340b565a3be0fe0e7305dc4aa551c74 upstream.
    
    We store a SW state of the t11_t12 timing in 100usec units but have to
    program it in 100msec as required by HW. The rounding used during
    programming means there will be a mismatch between the SW and HW states
    of this value triggering a "PPS state mismatch" error. Avoid this by
    storing the already rounded-up value in the SW state.
    
    Note that we still calculate panel_power_cycle_delay with the finer
    100usec granularity to avoid any needless waits using that version of
    the delay.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
    Cc: joks <joks@linux.pl>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171129175137.2889-1-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7217671ff5ad0ff2e147ebd890ee5625e0c7ff9d
Author: Yan Markman <ymarkman@marvell.com>
Date:   Wed Jan 3 16:18:52 2018 +0100

    arm64: dts: marvell: add Ethernet aliases
    
    commit 474c5885582c4a79c21bcf01ed98f98c935f1f4a upstream.
    
    This patch adds Ethernet aliases in the Marvell Armada 7040 DB, 8040 DB
    and 8040 mcbin device trees so that the bootloader setup the MAC
    addresses correctly.
    
    Signed-off-by: Yan Markman <ymarkman@marvell.com>
    [Antoine: commit message, small fixes]
    Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8217faccb47e736a2f151abd9e200d0b90e1f31
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Feb 8 14:02:32 2018 +0100

    objtool: Fix switch-table detection
    
    commit 99ce7962d52d1948ad6f2785e308d48e76e0a6ef upstream.
    
    Linus reported that GCC-7.3 generated a switch-table construct that
    confused objtool. It turns out that, in particular due to KASAN, it is
    possible to have unrelated .rodata usage in between the .rodata setup
    for the switch-table and the following indirect jump.
    
    The simple linear reverse search from the indirect jump would hit upon
    the KASAN .rodata usage first and fail to find a switch_table,
    resulting in a spurious 'sibling call with modified stack frame'
    warning.
    
    Fix this by creating a 'jump-stack' which we can 'unwind' during
    reversal, thereby skipping over much of the in-between code.
    
    This is not fool proof by any means, but is sufficient to make the
    known cases work. Future work would be to construct more comprehensive
    flow analysis code.
    
    Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20180208130232.GF25235@hirez.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1396715adadb48ab24abcc004d193bfc873f39c7
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Tue Feb 6 15:40:42 2018 -0800

    lib/ubsan: add type mismatch handler for new GCC/Clang
    
    commit 42440c1f9911b4b7b8ba3dc4e90c1197bc561211 upstream.
    
    UBSAN=y fails to build with new GCC/clang:
    
        arch/x86/kernel/head64.o: In function `sanitize_boot_params':
        arch/x86/include/asm/bootparam_utils.h:37: undefined reference to `__ubsan_handle_type_mismatch_v1'
    
    because Clang and GCC 8 slightly changed ABI for 'type mismatch' errors.
    Compiler now uses new __ubsan_handle_type_mismatch_v1() function with
    slightly modified 'struct type_mismatch_data'.
    
    Let's add new 'struct type_mismatch_data_common' which is independent from
    compiler's layout of 'struct type_mismatch_data'.  And make
    __ubsan_handle_type_mismatch[_v1]() functions transform compiler-dependent
    type mismatch data to our internal representation.  This way, we can
    support both old and new compilers with minimal amount of change.
    
    Link: http://lkml.kernel.org/r/20180119152853.16806-1-aryabinin@virtuozzo.com
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Reported-by: Sodagudi Prasad <psodagud@codeaurora.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 157bb32f826c31263f22a0b35366c136affde6f0
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Tue Feb 6 15:40:38 2018 -0800

    lib/ubsan.c: s/missaligned/misaligned/
    
    commit b8fe1120b4ba342b4f156d24e952d6e686b20298 upstream.
    
    A vist from the spelling fairy.
    
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a8ca66b3b26b6912aafeeb971a7b5645f02e43e
Author: Daniel Lezcano <daniel.lezcano@linaro.org>
Date:   Mon Jan 8 14:28:50 2018 +0100

    clocksource/drivers/stm32: Fix kernel panic with multiple timers
    
    commit e0aeca3d8cbaea514eb98df1149faa918f9ec42d upstream.
    
    The current code hides a couple of bugs:
    
     - The global variable 'clock_event_ddata' is overwritten each time the
       init function is invoked.
    
    This is fixed with a kmemdup() instead of assigning the global variable. That
    prevents a memory corruption when several timers are defined in the DT.
    
     - The clockevent's event_handler is NULL if the time framework does
       not select the clockevent when registering it, this is fine but the init
       code generates in any case an interrupt leading to dereference this
       NULL pointer.
    
    The stm32 timer works with shadow registers, a mechanism to cache the
    registers. When a change is done in one buffered register, we need to
    artificially generate an event to force the timer to copy the content
    of the register to the shadowed register.
    
    The auto-reload register (ARR) is one of the shadowed register as well as
    the prescaler register (PSC), so in order to force the copy, we issue an
    event which in turn leads to an interrupt and the NULL dereference.
    
    This is fixed by inverting two lines where we clear the status register
    before enabling the update event interrupt.
    
    As this kernel crash is resulting from the combination of these two bugs,
    the fixes are grouped into a single patch.
    
    Tested-by: Benjamin Gaignard <benjamin.gaignard@st.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Acked-by: Benjamin Gaignard <benjamin.gaignard@st.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1515418139-23276-11-git-send-email-daniel.lezcano@linaro.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83cfeb15b960644979697719edad2a800ff7dddf
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Jan 6 16:27:37 2018 +0800

    blk-mq: quiesce queue before freeing queue
    
    commit c2856ae2f315d754a0b6a268e4c6745b332b42e7 upstream.
    
    After queue is frozen, dispatch still may happen, for example:
    
    1) requests are submitted from several contexts
    2) requests from all these contexts are inserted to queue, but may dispatch
    to LLD in one of these paths, but other paths sill need to move on even all
    these requests are completed(that means blk_mq_freeze_queue_wait() returns
    at that time)
    3) dispatch after queue freezing still moves on and causes use-after-free,
    because request queue is freed
    
    This patch quiesces queue after it is frozen, and makes sure all
    in-progress dispatch are completed.
    
    This patch fixes the following kernel crash when running heavy IOs vs.
    deleting device:
    
    [   36.719251] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
    [   36.720318] IP: kyber_has_work+0x14/0x40
    [   36.720847] PGD 254bf5067 P4D 254bf5067 PUD 255e6a067 PMD 0
    [   36.721584] Oops: 0000 [#1] PREEMPT SMP
    [   36.722105] Dumping ftrace buffer:
    [   36.722570]    (ftrace buffer empty)
    [   36.723057] Modules linked in: scsi_debug ebtable_filter ebtables ip6table_filter ip6_tables tcm_loop iscsi_target_mod target_core_file target_core_iblock target_core_pscsi target_core_mod xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c bridge stp llc fuse iptable_filter ip_tables sd_mod sg btrfs xor zstd_decompress zstd_compress xxhash raid6_pq mptsas mptscsih bcache crc32c_intel ahci mptbase libahci serio_raw scsi_transport_sas nvme libata shpchp lpc_ich virtio_scsi nvme_core binfmt_misc dm_mod iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi null_blk configs
    [   36.733438] CPU: 2 PID: 2374 Comm: fio Not tainted 4.15.0-rc2.blk_mq_quiesce+ #714
    [   36.735143] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.9.3-1.fc25 04/01/2014
    [   36.736688] RIP: 0010:kyber_has_work+0x14/0x40
    [   36.737515] RSP: 0018:ffffc9000209bca0 EFLAGS: 00010202
    [   36.738431] RAX: 0000000000000008 RBX: ffff88025578bfc8 RCX: ffff880257bf4ed0
    [   36.739581] RDX: 0000000000000038 RSI: ffffffff81a98c6d RDI: ffff88025578bfc8
    [   36.740730] RBP: ffff880253cebfc8 R08: ffffc9000209bda0 R09: ffff8802554f3480
    [   36.741885] R10: ffffc9000209be60 R11: ffff880263f72538 R12: ffff88025573e9e8
    [   36.743036] R13: ffff88025578bfd0 R14: 0000000000000001 R15: 0000000000000000
    [   36.744189] FS:  00007f9b9bee67c0(0000) GS:ffff88027fc80000(0000) knlGS:0000000000000000
    [   36.746617] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   36.748483] CR2: 0000000000000008 CR3: 0000000254bf4001 CR4: 00000000003606e0
    [   36.750164] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   36.751455] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   36.752796] Call Trace:
    [   36.753992]  blk_mq_do_dispatch_sched+0x7f/0xe0
    [   36.755110]  blk_mq_sched_dispatch_requests+0x119/0x190
    [   36.756179]  __blk_mq_run_hw_queue+0x83/0x90
    [   36.757144]  __blk_mq_delay_run_hw_queue+0xaf/0x110
    [   36.758046]  blk_mq_run_hw_queue+0x24/0x70
    [   36.758845]  blk_mq_flush_plug_list+0x1e7/0x270
    [   36.759676]  blk_flush_plug_list+0xd6/0x240
    [   36.760463]  blk_finish_plug+0x27/0x40
    [   36.761195]  do_io_submit+0x19b/0x780
    [   36.761921]  ? entry_SYSCALL_64_fastpath+0x1a/0x7d
    [   36.762788]  entry_SYSCALL_64_fastpath+0x1a/0x7d
    [   36.763639] RIP: 0033:0x7f9b9699f697
    [   36.764352] RSP: 002b:00007ffc10f991b8 EFLAGS: 00000206 ORIG_RAX: 00000000000000d1
    [   36.765773] RAX: ffffffffffffffda RBX: 00000000008f6f00 RCX: 00007f9b9699f697
    [   36.766965] RDX: 0000000000a5e6c0 RSI: 0000000000000001 RDI: 00007f9b8462a000
    [   36.768377] RBP: 0000000000000000 R08: 0000000000000001 R09: 00000000008f6420
    [   36.769649] R10: 00007f9b846e5000 R11: 0000000000000206 R12: 00007f9b795d6a70
    [   36.770807] R13: 00007f9b795e4140 R14: 00007f9b795e3fe0 R15: 0000000100000000
    [   36.771955] Code: 83 c7 10 e9 3f 68 d1 ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 97 b0 00 00 00 48 8d 42 08 48 83 c2 38 <48> 3b 00 74 06 b8 01 00 00 00 c3 48 3b 40 08 75 f4 48 83 c0 10
    [   36.775004] RIP: kyber_has_work+0x14/0x40 RSP: ffffc9000209bca0
    [   36.776012] CR2: 0000000000000008
    [   36.776690] ---[ end trace 4045cbce364ff2a4 ]---
    [   36.777527] Kernel panic - not syncing: Fatal exception
    [   36.778526] Dumping ftrace buffer:
    [   36.779313]    (ftrace buffer empty)
    [   36.780081] Kernel Offset: disabled
    [   36.780877] ---[ end Kernel panic - not syncing: Fatal exception
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3e1e2d54d4f48a2e301a87ad6b757bfbb4b3824
Author: Bart Van Assche <bart.vanassche@wdc.com>
Date:   Tue Jan 2 11:39:48 2018 -0800

    pktcdvd: Fix a recently introduced NULL pointer dereference
    
    commit 882d4171a8950646413b1a3cbe0e4a6a612fe82e upstream.
    
    Call bdev_get_queue(bdev) after bdev->bd_disk has been initialized
    instead of just before that pointer has been initialized. This patch
    avoids that the following command
    
    pktsetup 1 /dev/sr0
    
    triggers the following kernel crash:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000548
    IP: pkt_setup_dev+0x2db/0x670 [pktcdvd]
    CPU: 2 PID: 724 Comm: pktsetup Not tainted 4.15.0-rc4-dbg+ #1
    Call Trace:
     pkt_ctl_ioctl+0xce/0x1c0 [pktcdvd]
     do_vfs_ioctl+0x8e/0x670
     SyS_ioctl+0x3c/0x70
     entry_SYSCALL_64_fastpath+0x23/0x9a
    
    Reported-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Fixes: commit ca18d6f769d2 ("block: Make most scsi_req_init() calls implicit")
    Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
    Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a6938e21159bc13767d2d009811dac3920e5b36
Author: Bart Van Assche <bart.vanassche@wdc.com>
Date:   Tue Jan 2 11:39:47 2018 -0800

    pktcdvd: Fix pkt_setup_dev() error path
    
    commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.
    
    Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
    modified add_disk() and disk_release() but did not update any of the
    error paths that trigger a put_disk() call after disk->queue has been
    assigned. That introduced the following behavior in the pktcdvd driver
    if pkt_new_dev() fails:
    
    Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]
    
    Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
    fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
    error path.
    
    Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
    Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4d9ac623f3c68b32e8d9eb68013a82bfd9178ec
Author: Peter Rosin <peda@axentia.se>
Date:   Wed Jan 17 14:34:23 2018 +0100

    pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping
    
    commit b930151e5b55a0e62a3aad06876de891ac980471 upstream.
    
    Without such a range, gpiolib fails with -EPROBE_DEFER, pending the
    addition of the range. So, without a range, gpiolib will keep
    deferring indefinitely.
    
    Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
    Fixes: e10f72bf4b3e ("gpio: gpiolib: Generalise state persistence beyond sleep")
    Suggested-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12cbc6636acf34f3a4c7be14030acc98ce5be5bd
Author: Peter Rosin <peda@axentia.se>
Date:   Wed Jan 17 14:34:22 2018 +0100

    pinctrl: sx150x: Register pinctrl before adding the gpiochip
    
    commit 1a1d39e1b8dd1d0f92a79da4fcc1ab0be3ae9bfc upstream.
    
    Various gpiolib activity depend on the pinctrl to be up and kicking.
    Therefore, register the pinctrl before adding a gpiochip.
    
    Suggested-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c56a74735860891522ea15c3802104681fd4dd3a
Author: Peter Rosin <peda@axentia.se>
Date:   Wed Jan 17 14:34:21 2018 +0100

    pinctrl: sx150x: Unregister the pinctrl on release
    
    commit 0657cb50b5a75abd92956028727dc255d690a4a6 upstream.
    
    There is no matching call to pinctrl_unregister, so switch to the
    managed devm_pinctrl_register to clean up properly when done.
    
    Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
    Signed-off-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 178e4288c0144fe662f6ac7bfa7ffb69191ddf31
Author: Dmitry Mastykin <mastichi@gmail.com>
Date:   Thu Dec 28 18:19:24 2017 +0300

    pinctrl: mcp23s08: fix irq setup order
    
    commit 02e389e63e3523828fc3832f27e0341885f60f6f upstream.
    
    When using mcp23s08 module with gpio-keys, often (50% of boots)
    it fails to get irq numbers with message:
    "gpio-keys keys: Unable to get irq number for GPIO 0, error -6".
    Seems that irqs must be setup before devm_gpiochip_add_data().
    
    Signed-off-by: Dmitry Mastykin <mastichi@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25484773c7a9eb04f0636232ac1a4a5c3b5e32ad
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Wed Nov 29 16:25:44 2017 +0300

    pinctrl: intel: Initialize GPIO properly when used through irqchip
    
    commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 upstream.
    
    When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
    switches the pin to GPIO mode and makes sure interrupts are routed to
    the GPIO hardware instead of IOAPIC. However, if the GPIO is used
    directly through irqchip, as is the case with many I2C-HID devices where
    I2C core automatically configures interrupt for the device, the pin is
    not initialized as GPIO. Instead we rely that the BIOS configures the
    pin accordingly which seems not to be the case at least in Asus X540NA
    SKU3 with Focaltech touchpad.
    
    When the pin is not properly configured it might result weird behaviour
    like interrupts suddenly stop firing completely and the touchpad stops
    responding to user input.
    
    Fix this by properly initializing the pin to GPIO mode also when it is
    used directly through irqchip.
    
    Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
    Reported-by: Daniel Drake <drake@endlessm.com>
    Reported-and-tested-by: Chris Chiu <chiu@endlessm.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7872298948968b9977602f2391faba4a72502d93
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jan 30 19:36:32 2018 +0100

    genirq: Make legacy autoprobing work again
    
    commit 1beaeacdc88b537703d04d5536235d0bbb36db93 upstream.
    
    Meelis reported the following warning on a quad P3 HP NetServer museum piece:
    
    WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100
    EIP: __irq_startup+0x80/0x100
    irq_startup+0x7e/0x170
    probe_irq_on+0x128/0x2b0
    parport_irq_probe.constprop.18+0x8d/0x1af [parport_pc]
    parport_pc_probe_port+0xf11/0x1260 [parport_pc]
    parport_pc_init+0x78a/0xf10 [parport_pc]
    parport_parse_param.constprop.16+0xf0/0xf0 [parport_pc]
    do_one_initcall+0x45/0x1e0
    
    This is caused by the rewrite of the irq activation/startup sequence which
    missed to convert a callsite in the irq legacy auto probing code.
    
    To fix this irq_activate_and_startup() needs to gain a return value so the
    pending logic can work proper.
    
    Fixes: c942cee46bba ("genirq: Separate activation and startup")
    Reported-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Meelis Roos <mroos@linux.ee>
    Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801301935410.1797@nanos
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 141fce350f00d4df5494e901d379ce9f52ab0e2d
Author: James Hogan <jhogan@kernel.org>
Date:   Mon Nov 13 16:12:06 2017 +0000

    EDAC, octeon: Fix an uninitialized variable warning
    
    commit 544e92581a2ac44607d7cc602c6b54d18656f56d upstream.
    
    Fix an uninitialized variable warning in the Octeon EDAC driver, as seen
    in MIPS cavium_octeon_defconfig builds since v4.14 with Codescape GNU
    Tools 2016.05-03:
    
      drivers/edac/octeon_edac-lmc.c In function ‘octeon_lmc_edac_poll_o2’:
      drivers/edac/octeon_edac-lmc.c:87:24: warning: ‘((long unsigned int*)&int_reg)[1]’ may \
        be used uninitialized in this function [-Wmaybe-uninitialized]
        if (int_reg.s.sec_err || int_reg.s.ded_err) {
                            ^
    Iinitialise the whole int_reg variable to zero before the conditional
    assignments in the error injection case.
    
    Signed-off-by: James Hogan <jhogan@kernel.org>
    Acked-by: David Daney <david.daney@cavium.com>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Cc: linux-mips@linux-mips.org
    Fixes: 1bc021e81565 ("EDAC: Octeon: Add error injection support")
    Link: http://lkml.kernel.org/r/20171113161206.20990-1-james.hogan@mips.com
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36ea5adbf38ebf454280eba7a305d142657b018f
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Fri Jan 5 14:27:58 2018 -0800

    xtensa: fix futex_atomic_cmpxchg_inatomic
    
    commit ca47480921587ae30417dd234a9f79af188e3666 upstream.
    
    Return 0 if the operation was successful, not the userspace memory
    value. Check that userspace value equals passed oldval, not itself.
    Don't update *uval if the value wasn't read from userspace memory.
    
    This fixes process hang due to infinite loop in futex_lock_pi.
    It also fixes a bunch of glibc tests nptl/tst-mutexpi*.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa38e58d15abed5f077507dcec36c6193d2ee14a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jan 2 14:00:32 2018 -0500

    alpha: fix formating of stack content
    
    commit 4b01abdb32fc36abe877503bfbd33019159fad71 upstream.
    
    Since version 4.9, the kernel automatically breaks printk calls into
    multiple newlines unless pr_cont is used. Fix the alpha stacktrace code,
    so that it prints stack trace in four columns, as it was initially
    intended.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa117ce7d303bcb1367bd894ec5a3280bafd81e5
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jan 2 13:59:54 2018 -0500

    alpha: fix reboot on Avanti platform
    
    commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream.
    
    We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get
    machine check exception when attempting to reboot the machine.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bbebfe82495f4a197070c54265d9184e14cd479
Author: Michael Cree <mcree@orcon.net.nz>
Date:   Fri Nov 24 21:25:01 2017 +1300

    alpha: Fix mixed up args in EXC macro in futex operations
    
    commit 84e455361ec97ea6037d31d42a2955628ea2094b upstream.
    
    Fix the typo (mixed up arguments) in the EXC macro in the futex
    definitions introduced by commit ca282f697381 (alpha: add a
    helper for emitting exception table entries).
    
    Signed-off-by: Michael Cree <mcree@orcon.net.nz>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3135742ca71c0e4164e4b2e0dc0d86bbfdde9aa
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 8 16:02:13 2017 +0100

    alpha: osf_sys.c: fix put_tv32 regression
    
    commit 47669fb6b5951d0e09fc99719653e0ac92b50b99 upstream.
    
    There was a typo in the new version of put_tv32() that caused an unguarded
    access of a user space pointer, and failed to return the correct result in
    gettimeofday(), wait4(), usleep_thread() and old_adjtimex().
    
    This fixes it to give the correct behavior again.
    
    Fixes: 1cc6c4635e9f ("osf_sys.c: switch handling of timeval32/itimerval32 to copy_{to,from}_user()")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 190d1ab5450cc9967120926cc489dfe4d7ae9d98
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jan 2 14:01:34 2018 -0500

    alpha: fix crash if pthread_create races with signal delivery
    
    commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream.
    
    On alpha, a process will crash if it attempts to start a thread and a
    signal is delivered at the same time. The crash can be reproduced with
    this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
    
    The reason for the crash is this:
    * we call the clone syscall
    * we go to the function copy_process
    * copy process calls copy_thread_tls, it is a wrapper around copy_thread
    * copy_thread sets the tls pointer: childti->pcb.unique = regs->r20
    * copy_thread sets regs->r20 to zero
    * we go back to copy_process
    * copy process checks "if (signal_pending(current))" and returns
      -ERESTARTNOINTR
    * the clone syscall is restarted, but this time, regs->r20 is zero, so
      the new thread is created with zero tls pointer
    * the new thread crashes in start_thread when attempting to access tls
    
    The comment in the code says that setting the register r20 is some
    compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so
    we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug
    by zeroing regs->r20 only if CLONE_SETTLS is not set.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24faada95fbe2992aa56c7930c50a6f80d65cdb3
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Jul 24 17:30:30 2017 -0500

    signal/sh: Ensure si_signo is initialized in do_divide_error
    
    commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream.
    
    Set si_signo.
    
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: linux-sh@vger.kernel.org
    Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cce3b22f14dd4afcd7863af4dec07b1a2b6cdd99
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Aug 1 04:16:47 2017 -0500

    signal/openrisc: Fix do_unaligned_access to send the proper signal
    
    commit 500d58300571b6602341b041f97c082a461ef994 upstream.
    
    While reviewing the signal sending on openrisc the do_unaligned_access
    function stood out because it is obviously wrong.  A comment about an
    si_code set above when actually si_code is never set.  Leading to a
    random si_code being sent to userspace in the event of an unaligned
    access.
    
    Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
    si_code to send for an unaligned access. That is what other
    architectures do and what is required by posix.
    
    Given that do_unaligned_access is broken in a way that no one can be
    relying on it on openrisc fix the code to just do the right thing.
    
    Fixes: 769a8a96229e ("OpenRISC: Traps")
    Cc: Jonas Bonn <jonas@southpole.se>
    Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
    Cc: Stafford Horne <shorne@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: openrisc@lists.librecores.org
    Acked-by: Stafford Horne <shorne@gmail.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4574b506d634d1a006f79eb7e621cbe75c6375a2
Author: John Garry <john.garry@huawei.com>
Date:   Thu Jan 18 00:36:57 2018 +0800

    ipmi: use dynamic memory for DMI driver override
    
    commit 5516e21a1e95e9b9f39985598431a25477d91643 upstream.
    
    Currently a crash can be seen if we reach the "err"
    label in dmi_add_platform_ipmi(), calling
    platform_device_put(), like here:
    [    7.270584]  (null): ipmi:dmi: Unable to add resources: -16
    [    7.330229] ------------[ cut here ]------------
    [    7.334889] kernel BUG at mm/slub.c:3894!
    [    7.338936] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [    7.344475] Modules linked in:
    [    7.347556] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00004-gbe9cb7b-dirty #114
    [    7.355907] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 11/29/2017
    [    7.365137] task: 00000000c211f6d3 task.stack: 00000000f276e9af
    [    7.371116] pstate: 60000005 (nZCv daif -PAN -UAO)
    [    7.375957] pc : kfree+0x194/0x1b4
    [    7.379389] lr : platform_device_release+0xcc/0xd8
    [    7.384225] sp : ffff0000092dba90
    [    7.387567] x29: ffff0000092dba90 x28: ffff000008a83000
    [    7.392933] x27: ffff0000092dbc10 x26: 00000000000000e6
    [    7.398297] x25: 0000000000000003 x24: ffff0000085b51e8
    [    7.403662] x23: 0000000000000100 x22: ffff7e0000234cc0
    [    7.409027] x21: ffff000008af3660 x20: ffff8017d21acc10
    [    7.414392] x19: ffff8017d21acc00 x18: 0000000000000002
    [    7.419757] x17: 0000000000000001 x16: 0000000000000008
    [    7.425121] x15: 0000000000000001 x14: 6666666678303d65
    [    7.430486] x13: 6469727265766f5f x12: 7265766972642e76
    [    7.435850] x11: 6564703e2d617020 x10: 6530326435373638
    [    7.441215] x9 : 3030303030303030 x8 : 3d76656420657361
    [    7.446580] x7 : ffff000008f59df8 x6 : ffff8017fbe0ea50
    [    7.451945] x5 : 0000000000000000 x4 : 0000000000000000
    [    7.457309] x3 : ffffffffffffffff x2 : 0000000000000000
    [    7.462674] x1 : 0fffc00000000800 x0 : ffff7e0000234ce0
    [    7.468039] Process swapper/0 (pid: 1, stack limit = 0x00000000f276e9af)
    [    7.474809] Call trace:
    [    7.477272]  kfree+0x194/0x1b4
    [    7.480351]  platform_device_release+0xcc/0xd8
    [    7.484837]  device_release+0x34/0x90
    [    7.488531]  kobject_put+0x70/0xcc
    [    7.491961]  put_device+0x14/0x1c
    [    7.495304]  platform_device_put+0x14/0x1c
    [    7.499439]  dmi_add_platform_ipmi+0x348/0x3ac
    [    7.503923]  scan_for_dmi_ipmi+0xfc/0x10c
    [    7.507970]  do_one_initcall+0x38/0x124
    [    7.511840]  kernel_init_freeable+0x188/0x228
    [    7.516238]  kernel_init+0x10/0x100
    [    7.519756]  ret_from_fork+0x10/0x18
    [    7.523362] Code: f94002c0 37780080 f94012c0 37000040 (d4210000)
    [    7.529552] ---[ end trace 11750e4787deef9e ]---
    [    7.534228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
    [    7.534228]
    
    This is because when the device is released in
    platform_device_release(), we try to free
    pdev.driver_override. This is a const string, hence
    the crash.
    Fix by using dynamic memory for pdev->driver_override.
    
    Signed-off-by: John Garry <john.garry@huawei.com>
    [Removed the free of driver_override from ipmi_si_remove_by_dev().  The
     free is done in platform_device_release(), and would result in a double
     free, and ipmi_si_remove_by_dev() is called by non-platform devices.]
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 457ad223c59d939bbca7c7202912a910e5dcf860
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Jan 8 10:44:16 2018 +0100

    Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
    
    commit 61f5acea8737d9b717fcc22bb6679924f3c82b98 upstream.
    
    Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
    removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
    instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
    
    This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
    has several issues (see the original commit message). An added advantage
    of moving over to the USB-core reset-resume handling is that it also
    disables autosuspend for these devices, which is similarly broken on these.
    
    But there are 2 issues with this approach:
    1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek
       devices.
    2) Sofar only 2 of the 10 QCA devices known to the btusb code have been
       added to usb/core/quirks.c and if we fix the Realtek case the same way
       we need to add an additional 14 entries. So in essence we need to
       duplicate a large part of the usb_device_id table in btusb.c in
       usb/core/quirks.c and manually keep them in sync.
    
    This commit instead restores setting a reset-resume quirk for QCA devices
    in the btusb.c code, avoiding the duplicate usb_device_id table problem.
    
    This commit avoids the problems with the original DIY BTUSB_RESET_RESUME
    code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the
    usb_device.
    
    This commit also moves the BTUSB_REALTEK case over to directly setting the
    USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused
    BTUSB_RESET_RESUME code.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
    Fixes: 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
    Cc: Leif Liddy <leif.linux@gmail.com>
    Cc: Matthias Kaehlcke <mka@chromium.org>
    Cc: Brian Norris <briannorris@chromium.org>
    Cc: Daniel Drake <drake@endlessm.com>
    Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ac3d11aba75b5e3d7bef1f4d0cb912971bdf6af
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Wed Dec 20 19:00:07 2017 +0800

    Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
    
    commit 7d06d5895c159f64c46560dc258e553ad8670fe0 upstream.
    
    This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56.
    
    This commit causes a regression on some QCA ROME chips. The USB device
    reset happens in btusb_open(), hence firmware loading gets interrupted.
    
    Furthermore, this commit stops working after commit
    ("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to
    enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in
    btusb_suspend() when it's not a wakeup source.
    
    If we really want to reset the USB device, we need to do it before
    btusb_open(). Let's handle it in drivers/usb/core/quirks.c.
    
    Cc: Leif Liddy <leif.linux@gmail.com>
    Cc: Matthias Kaehlcke <mka@chromium.org>
    Cc: Brian Norris <briannorris@chromium.org>
    Cc: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reviewed-by: Brian Norris <briannorris@chromium.org>
    Tested-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea0c164b58950e00cb465d39e6d42120e975bd06
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Nov 29 20:29:07 2017 +0100

    Bluetooth: btsdio: Do not bind to non-removable BCM43341
    
    commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 upstream.
    
    BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
    use an UART connection for bluetooth. But they also advertise btsdio
    support on their 3th sdio function, this causes 2 problems:
    
    1) A non functioning BT HCI getting registered
    
    2) Since the btsdio driver does not have suspend/resume callbacks,
    mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
    to react as if the SDIO-card is removed and since the slot is
    marked as non-removable it will never get detected as inserted again.
    Which results in wifi no longer working after a suspend/resume.
    
    This commit fixes both by making btsdio ignore BCM43341 devices
    when connected to a slot which is marked non-removable.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 062b49f817aa5062cfe6e4d89278eda6cd1c6853
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Jan 17 21:05:55 2018 +0100

    HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working
    
    commit edfc3722cfef4217c7fe92b272cbe0288ba1ff57 upstream.
    
    The Toshiba Click Mini uses an i2c attached keyboard/touchpad combo
    (single i2c_hid device for both) which has a vid:pid of 04F3:0401,
    which is also used by a bunch of Elan touchpads which are handled by the
    drivers/input/mouse/elan_i2c driver, but that driver deals with pure
    touchpads and does not work for a combo device such as the one on the
    Toshiba Click Mini.
    
    The combo on the Mini has an ACPI id of ELAN0800, which is not claimed
    by the elan_i2c driver, so check for that and if it is found do not ignore
    the device. This fixes the keyboard/touchpad combo on the Mini not working
    (although with the touchpad in mouse emulation mode).
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f877972bcf62ea90a6ede994f629680977cc9e2f
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Feb 6 15:41:56 2018 -0800

    pipe: fix off-by-one error when checking buffer limits
    
    commit 9903a91c763ecdae333a04a9d89d79d2b8966503 upstream.
    
    With pipe-user-pages-hard set to 'N', users were actually only allowed up
    to 'N - 1' buffers; and likewise for pipe-user-pages-soft.
    
    Fix this to allow up to 'N' buffers, as would be expected.
    
    Link: http://lkml.kernel.org/r/20180111052902.14409-5-ebiggers3@gmail.com
    Fixes: b0b91d18e2e9 ("pipe: fix limit checking in pipe_set_size()")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Willy Tarreau <w@1wt.eu>
    Acked-by: Kees Cook <keescook@chromium.org>
    Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: "Luis R . Rodriguez" <mcgrof@kernel.org>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f361f601c0498c6a36bc044f5df8b778cf4e586
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Feb 6 15:41:53 2018 -0800

    pipe: actually allow root to exceed the pipe buffer limits
    
    commit 85c2dd5473b2718b4b63e74bfeb1ca876868e11f upstream.
    
    pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
    to unprivileged users, as documented in both Documentation/sysctl/fs.txt
    and the pipe(7) man page.
    
    However, the capabilities are actually only checked when increasing a
    pipe's size using F_SETPIPE_SZ, not when creating a new pipe.  Therefore,
    if pipe-user-pages-hard has been set, the root user can run into it and be
    unable to create pipes.  Similarly, if pipe-user-pages-soft has been set,
    the root user can run into it and have their pipes limited to 1 page each.
    
    Fix this by allowing the privileged override in both cases.
    
    Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com
    Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: "Luis R . Rodriguez" <mcgrof@kernel.org>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: Mikulas Patocka <mpatocka@redhat.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4ae624fc00373514c266f7ddfdbd8b6c2a21bb7
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Feb 6 15:40:24 2018 -0800

    kernel/relay.c: revert "kernel/relay.c: fix potential memory leak"
    
    commit a1be1f3931bfe0a42b46fef77a04593c2b136e7f upstream.
    
    This reverts commit ba62bafe942b ("kernel/relay.c: fix potential memory leak").
    
    This commit introduced a double free bug, because 'chan' is already
    freed by the line:
    
        kref_put(&chan->kref, relay_destroy_channel);
    
    This bug was found by syzkaller, using the BLKTRACESETUP ioctl.
    
    Link: http://lkml.kernel.org/r/20180127004759.101823-1-ebiggers3@gmail.com
    Fixes: ba62bafe942b ("kernel/relay.c: fix potential memory leak")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c84c68fc2321154f1549210c751f7325d75f1b0f
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Tue Feb 6 15:37:55 2018 -0800

    kernel/async.c: revert "async: simplify lowest_in_progress()"
    
    commit 4f7e988e63e336827f4150de48163bed05d653bd upstream.
    
    This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()")
    which was simply wrong: In the case where domain is NULL, we now use the
    wrong offsetof() in the list_first_entry macro, so we don't actually
    fetch the ->cookie value, but rather the eight bytes located
    sizeof(struct list_head) further into the struct async_entry.
    
    On 64 bit, that's the data member, while on 32 bit, that's a u64 built
    from func and data in some order.
    
    I think the bug happens to be harmless in practice: It obviously only
    affects callers which pass a NULL domain, and AFAICT the only such
    caller is
    
      async_synchronize_full() ->
      async_synchronize_full_domain(NULL) ->
      async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
    
    and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
    the async_global_pending list to be empty - but it would break if
    somebody happened to pass (void*)-1 as the data element to
    async_schedule, and of course also if somebody ever does a
    async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
    
    Maybe the "harmless in practice" means this isn't -stable material.  But
    I'm not completely confident my quick git grep'ing is enough, and there
    might be affected code in one of the earlier kernels that has since been
    removed, so I'll leave the decision to the stable guys.
    
    Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk
    Fixes: 92266d6ef60c "async: simplify lowest_in_progress()"
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Acked-by: Tejun Heo <tj@kernel.org>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Adam Wallis <awallis@codeaurora.org>
    Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20819e0cdfa84763bc5b6da8d1624931a9fae474
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Tue Feb 6 15:37:13 2018 -0800

    fs/proc/kcore.c: use probe_kernel_read() instead of memcpy()
    
    commit d0290bc20d4739b7a900ae37eb5d4cc3be2b393f upstream.
    
    Commit df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext
    data") added a bounce buffer to avoid hardened usercopy checks.  Copying
    to the bounce buffer was implemented with a simple memcpy() assuming
    that it is always valid to read from kernel memory iff the
    kern_addr_valid() check passed.
    
    A simple, but pointless, test case like "dd if=/proc/kcore of=/dev/null"
    now can easily crash the kernel, since the former execption handling on
    invalid kernel addresses now doesn't work anymore.
    
    Also adding a kern_addr_valid() implementation wouldn't help here.  Most
    architectures simply return 1 here, while a couple implemented a page
    table walk to figure out if something is mapped at the address in
    question.
    
    With DEBUG_PAGEALLOC active mappings are established and removed all the
    time, so that relying on the result of kern_addr_valid() before
    executing the memcpy() also doesn't work.
    
    Therefore simply use probe_kernel_read() to copy to the bounce buffer.
    This also allows to simplify read_kcore().
    
    At least on s390 this fixes the observed crashes and doesn't introduce
    warnings that were removed with df04abfd181a ("fs/proc/kcore.c: Add
    bounce buffer for ktext data"), even though the generic
    probe_kernel_read() implementation uses uaccess functions.
    
    While looking into this I'm also wondering if kern_addr_valid() could be
    completely removed...(?)
    
    Link: http://lkml.kernel.org/r/20171202132739.99971-1-heiko.carstens@de.ibm.com
    Fixes: df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
    Fixes: f5509cc18daa ("mm: Hardened usercopy")
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c578f7ee61fed0bd8136231c327842153f0e0c5f
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Wed Jan 24 06:01:57 2018 -0500

    media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
    
    commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.
    
    The XC2028_I2C_FLUSH only needs to be implemented on a few
    devices. Others can safely ignore it.
    
    That prevents filling the dmesg with lots of messages like:
    
            dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
    
    Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
    Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bddff4ff67edf3e1f3363e29be6f530db548fbc
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Thu Jan 25 06:57:45 2018 -0500

    media: vivid: fix module load error when enabling fb and no_error_inj=1
    
    commit 0fa2c5f954c41e870fe327907c01cb8f7ea8d5a2 upstream.
    
    If the framebuffer is enabled and error injection is disabled, then
    creating the controls for the video output device would fail with an
    error.
    
    This is because the Clear Framebuffer control uses the 'vivid control
    class' and that control class isn't added if error injection is disabled.
    
    In addition, this control was added to e.g. vbi devices as well, which
    makes no sense.
    
    Move this control to its own control handler and handle it correctly.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cefbd21480ddcde959e89df8f90fdec5fd5700c8
Author: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Date:   Wed Jan 10 07:20:39 2018 -0500

    media: ts2020: avoid integer overflows on 32 bit machines
    
    commit 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 upstream.
    
    Before this patch, when compiled for arm32, the signal strength
    were reported as:
    
    Lock   (0x1f) Signal= 4294908.66dBm C/N= 12.79dB
    
    Because of a 32 bit integer overflow. After it, it is properly
    reported as:
    
            Lock   (0x1f) Signal= -58.64dBm C/N= 12.79dB
    
    Fixes: 0f91c9d6bab9 ("[media] TS2020: Calculate tuner gain correctly")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de87fcee48bc7a373b5eda97cda36189ae17f321
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Sat Dec 16 05:44:13 2017 -0500

    media: dt-bindings/media/cec-gpio.txt: mention the CEC/HPD max voltages
    
    commit dac15ed62dc9d7898d3695a3c393d6f712d66185 upstream.
    
    Mention the maximum voltages of the CEC and HPD lines. Since in the example
    these lines are connected to a Raspberry Pi and the Rpi GPIO lines are 3.3V
    it is a good idea to warn against directly connecting the HPD to the Raspberry
    Pi's GPIO line.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reviewed-by: Rob Herring <robh@kernel.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 ec1eeaf5b6c12b561d9a90588987e44a2e2f8b1a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Nov 30 11:55:46 2017 -0500

    media: dvb-frontends: fix i2c access helpers for KASAN
    
    commit 3cd890dbe2a4f14cc44c85bb6cf37e5e22d4dd0e upstream.
    
    A typical code fragment was copied across many dvb-frontend drivers and
    causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:
    
    drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
    drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
    drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
    drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
    drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
    
    gcc-8 now solves this by consolidating the stack slots for the argument
    variables, but on older compilers we can get the same behavior by taking
    the pointer of a local variable rather than the inline function argument.
    
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
    
    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 2058517f456c088a8eede9df023696ac9c1e71de
Author: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Date:   Wed Nov 1 17:05:39 2017 -0400

    media: dvb_frontend: be sure to init dvb_frontend_handle_ioctl() return code
    
    commit a9cb97c3e628902e37583d8a40bb28cf76522cf1 upstream.
    
    As smatch warned:
            drivers/media/dvb-core/dvb_frontend.c:2468 dvb_frontend_handle_ioctl() error: uninitialized symbol 'err'.
    
    The ioctl handler actually got a regression here: before changeset
    d73dcf0cdb95 ("media: dvb_frontend: cleanup ioctl handling logic"),
    the code used to return -EOPNOTSUPP if an ioctl handler was not
    implemented on a driver. After the change, it may return a random
    value.
    
    Fixes: d73dcf0cdb95 ("media: dvb_frontend: cleanup ioctl handling logic")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Tested-by: Daniel Scheller <d.scheller@gmx.net>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6de976631b2809ad70c412fb791fc13e531e9ee
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 6 15:41:41 2018 -0800

    kasan: rework Kconfig settings
    
    commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.
    
    We get a lot of very large stack frames using gcc-7.0.1 with the default
    -fsanitize-address-use-after-scope --param asan-stack=1 options, which can
    easily cause an overflow of the kernel stack, e.g.
    
      drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
      drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
      lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
      drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
      drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
      fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
    
    To reduce this risk, -fsanitize-address-use-after-scope is now split out
    into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
    frames that are smaller than 2 kilobytes most of the time on x86_64.  An
    earlier version of this patch also prevented combining KASAN_EXTRA with
    KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
    
    All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
    and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
    bring back that default now.  KASAN_EXTRA=y still causes lots of
    warnings but now defaults to !COMPILE_TEST to disable it in
    allmodconfig, and it remains disabled in all other defconfigs since it
    is a new option.  I arbitrarily raise the warning limit for KASAN_EXTRA
    to 3072 to reduce the noise, but an allmodconfig kernel still has around
    50 warnings on gcc-7.
    
    I experimented a bit more with smaller stack frames and have another
    follow-up series that reduces the warning limit for 64-bit architectures
    to 1280 bytes (without CONFIG_KASAN).
    
    With earlier versions of this patch series, I also had patches to address
    the warnings we get with KASAN and/or KASAN_EXTRA, using a
    "noinline_if_stackbloat" annotation.
    
    That annotation now got replaced with a gcc-8 bugfix (see
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
    older compilers, which means that KASAN_EXTRA is now just as bad as
    before and will lead to an instant stack overflow in a few extreme
    cases.
    
    This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable
    -Wframe-larger-than warnings with KASAN=y").  Two patches in linux-next
    should be merged first to avoid introducing warnings in an allmodconfig
    build:
      3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
      16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")
    
    Do we really need to backport this?
    
    I think we do: without this patch, enabling KASAN will lead to
    unavoidable kernel stack overflow in certain device drivers when built
    with gcc-7 or higher on linux-4.10+ or any version that contains a
    backport of commit c5caf21ab0cf8.  Most people are probably still on
    older compilers, but it will get worse over time as they upgrade their
    distros.
    
    The warnings we get on kernels older than this should all be for code
    that uses dangerously large stack frames, though most of them do not
    cause an actual stack overflow by themselves.The asan-stack option was
    added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug:
    disable -Wframe-larger-than warnings with KASAN=y") effectively turned
    off the warning for allmodconfig kernels, so I would like to see this
    fix backported to any kernels later than 4.0.
    
    I have done dozens of fixes for individual functions with stack frames
    larger than 2048 bytes with asan-stack, and I plan to make sure that
    all those fixes make it into the stable kernels as well (most are
    already there).
    
    Part of the complication here is that asan-stack (from 4.0) was
    originally assumed to always require much larger stacks, but that
    turned out to be a combination of multiple gcc bugs that we have now
    worked around and fixed, but sanitize-address-use-after-scope (from
    v4.10) has a much higher inherent stack usage and also suffers from at
    least three other problems that we have analyzed but not yet fixed
    upstream, each of them makes the stack usage more severe than it should
    be.
    
    Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d5dd742cbf5bd7bb5c01e90b576561a4810b674
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Tue Feb 6 15:36:00 2018 -0800

    kasan: don't emit builtin calls when sanitization is off
    
    commit 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 upstream.
    
    With KASAN enabled the kernel has two different memset() functions, one
    with KASAN checks (memset) and one without (__memset).  KASAN uses some
    macro tricks to use the proper version where required.  For example
    memset() calls in mm/slub.c are without KASAN checks, since they operate
    on poisoned slab object metadata.
    
    The issue is that clang emits memset() calls even when there is no
    memset() in the source code.  They get linked with improper memset()
    implementation and the kernel fails to boot due to a huge amount of KASAN
    reports during early boot stages.
    
    The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
    n marker.
    
    Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.1516384594.git.andreyknvl@google.com
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Acked-by: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: Michal Marek <michal.lkml@markovi.net>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e2dee3fc6e02773124db9c019e5bb26e3166981
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Fri Jan 12 18:07:01 2018 -0700

    Btrfs: raid56: iterate raid56 internal bio with bio_for_each_segment_all
    
    commit 0198e5b707cfeb5defbd1b71b1ec6e71580d7db9 upstream.
    
    Bio iterated by set_bio_pages_uptodate() is raid56 internal one, so it
    will never be a BIO_CLONED bio, and since this is called by end_io
    functions, bio->bi_iter.bi_size is zero, we mustn't use
    bio_for_each_segment() as that is a no-op if bi_size is zero.
    
    Fixes: 6592e58c6b68e61f003a01ba29a3716e7e2e9484 ("Btrfs: fix write corruption due to bio cloning on raid5/6")
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04f417b0312cad8ef68d75e0db80153a402b1f85
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Tue Dec 5 09:29:19 2017 +0200

    btrfs: Handle btrfs_set_extent_delalloc failure in fixup worker
    
    commit f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb upstream.
    
    This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
    to deal with pages that have been improperly dirtied") and it didn't do
    any error handling then. This function might very well fail in ENOMEM
    situation, yet it's not handled, this could lead to inconsistent state.
    So let's handle the failure by setting the mapping error bit.
    
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51611b5d19a5f07dda1c22b8f8e3688c9d76a6b1
Author: David Howells <dhowells@redhat.com>
Date:   Tue Feb 6 14:12:32 2018 +0000

    afs: Fix server list handling
    
    commit 45df8462730d2149834980d3db16e2d2b9daaf60 upstream.
    
    Fix server list handling in the following ways:
    
     (1) In afs_alloc_volume(), remove duplicate server list build code.  This
         was already done by afs_alloc_server_list() which afs_alloc_volume()
         previously called.  This just results in twice as many VL RPCs.
    
     (2) In afs_deliver_vl_get_entry_by_name_u(), use the number of server
         records indicated by ->nServers in the UVLDB record returned by the
         VL.GetEntryByNameU RPC call rather than scanning all NMAXNSERVERS
         slots.  Unused slots may contain garbage.
    
     (3) In afs_alloc_server_list(), don't stop converting a UVLDB record into
         a server list just because we can't look up one of the servers.  Just
         skip that server and go on to the next.  If we can't look up any of
         the servers then we'll fail at the end.
    
    Without this patch, an attempt to view the umich.edu root cell using
    something like "ls /afs/umich.edu" on a dynamic root (future patch) mount
    or an autocell mount will result in ENOMEDIUM.  The failure is due to kafs
    not stopping after nServers'worth of records have been read, but then
    trying to access a server with a garbage UUID and getting an error, which
    aborts the server list build.
    
    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Reported-by: Jonathan Billings <jsbillings@jsbillings.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0a594704ff3ca87dee26925ac237717203a04ed
Author: David Howells <dhowells@redhat.com>
Date:   Tue Feb 6 06:26:30 2018 +0000

    afs: Fix missing cursor clearance
    
    commit fe4d774c847398c2a45c10a780ccfde069840793 upstream.
    
    afs_select_fileserver() ends the address cursor it is using in the case in
    which we get some sort of network error and run out of addresses to iterate
    through, before it jumps to try the next server.  This also needs to be
    done when the server aborts with some sort of error that means we should
    try the next server.
    
    Fix this by:
    
     (1) Move the iterate_address afs_end_cursor() call to the next_server
         case.
    
     (2) End the cursor in the failed case.
    
     (3) Make afs_end_cursor() clear the ->begun flag and ->addr pointer in the
         address cursor.
    
     (4) Make afs_end_cursor() able to be called on an already cleared cursor.
    
    Without this, something like the following oops may occur:
    
            AFS: Assertion failed
            18446612134397189888 == 0 is false
            0xffff88007c279f00 == 0x0 is false
            ------------[ cut here ]------------
            kernel BUG at fs/afs/rotate.c:360!
            RIP: 0010:afs_select_fileserver+0x79b/0xa30 [kafs]
            Call Trace:
             afs_statfs+0xcc/0x180 [kafs]
             ? p9_client_statfs+0x9e/0x110 [9pnet]
             ? _cond_resched+0x19/0x40
             statfs_by_dentry+0x6d/0x90
             vfs_statfs+0x1b/0xc0
             user_statfs+0x4b/0x80
             SYSC_statfs+0x15/0x30
             SyS_statfs+0xe/0x10
             entry_SYSCALL_64_fastpath+0x20/0x83
    
    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Reported-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b690011c27d90bf80585ff25bb15a07a533540d
Author: David Howells <dhowells@redhat.com>
Date:   Tue Feb 6 06:26:30 2018 +0000

    afs: Need to clear responded flag in addr cursor
    
    commit 8305e579c653b127b292fcdce551e930f9560260 upstream.
    
    In afs_select_fileserver(), we need to clear the ->responded flag in the
    address list when reusing it.  We should also clear it in
    afs_select_current_fileserver().
    
    To this end, just memset() the object before initialising it.
    
    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da89b2d752e97b2f5de5fda8cfa1ad4b7717a37e
Author: David Howells <dhowells@redhat.com>
Date:   Tue Feb 6 09:26:27 2018 +0000

    afs: Add missing afs_put_cell()
    
    commit e44150157f42219fa5c074588efdb31ccfb197fc upstream.
    
    afs_alloc_volume() needs to release the cell ref it obtained in the case of
    an error.  Fix this by adding an afs_put_cell() call into the error path.
    
    This can triggered when a lookup for a cell in a dynamic root or an
    autocell mount returns an error whilst trying to look up the server (such
    as ENOMEDIUM).  This results in an assertion failure oops when the module
    is unloaded due to outstanding refs on a cell record.
    
    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03a7be790fc9f59bfc81019648782b1ec0d825ee
Author: Martin Kaiser <martin@kaiser.cx>
Date:   Mon Jan 1 18:26:47 2018 +0100

    watchdog: imx2_wdt: restore previous timeout after suspend+resume
    
    commit 0be267255cef64e1c58475baa7b25568355a3816 upstream.
    
    When the watchdog device is suspended, its timeout is set to the maximum
    value. During resume, the previously set timeout should be restored.
    This does not work at the moment.
    
    The suspend function calls
    
    imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
    
    and resume reverts this by calling
    
    imx2_wdt_set_timeout(wdog, wdog->timeout);
    
    However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore,
    wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume
    function.
    
    Fix this by adding a new function __imx2_wdt_set_timeout() which
    only updates the hardware settings. imx2_wdt_set_timeout() now calls
    __imx2_wdt_set_timeout() and then saves the new timeout to
    wdog->timeout.
    
    During suspend, we call __imx2_wdt_set_timeout() directly so that
    wdog->timeout won't be updated and we can restore the previous value
    during resume. This approach makes wdog->timeout different from the
    actual setting in the hardware which is usually not a good thing.
    However, the two differ only while we're suspended and no kernel code is
    running, so it should be ok in this case.
    
    Signed-off-by: Martin Kaiser <martin@kaiser.cx>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16c4b6e0c06412d180356bce91fafa39dfc374fd
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Fri Jan 26 13:08:43 2018 +0000

    ASoC: compress: Correct handling of copy callback
    
    commit 290df4d3ab192821b66857c05346b23056ee9545 upstream.
    
    The soc_compr_copy callback is currently broken. Since the
    changes to move the compr_ops over to the component the return
    value is not correctly propagated, always returning zero on
    success rather than the number of bytes copied. This causes
    user-space to stall continuously reading as it does not believe
    it has received any data.
    
    Furthermore, the changes to move the compr_ops over to the
    component iterate through the list of components and will call
    the copy callback for any that have compressed ops. There isn't
    currently any consensus on the mechanism to combine the results
    of multiple copy callbacks.
    
    To fix this issue for now halt searching the component list when
    we locate a copy callback and return the result of that single
    callback. Additional work should probably be done to look at the
    other ops, tidy things up, and work out if we want to support
    multiple components on a single compressed, but this is the only
    fix required to get things working again.
    
    Fixes: 9e7e3738ab0e ("ASoC: snd_soc_component_driver has snd_compr_ops")
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5711cf9b8908770e96d2b91fae6c6684e183f54f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 3 16:38:46 2018 +0100

    ASoC: skl: Fix kernel warning due to zero NHTL entry
    
    commit 20a1ea2222e7cbf96e9bf8579362e971491e6aea upstream.
    
    I got the following kernel warning when loading snd-soc-skl module on
    Dell Latitude 7270 laptop:
     memremap attempted on mixed range 0x0000000000000000 size: 0x0
     WARNING: CPU: 0 PID: 484 at kernel/memremap.c:98 memremap+0x8a/0x180
     Call Trace:
      skl_nhlt_init+0x82/0xf0 [snd_soc_skl]
      skl_probe+0x2ee/0x7c0 [snd_soc_skl]
      ....
    
    It seems that the machine doesn't support the SKL DSP gives the empty
    NHLT entry, and it triggers the warning.  For avoiding it, let do the
    zero check before calling memremap().
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a042d14100fdc55a50739fc8b98c1e7c4129968
Author: John Keeping <john@metanate.com>
Date:   Mon Jan 8 16:01:04 2018 +0000

    ASoC: rockchip: i2s: fix playback after runtime resume
    
    commit c66234cfedfc3e6e3b62563a5f2c1562be09a35d upstream.
    
    When restoring registers during runtime resume, we must not write to
    I2S_TXDR which is the transmit FIFO as this queues up a sample to be
    output and pushes all of the output channels down by one.
    
    This can be demonstrated with the speaker-test utility:
    
            for i in a b c; do speaker-test -c 2 -s 1; done
    
    which should play a test through the left speaker three times but if the
    I2S hardware starts runtime suspended the first sample will be played
    through the right speaker.
    
    Fix this by marking I2S_TXDR as volatile (which also requires marking it
    as readble, even though it technically isn't).  This seems to be the
    most robust fix, the alternative of giving I2S_TXDR a default value is
    more fragile since it does not prevent regcache writing to the register
    in all circumstances.
    
    While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
    are not writable so they do not suffer from the same problem as I2S_TXDR
    but reading from I2S_RXDR does suffer from a similar problem.
    
    Fixes: f0447f6cbb20 ("ASoC: rockchip: i2s: restore register during runtime_suspend/resume cycle", 2016-09-07)
    Signed-off-by: John Keeping <john@metanate.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bd298ee74d8768517f7b92e733fda4771f9bb63
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Fri Jan 5 14:55:33 2018 -0600

    ASoC: acpi: fix machine driver selection based on quirk
    
    commit 5c256045b87b8aa8e5bc9d2e2fdc0802351c1f99 upstream.
    
    The ACPI/machine-driver code refactoring introduced in 4.13 introduced
    a regression for cases where we need a DMI-based quirk to select the
    machine driver (the BIOS reports an invalid HID). The fix is just to
    make sure the results of the quirk are actually used.
    
    Fixes: 54746dabf770 ('ASoC: Improve machine driver selection based on quirk data')
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691
    Tested-by: Nicole Færber <nicole.faerber@dpin.de>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8000c0f576336c677ac60d1c7e342643bf4cb1de
Author: Ulf Magnusson <ulfalizer@gmail.com>
Date:   Mon Feb 5 02:21:14 2018 +0100

    KVM: PPC: Book3S PR: Fix broken select due to misspelling
    
    commit 57ea5f161a7de5b1913c212d04f57a175b159fdf upstream.
    
    Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code
    on non-pseries platforms") added a reference to the globally undefined
    symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was
    probably intended.
    
    Change PPC_SERIES to PPC_PSERIES.
    
    Discovered with the
    https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
    script.
    
    Fixes: 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms")
    Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47415812fec37ba0c42550f68b0139b2a0955279
Author: James Morse <james.morse@arm.com>
Date:   Mon Jan 22 18:19:06 2018 +0000

    KVM: arm/arm64: Handle CPU_PM_ENTER_FAILED
    
    commit 58d6b15e9da5042a99c9c30ad725792e4569150e upstream.
    
    cpu_pm_enter() calls the pm notifier chain with CPU_PM_ENTER, then if
    there is a failure: CPU_PM_ENTER_FAILED.
    
    When KVM receives CPU_PM_ENTER it calls cpu_hyp_reset() which will
    return us to the hyp-stub. If we subsequently get a CPU_PM_ENTER_FAILED,
    KVM does nothing, leaving the CPU running with the hyp-stub, at odds
    with kvm_arm_hardware_enabled.
    
    Add CPU_PM_ENTER_FAILED as a fallthrough for CPU_PM_EXIT, this reloads
    KVM based on kvm_arm_hardware_enabled. This is safe even if CPU_PM_ENTER
    never gets as far as KVM, as cpu_hyp_reinit() calls cpu_hyp_reset()
    to make sure the hyp-stub is loaded before reloading KVM.
    
    Fixes: 67f691976662 ("arm64: kvm: allows kvm cpu hotplug")
    CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 703f0395362ab008af8733ee1927bcb765677496
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Tue Jan 30 10:51:32 2018 +1100

    KVM: PPC: Book3S HV: Drop locks before reading guest memory
    
    commit 36ee41d161c67a6fcf696d4817a0da31f778938c upstream.
    
    Running with CONFIG_DEBUG_ATOMIC_SLEEP reveals that HV KVM tries to
    read guest memory, in order to emulate guest instructions, while
    preempt is disabled and a vcore lock is held.  This occurs in
    kvmppc_handle_exit_hv(), called from post_guest_process(), when
    emulating guest doorbell instructions on POWER9 systems, and also
    when checking whether we have hit a hypervisor breakpoint.
    Reading guest memory can cause a page fault and thus cause the
    task to sleep, so we need to avoid reading guest memory while
    holding a spinlock or when preempt is disabled.
    
    To fix this, we move the preempt_enable() in kvmppc_run_core() to
    before the loop that calls post_guest_process() for each vcore that
    has just run, and we drop and re-take the vcore lock around the calls
    to kvmppc_emulate_debug_inst() and kvmppc_emulate_doorbell_instr().
    
    Dropping the lock is safe with respect to the iteration over the
    runnable vcpus in post_guest_process(); for_each_runnable_thread
    is actually safe to use locklessly.  It is possible for a vcpu
    to become runnable and add itself to the runnable_threads array
    (code near the beginning of kvmppc_run_vcpu()) and then get included
    in the iteration in post_guest_process despite the fact that it
    has not just run.  This is benign because vcpu->arch.trap and
    vcpu->arch.ceded will be zero.
    
    Fixes: 579006944e0d ("KVM: PPC: Book3S HV: Virtualize doorbell facility on POWER9")
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e46778efc9f1329d55746b6a4e24adc1a3f8db7
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Thu Jan 11 14:31:43 2018 +1100

    KVM: PPC: Book3S HV: Make sure we don't re-enter guest without XIVE loaded
    
    commit 43ff3f65234061e08d234bdef5a9aadc19832b74 upstream.
    
    This fixes a bug where it is possible to enter a guest on a POWER9
    system without having the XIVE (interrupt controller) context loaded.
    This can happen because we unload the XIVE context from the CPU
    before doing the real-mode handling for machine checks.  After the
    real-mode handler runs, it is possible that we re-enter the guest
    via a fast path which does not load the XIVE context.
    
    To fix this, we move the unloading of the XIVE context to come after
    the real-mode machine check handler is called.
    
    Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8285c292436c75c6b985ce1cc931d747c67bf55f
Author: Liran Alon <liran.alon@oracle.com>
Date:   Sun Nov 19 18:25:43 2017 +0200

    KVM: nVMX: Fix bug of injecting L2 exception into L1
    
    commit 5c7d4f9ad39d980728b39752304ce10bb2960cbf upstream.
    
    kvm_clear_exception_queue() should clear pending exception.
    This also includes exceptions which were only marked pending but not
    yet injected. This is because exception.pending is used for both L1
    and L2 to determine if an exception should be raised to guest.
    Note that an exception which is pending but not yet injected will
    be raised again once the guest will be resumed.
    
    Consider the following scenario:
    1) L0 KVM with ignore_msrs=false.
    2) L1 prepare vmcs12 with the following:
        a) No intercepts on MSR (MSR_BITMAP exist and is filled with 0).
        b) No intercept for #GP.
        c) vmx-preemption-timer is configured.
    3) L1 enters into L2.
    4) L2 reads an unhandled MSR that exists in MSR_BITMAP
    (such as 0x1fff).
    
    L2 RDMSR could be handled as described below:
    1) L2 exits to L0 on RDMSR and calls handle_rdmsr().
    2) handle_rdmsr() calls kvm_inject_gp() which sets
    KVM_REQ_EVENT, exception.pending=true and exception.injected=false.
    3) vcpu_enter_guest() consumes KVM_REQ_EVENT and calls
    inject_pending_event() which calls vmx_check_nested_events()
    which sees that exception.pending=true but
    nested_vmx_check_exception() returns 0 and therefore does nothing at
    this point. However let's assume it later sees vmx-preemption-timer
    expired and therefore exits from L2 to L1 by calling
    nested_vmx_vmexit().
    4) nested_vmx_vmexit() calls prepare_vmcs12()
    which calls vmcs12_save_pending_event() but it does nothing as
    exception.injected is false. Also prepare_vmcs12() calls
    kvm_clear_exception_queue() which does nothing as
    exception.injected is already false.
    5) We now return from vmx_check_nested_events() with 0 while still
    having exception.pending=true!
    6) Therefore inject_pending_event() continues
    and we inject L2 exception to L1!...
    
    This commit will fix above issue by changing step (4) to
    clear exception.pending in kvm_clear_exception_queue().
    
    Fixes: 664f8e26b00c ("KVM: X86: Fix loss of exception which has not yet been injected")
    Signed-off-by: Liran Alon <liran.alon@oracle.com>
    Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
    Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
    Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cb7e6931e5222f4908149dbee829666cde0e276
Author: Liran Alon <liran.alon@oracle.com>
Date:   Thu Nov 9 20:27:20 2017 +0200

    KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2
    
    commit 6b6977117f50d60455ace86b2d256f6fb4f3de05 upstream.
    
    Consider the following scenario:
    1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
    to CPU B via virtual posted-interrupt mechanism.
    2. CPU B is currently executing L2 guest.
    3. vmx_deliver_nested_posted_interrupt() calls
    kvm_vcpu_trigger_posted_interrupt() which will note that
    vcpu->mode == IN_GUEST_MODE.
    4. Assume that before CPU A sends the physical POSTED_INTR_NESTED_VECTOR
    IPI, CPU B exits from L2 to L0 during event-delivery
    (valid IDT-vectoring-info).
    5. CPU A now sends the physical IPI. The IPI is received in host and
    it's handler (smp_kvm_posted_intr_nested_ipi()) does nothing.
    6. Assume that before CPU A sets pi_pending=true and KVM_REQ_EVENT,
    CPU B continues to run in L0 and reach vcpu_enter_guest(). As
    KVM_REQ_EVENT is not set yet, vcpu_enter_guest() will continue and resume
    L2 guest.
    7. At this point, CPU A sets pi_pending=true and KVM_REQ_EVENT but
    it's too late! CPU B already entered L2 and KVM_REQ_EVENT will only be
    consumed at next L2 entry!
    
    Another scenario to consider:
    1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
    to CPU B via virtual posted-interrupt mechanism.
    2. Assume that before CPU A calls kvm_vcpu_trigger_posted_interrupt(),
    CPU B is at L0 and is about to resume into L2. Further assume that it is
    in vcpu_enter_guest() after check for KVM_REQ_EVENT.
    3. At this point, CPU A calls kvm_vcpu_trigger_posted_interrupt() which
    will note that vcpu->mode != IN_GUEST_MODE. Therefore, do nothing and
    return false. Then, will set pi_pending=true and KVM_REQ_EVENT.
    4. Now CPU B continue and resumes into L2 guest without processing
    the posted-interrupt until next L2 entry!
    
    To fix both issues, we just need to change
    vmx_deliver_nested_posted_interrupt() to set pi_pending=true and
    KVM_REQ_EVENT before calling kvm_vcpu_trigger_posted_interrupt().
    
    It will fix the first scenario by chaging step (6) to note that
    KVM_REQ_EVENT and pi_pending=true and therefore process
    nested posted-interrupt.
    
    It will fix the second scenario by two possible ways:
    1. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B has changed
    vcpu->mode to IN_GUEST_MODE, physical IPI will be sent and will be received
    when CPU resumes into L2.
    2. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B hasn't yet
    changed vcpu->mode to IN_GUEST_MODE, then after CPU B will change
    vcpu->mode it will call kvm_request_pending() which will return true and
    therefore force another round of vcpu_enter_guest() which will note that
    KVM_REQ_EVENT and pi_pending=true and therefore process nested
    posted-interrupt.
    
    Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing")
    Signed-off-by: Liran Alon <liran.alon@oracle.com>
    Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
    Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
    [Add kvm_vcpu_kick to also handle the case where L1 doesn't intercept L2 HLT
     and L2 executes HLT instruction. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d3bb572ef4410e3b404bec47a1f89b64b14d1bd
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:06 2018 +0000

    arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
    
    commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream.
    
    KVM doesn't follow the SMCCC when it comes to unimplemented calls,
    and inject an UNDEF instead of returning an error. Since firmware
    calls are now used for security mitigation, they are becoming more
    common, and the undef is counter productive.
    
    Instead, let's follow the SMCCC which states that -1 must be returned
    to the caller when getting an unknown function number.
    
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e76a4b126d1e7fbd0124cb885331a45e9a24f32b
Author: LEROY Christophe <christophe.leroy@c-s.fr>
Date:   Fri Jan 26 17:09:59 2018 +0100

    crypto: talitos - fix Kernel Oops on hashing an empty file
    
    commit 87a81dce53b1ea61acaeefa5191a0376a2d1d721 upstream.
    
    Performing the hash of an empty file leads to a kernel Oops
    
    [   44.504600] Unable to handle kernel paging request for data at address 0x0000000c
    [   44.512819] Faulting instruction address: 0xc02d2be8
    [   44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
    [   44.529171] BE PREEMPT CMPC885
    [   44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
    [   44.540814] NIP:  c02d2be8 LR: c02d2984 CTR: 00000000
    [   44.545812] REGS: c6813c90 TRAP: 0300   Not tainted  (4.15.0-rc8-00211-g3a968610b6ea)
    [   44.554223] MSR:  00009032 <EE,ME,IR,DR,RI>  CR: 48222822  XER: 20000000
    [   44.560855] DAR: 0000000c DSISR: c0000000
    [   44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
    [   44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
    [   44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
    [   44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
    [   44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
    [   44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
    [   44.608868] Call Trace:
    [   44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
    [   44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
    [   44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
    [   44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
    [   44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
    [   44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
    [   44.645530] Instruction dump:
    [   44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
    [   44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
    
    This patch fixes that Oops by checking if src is NULL.
    
    Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97905e9cf76a4a0eace41c24ab7582c02b6517a9
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 24 00:31:27 2018 -0800

    crypto: sha512-mb - initialize pending lengths correctly
    
    commit eff84b379089cd8b4e83599639c1f5f6e34ef7bf upstream.
    
    The SHA-512 multibuffer code keeps track of the number of blocks pending
    in each lane.  The minimum of these values is used to identify the next
    lane that will be completed.  Unused lanes are set to a large number
    (0xFFFFFFFF) so that they don't affect this calculation.
    
    However, it was forgotten to set the lengths to this value in the
    initial state, where all lanes are unused.  As a result it was possible
    for sha512_mb_mgr_get_comp_job_avx2() to select an unused lane, causing
    a NULL pointer dereference.  Specifically this could happen in the case
    where ->update() was passed fewer than SHA512_BLOCK_SIZE bytes of data,
    so it then called sha_complete_job() without having actually submitted
    any blocks to the multi-buffer code.  This hit a NULL pointer
    dereference if another task happened to have submitted blocks
    concurrently to the same CPU and the flush timer had not yet expired.
    
    Fix this by initializing sha512_mb_mgr->lens correctly.
    
    As usual, this bug was found by syzkaller.
    
    Fixes: 45691e2d9b18 ("crypto: sha512-mb - submit/flush routines for AVX2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bde50164e671849f175422c3f846ff00d651b3ec
Author: Horia Geantă <horia.geanta@nxp.com>
Date:   Mon Feb 5 11:15:52 2018 +0200

    crypto: caam - fix endless loop when DECO acquire fails
    
    commit 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 upstream.
    
    In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails
    with -ENODEV, caam_probe() enters an endless loop:
    
    run_descriptor_deco0
            ret -ENODEV
            -> instantiate_rng
                    -ENODEV, overwritten by -EAGAIN
                    ret -EAGAIN
                    -> caam_probe
                            -EAGAIN results in endless loop
    
    It turns out the error path in instantiate_rng() is incorrect,
    the checks are done in the wrong order.
    
    Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles")
    Reported-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
    Suggested-by: Auer Lukas <lukas.auer@aisec.fraunhofer.de>
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d971cb5f5fbd4af3b35a4addb850fb4b2aa8d720
Author: Hans Verkuil <hansverk@cisco.com>
Date:   Tue Jan 30 10:18:32 2018 -0500

    media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
    
    commit 273caa260035c03d89ad63d72d8cd3d9e5c5e3f1 upstream.
    
    If the device is of type VFL_TYPE_SUBDEV then vdev->ioctl_ops
    is NULL so the 'if (!ops->vidioc_query_ext_ctrl)' check would crash.
    Add a test for !ops to the condition.
    
    All sub-devices that have controls will use the control framework,
    so they do not have an equivalent to ops->vidioc_query_ext_ctrl.
    Returning false if ops is NULL is the correct thing to do here.
    
    Fixes: b8c601e8af ("v4l2-compat-ioctl32.c: fix ctrl_is_pointer")
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76db969a3bbf598bdfaa1c957a54586c2bb61fb8
Author: Daniel Mentz <danielmentz@google.com>
Date:   Wed Jul 19 19:03:19 2017 -0400

    media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic
    
    commit a1dfb4c48cc1e64eeb7800a27c66a6f7e88d075a upstream.
    
    The 32-bit compat v4l2 ioctl handling is implemented based on its 64-bit
    equivalent. It converts 32-bit data structures into its 64-bit
    equivalents and needs to provide the data to the 64-bit ioctl in user
    space memory which is commonly allocated using
    compat_alloc_user_space().
    
    However, due to how that function is implemented, it can only be called
    a single time for every syscall invocation.
    
    Supposedly to avoid this limitation, the existing code uses a mix of
    memory from the kernel stack and memory allocated through
    compat_alloc_user_space().
    
    Under normal circumstances, this would not work, because the 64-bit
    ioctl expects all pointers to point to user space memory. As a
    workaround, set_fs(KERNEL_DS) is called to temporarily disable this
    extra safety check and allow kernel pointers. However, this might
    introduce a security vulnerability: The result of the 32-bit to 64-bit
    conversion is writeable by user space because the output buffer has been
    allocated via compat_alloc_user_space(). A malicious user space process
    could then manipulate pointers inside this output buffer, and due to the
    previous set_fs(KERNEL_DS) call, functions like get_user() or put_user()
    no longer prevent kernel memory access.
    
    The new approach is to pre-calculate the total amount of user space
    memory that is needed, allocate it using compat_alloc_user_space() and
    then divide up the allocated memory to accommodate all data structures
    that need to be converted.
    
    An alternative approach would have been to retain the union type karg
    that they allocated on the kernel stack in do_video_ioctl(), copy all
    data from user space into karg and then back to user space. However, we
    decided against this approach because it does not align with other
    compat syscall implementations. Instead, we tried to replicate the
    get_user/put_user pairs as found in other places in the kernel:
    
        if (get_user(clipcount, &up->clipcount) ||
            put_user(clipcount, &kp->clipcount)) return -EFAULT;
    
    Notes from hans.verkuil@cisco.com:
    
    This patch was taken from:
        https://github.com/LineageOS/android_kernel_samsung_apq8084/commit/97b733953c06e4f0398ade18850f0817778255f7
    
    Clearly nobody could be bothered to upstream this patch or at minimum
    tell us :-( We only heard about this a week ago.
    
    This patch was rebased and cleaned up. Compared to the original I
    also swapped the order of the convert_in_user arguments so that they
    matched copy_in_user. It was hard to review otherwise. I also replaced
    the ALLOC_USER_SPACE/ALLOC_AND_GET by a normal function.
    
    Fixes: 6b5a9492ca ("v4l: introduce string control support.")
    
    Signed-off-by: Daniel Mentz <danielmentz@google.com>
    Co-developed-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.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 11fe1040030e703340a7c6c91330314e1129cdc1
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Fri Jan 26 03:24:53 2018 -0500

    media: v4l2-compat-ioctl32.c: don't copy back the result for certain errors
    
    commit d83a8243aaefe62ace433e4384a4f077bed86acb upstream.
    
    Some ioctls need to copy back the result even if the ioctl returned
    an error. However, don't do this for the error code -ENOTTY.
    It makes no sense in that cases.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cc643ab48ee22b71679db6453475de299c0ac83
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 09:33:57 2018 -0500

    media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
    
    commit 169f24ca68bf0f247d111aef07af00dd3a02ae88 upstream.
    
    There is nothing wrong with using an unknown buffer type. So
    stop spamming the kernel log whenever this happens. The kernel
    will just return -EINVAL to signal this.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b14d31a951e1af276077d40e000638fa469185e
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 06:03:08 2018 -0500

    media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32
    
    commit a751be5b142ef6bcbbb96d9899516f4d9c8d0ef4 upstream.
    
    put_v4l2_window32() didn't copy back the clip list to userspace.
    Drivers can update the clip rectangles, so this should be done.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e364b677035b61ecb9560dcc9a4bc9540f55cbe
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 05:30:59 2018 -0500

    media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
    
    commit b8c601e8af2d08f733d74defa8465303391bb930 upstream.
    
    ctrl_is_pointer just hardcoded two known string controls, but that
    caused problems when using e.g. custom controls that use a pointer
    for the payload.
    
    Reimplement this function: it now finds the v4l2_ctrl (if the driver
    uses the control framework) or it calls vidioc_query_ext_ctrl (if the
    driver implements that directly).
    
    In both cases it can now check if the control is a pointer control
    or not.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c15a21a0737a422e9c3a4ff7a0f1e2085e41855
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 05:19:59 2018 -0500

    media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
    
    commit 8ed5a59dcb47a6f76034ee760b36e089f3e82529 upstream.
    
    The struct v4l2_plane32 should set m.userptr as well. The same
    happens in v4l2_buffer32 and v4l2-compliance tests for this.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5294484a664fc25972d541127897a8df63328ca
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 05:01:31 2018 -0500

    media: v4l2-compat-ioctl32.c: avoid sizeof(type)
    
    commit 333b1e9f96ce05f7498b581509bb30cde03018bf upstream.
    
    Instead of doing sizeof(struct foo) use sizeof(*up). There even were
    cases where 4 * sizeof(__u32) was used instead of sizeof(kp->reserved),
    which is very dangerous when the size of the reserved array changes.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 991030bd0aa745478f12d97d4f3e3b66755b94cc
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 04:45:29 2018 -0500

    media: v4l2-compat-ioctl32.c: move 'helper' functions to __get/put_v4l2_format32
    
    commit 486c521510c44a04cd756a9267e7d1e271c8a4ba upstream.
    
    These helper functions do not really help. Move the code to the
    __get/put_v4l2_format32 functions.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc9a62adcd7656c9e6a40a368125d93a86e18f48
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 04:35:48 2018 -0500

    media: v4l2-compat-ioctl32.c: fix the indentation
    
    commit b7b957d429f601d6d1942122b339474f31191d75 upstream.
    
    The indentation of this source is all over the place. Fix this.
    This patch only changes whitespace.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d57714a7c0f2b79177cb3dd7476a6426e1b411ae
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 08:37:04 2018 -0500

    media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
    
    commit 3ee6d040719ae09110e5cdf24d5386abe5d1b776 upstream.
    
    The result of the VIDIOC_PREPARE_BUF ioctl was never copied back
    to userspace since it was missing in the switch.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc174e6cbdee10c46e316971fd6b5da767211952
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Tue Jan 30 03:50:01 2018 -0500

    media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
    
    commit 181a4a2d5a0a7b43cab08a70710d727e7764ccdd upstream.
    
    If the ioctl returned -ENOTTY, then don't bother copying
    back the result as there is no point.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1113a74590b4597c0d5104bf9f653cc4daad9daf
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Wed Jan 24 08:28:10 2018 -0500

    media: v4l2-ioctl.c: use check_fmt for enum/g/s/try_fmt
    
    commit b2469c814fbc8f1f19676dd4912717b798df511e upstream.
    
    Don't duplicate the buffer type checks in enum/g/s/try_fmt.
    The check_fmt function does that already.
    
    It is hard to keep the checks in sync for all these functions and
    in fact the check for VBI was wrong in the _fmt functions as it
    allowed SDR types as well. This caused a v4l2-compliance failure
    for /dev/swradio0 using vivid.
    
    This simplifies the code and keeps the check in one place and
    fixes the SDR/VBI bug.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46e8d06e423c4f35eac7a8b677b713b3ec9b0684
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:27 2018 -0800

    crypto: hash - prevent using keyed hashes without setting key
    
    commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream.
    
    Currently, almost none of the keyed hash algorithms check whether a key
    has been set before proceeding.  Some algorithms are okay with this and
    will effectively just use a key of all 0's or some other bogus default.
    However, others will severely break, as demonstrated using
    "hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
    via a (potentially exploitable) stack buffer overflow.
    
    A while ago, this problem was solved for AF_ALG by pairing each hash
    transform with a 'has_key' bool.  However, there are still other places
    in the kernel where userspace can specify an arbitrary hash algorithm by
    name, and the kernel uses it as unkeyed hash without checking whether it
    is really unkeyed.  Examples of this include:
    
        - KEYCTL_DH_COMPUTE, via the KDF extension
        - dm-verity
        - dm-crypt, via the ESSIV support
        - dm-integrity, via the "internal hash" mode with no key given
        - drbd (Distributed Replicated Block Device)
    
    This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
    privileges to call.
    
    Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
    ->crt_flags of each hash transform that indicates whether the transform
    still needs to be keyed or not.  Then, make the hash init, import, and
    digest functions return -ENOKEY if the key is still needed.
    
    The new flag also replaces the 'has_key' bool which algif_hash was
    previously using, thereby simplifying the algif_hash implementation.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cec606a62e0124689331ccb367a845ee1f34110e
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:26 2018 -0800

    crypto: hash - annotate algorithms taking optional key
    
    commit a208fa8f33031b9e0aba44c7d1b7e68eb0cbd29e upstream.
    
    We need to consistently enforce that keyed hashes cannot be used without
    setting the key.  To do this we need a reliable way to determine whether
    a given hash algorithm is keyed or not.  AF_ALG currently does this by
    checking for the presence of a ->setkey() method.  However, this is
    actually slightly broken because the CRC-32 algorithms implement
    ->setkey() but can also be used without a key.  (The CRC-32 "key" is not
    actually a cryptographic key but rather represents the initial state.
    If not overridden, then a default initial state is used.)
    
    Prepare to fix this by introducing a flag CRYPTO_ALG_OPTIONAL_KEY which
    indicates that the algorithm has a ->setkey() method, but it is not
    required to be called.  Then set it on all the CRC-32 algorithms.
    
    The same also applies to the Adler-32 implementation in Lustre.
    
    Also, the cryptd and mcryptd templates have to pass through the flag
    from their underlying algorithm.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5e994037f37e9e8b8ecfc43d6ef8a93f52633e5
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:25 2018 -0800

    crypto: poly1305 - remove ->setkey() method
    
    commit a16e772e664b9a261424107784804cffc8894977 upstream.
    
    Since Poly1305 requires a nonce per invocation, the Linux kernel
    implementations of Poly1305 don't use the crypto API's keying mechanism
    and instead expect the key and nonce as the first 32 bytes of the data.
    But ->setkey() is still defined as a stub returning an error code.  This
    prevents Poly1305 from being used through AF_ALG and will also break it
    completely once we start enforcing that all crypto API users (not just
    AF_ALG) call ->setkey() if present.
    
    Fix it by removing crypto_poly1305_setkey(), leaving ->setkey as NULL.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3b6f7d313afb083acec85f3ff513b4daf0d56d6
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:24 2018 -0800

    crypto: mcryptd - pass through absence of ->setkey()
    
    commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
    
    When the mcryptd template is used to wrap an unkeyed hash algorithm,
    don't install a ->setkey() method to the mcryptd instance.  This change
    is necessary for mcryptd to keep working with unkeyed hash algorithms
    once we start enforcing that ->setkey() is called when present.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f034d24fcef862d0fa12adcee1e5817c9ade8f7e
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:23 2018 -0800

    crypto: cryptd - pass through absence of ->setkey()
    
    commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
    
    When the cryptd template is used to wrap an unkeyed hash algorithm,
    don't install a ->setkey() method to the cryptd instance.  This change
    is necessary for cryptd to keep working with unkeyed hash algorithms
    once we start enforcing that ->setkey() is called when present.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 927a0dd1c4de3ec57e8d1194bd0383ca757162eb
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:22 2018 -0800

    crypto: hash - introduce crypto_hash_alg_has_setkey()
    
    commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
    
    Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
    to determine whether the underlying algorithm requires a key or not.
    But there was no corresponding function for ahash spawns.  Add it.
    
    Note that the new function actually has to support both shash and ahash
    algorithms, since the ahash API can be used with either.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d53f47c224c1adac6975d630d155da8927818b84
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Jan 11 15:55:50 2018 +0300

    ahci: Add Intel Cannon Lake PCH-H PCI ID
    
    commit f919dde0772a894c693a1eeabc77df69d6a9b937 upstream.
    
    Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers.
    
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd3b3e9b0520a1c41c65d0196d1d3cc4f1429e87
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Dec 6 16:41:09 2017 +0100

    ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
    
    commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
    
    Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
    SATA controllers. This commit is a preparation patch for allowing a
    different default sata link powermanagement policy for mobile chipsets.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d714ff5114589432ede4c7ab5eb8e3aaf9219b7e
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Dec 6 16:41:08 2017 +0100

    ahci: Annotate PCI ids for mobile Intel chipsets as such
    
    commit ca1b4974bd237f2373b0e980b11957aac3499b56 upstream.
    
    Intel uses different SATA PCI ids for the Desktop and Mobile SKUs of their
    chipsets. For older models the comment describing which chipset the PCI id
    is for, aksi indicates when we're dealing with a mobile SKU. Extend the
    comments for recent chipsets to also indicate mobile SKUs.
    
    The information this commit adds comes from Intel's chipset datasheets.
    
    This commit is a preparation patch for allowing a different default
    sata link powermanagement policy for mobile chipsets.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d94a30179cad987694a23a6442d27efaed5fa9e
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Fri Jan 19 09:18:54 2018 +0100

    kernfs: fix regression in kernfs_fop_write caused by wrong type
    
    commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
    
    Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
    kernfs_open_file") changes type of local variable 'len' from ssize_t
    to size_t. This change caused that the *ppos value is updated also
    when the previous write callback failed.
    
    Mentioned snippet:
    ...
    len = ops->write(...); <- return value can be negative
    ...
    if (len > 0)           <- true here in this case
            *ppos += len;
    ...
    
    Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e61f8b07b5795f93f45c437f26fa48ed48b538c
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Fri Jan 12 17:42:30 2018 -0500

    nfsd: Detect unhashed stids in nfsd4_verify_open_stid()
    
    commit 4f1764172a0aa7395d12b96cae640ca1438c5085 upstream.
    
    The state of the stid is guaranteed by 2 locks:
    - The nfs4_client 'cl_lock' spinlock
    - The nfs4_ol_stateid 'st_mutex' mutex
    
    so it is quite possible for the stid to be unhashed after lookup,
    but before calling nfsd4_lock_ol_stateid(). So we do need to check
    for a zero value for 'sc_type' in nfsd4_verify_open_stid().
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Tested-by: Checuk Lever <chuck.lever@oracle.com>
    Fixes: 659aefb68eca "nfsd: Ensure we don't recognise lock stateids..."
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 782b4e79ceaaf787b0fc05ee5fac7017f5c0a997
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sun Jan 28 09:29:41 2018 -0500

    NFS: Fix a race between mmap() and O_DIRECT
    
    commit e231c6879cfd44e4fffd384bb6dd7d313249a523 upstream.
    
    When locking the file in order to do O_DIRECT on it, we must unmap
    any mmapped ranges on the pagecache so that we can flush out the
    dirty data.
    
    Fixes: a5864c999de67 ("NFS: Do not serialise O_DIRECT reads and writes")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0645878a34d02aeb55aaccd9ba6fe0b39b55f83a
Author: Eric Biggers <ebiggers@google.com>
Date:   Fri Jan 19 15:15:34 2018 -0800

    NFS: reject request for id_legacy key without auxdata
    
    commit 49686cbbb3ebafe42e63868222f269d8053ead00 upstream.
    
    nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
    to a 'struct idmap', via the call to request_key_with_auxdata() in
    nfs_idmap_request_key().
    
    However it can also be reached via the request_key() system call in
    which case 'aux' will be NULL, causing a NULL pointer dereference in
    nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
    valid enough to get that far.
    
    Fix this by making nfs_idmap_legacy_upcall() negate the key if no
    auxdata is provided.
    
    As usual, this bug was found by syzkaller.  A simple reproducer using
    the command-line keyctl program is:
    
        keyctl request2 id_legacy uid:0 '' @s
    
    Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
    Reported-by: syzbot+5dfdbcf7b3eb5912abbb@syzkaller.appspotmail.com
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Trond Myklebust <trondmy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60af9d47409cc57fd61b13a95de27981abfa773c
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jan 16 10:08:00 2018 -0500

    NFS: commit direct writes even if they fail partially
    
    commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 upstream.
    
    If some of the WRITE calls making up an O_DIRECT write syscall fail,
    we neglect to commit, even if some of the WRITEs succeed.
    
    We also depend on the commit code to free the reference count on the
    nfs_page taken in the "if (request_commit)" case at the end of
    nfs_direct_write_completion().  The problem was originally noticed
    because ENOSPC's encountered partway through a write would result in a
    closed file being sillyrenamed when it should have been unlinked.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d301c957fafe2bdc59c75efb56ea663b7cdab4c
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Jan 6 09:53:49 2018 -0500

    NFS: Fix nfsstat breakage due to LOOKUPP
    
    commit 8634ef5e05311f32d7f2aee06f6b27a8834a3bd6 upstream.
    
    The LOOKUPP operation was inserted into the nfs4_procedures array
    rather than being appended, which put /proc/net/rpc/nfs out of
    whack, and broke the nfsstat utility.
    Fix by moving the LOOKUPP operation to the end of the array, and
    by ensuring that it keeps the same length whether or not NFSV4.1
    and NFSv4.2 are compiled in.
    
    Fixes: 5b5faaf6df734 ("nfs4: add NFSv4 LOOKUPP handlers")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09f453630a5cd33af480e4b8aa62e98e35dae20e
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Mon Dec 18 14:39:13 2017 -0500

    NFS: Add a cond_resched() to nfs_commit_release_pages()
    
    commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
    
    The commit list can get very large, and so we need a cond_resched()
    in nfs_commit_release_pages() in order to ensure we don't hog the CPU
    for excessive periods of time.
    
    Reported-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4be335576ecabc281ddc688a2057aca5bf6a4fd4
Author: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Date:   Tue Jan 16 22:38:50 2018 +0100

    nfs41: do not return ENOMEM on LAYOUTUNAVAILABLE
    
    commit 7ff4cff637aa0bd2abbd81f53b2a6206c50afd95 upstream.
    
    A pNFS server may return LAYOUTUNAVAILABLE error on LAYOUTGET for files
    which don't have any layout. In this situation pnfs_update_layout
    currently returns NULL. As this NULL is converted into ENOMEM, IO
    requests fails instead of falling back to MDS.
    
    Do not return ENOMEM on LAYOUTUNAVAILABLE and let client retry through
    MDS.
    
    Fixes 8d40b0f14846f. I will suggest to backport this fix to affected
    stable branches.
    
    Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
    [trondmy: Use IS_ERR_OR_NULL()]
    Fixes: 8d40b0f14846 ("NFS filelayout:call GETDEVICEINFO after...")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2a7f7a32d709c35744e5efee89c95cf31ef6f51
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Fri Dec 15 16:12:32 2017 -0500

    nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
    
    commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream.
    
    Currently when falling back to doing I/O through the MDS (via
    pnfs_{read|write}_through_mds), the client frees the nfs_pgio_header
    without releasing the reference taken on the dreq
    via pnfs_generic_pg_{read|write}pages -> nfs_pgheader_init ->
    nfs_direct_pgio_init.  It then takes another reference on the dreq via
    nfs_generic_pg_pgios -> nfs_pgheader_init -> nfs_direct_pgio_init and
    as a result the requester will become stuck in inode_dio_wait.  Once
    that happens, other processes accessing the inode will become stuck as
    well.
    
    Ensure that pnfs_read_through_mds() and pnfs_write_through_mds() clean
    up correctly by calling hdr->completion_ops->completion() instead of
    calling hdr->release() directly.
    
    This can be reproduced (sometimes) by performing "storage failover
    takeover" commands on NetApp filer while doing direct I/O from a client.
    
    This can also be reproduced using SystemTap to simulate a failure while
    doing direct I/O from a client (from Dave Wysochanski
    <dwysocha@redhat.com>):
    
    stap -v -g -e 'probe module("nfs_layout_nfsv41_files").function("nfs4_fl_prepare_ds").return { $return=NULL; exit(); }'
    
    Suggested-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Scott Mayhew <smayhew@redhat.com>
    Fixes: 1ca018d28d ("pNFS: Fix a memory leak when attempted pnfs fails")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79fca845f0e420a8dbd1c9712d652a054f8dd5a3
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Jan 11 23:27:00 2018 -0500

    ubifs: free the encrypted symlink target
    
    commit 6b46d444146eb8d0b99562795cea8086639d7282 upstream.
    
    ubifs_symlink() forgot to free the kmalloc()'ed buffer holding the
    encrypted symlink target, creating a memory leak.  Fix it.
    
    (UBIFS could actually encrypt directly into ui->data, removing the
    temporary buffer, but that is left for the patch that switches to use
    the symlink helper functions.)
    
    Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 973f83fab1b1034643abadafab4d83683349a717
Author: Bradley Bolen <bradleybolen@gmail.com>
Date:   Thu Jan 18 08:55:20 2018 -0500

    ubi: block: Fix locking for idr_alloc/idr_remove
    
    commit 7f29ae9f977bcdc3654e68bc36d170223c52fd48 upstream.
    
    This fixes a race with idr_alloc where gd->first_minor can be set to the
    same value for two simultaneous calls to ubiblock_create.  Each instance
    calls device_add_disk with the same first_minor.  device_add_disk calls
    bdi_register_owner which generates several warnings.
    
    WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
    sysfs_warn_dup+0x68/0x88
    sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2'
    
    WARNING: CPU: 1 PID: 179 at kernel-source/lib/kobject.c:240
    kobject_add_internal+0x1ec/0x2f8
    kobject_add_internal failed for 252:2 with -EEXIST, don't try to
    register things with the same name in the same directory
    
    WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
    sysfs_warn_dup+0x68/0x88
    sysfs: cannot create duplicate filename '/dev/block/252:2'
    
    However, device_add_disk does not error out when bdi_register_owner
    returns an error.  Control continues until reaching blk_register_queue.
    It then BUGs.
    
    kernel BUG at kernel-source/fs/sysfs/group.c:113!
    [<c01e26cc>] (internal_create_group) from [<c01e2950>]
    (sysfs_create_group+0x20/0x24)
    [<c01e2950>] (sysfs_create_group) from [<c00e3d38>]
    (blk_trace_init_sysfs+0x18/0x20)
    [<c00e3d38>] (blk_trace_init_sysfs) from [<c02bdfbc>]
    (blk_register_queue+0xd8/0x154)
    [<c02bdfbc>] (blk_register_queue) from [<c02cec84>]
    (device_add_disk+0x194/0x44c)
    [<c02cec84>] (device_add_disk) from [<c0436ec8>]
    (ubiblock_create+0x284/0x2e0)
    [<c0436ec8>] (ubiblock_create) from [<c0427bb8>]
    (vol_cdev_ioctl+0x450/0x554)
    [<c0427bb8>] (vol_cdev_ioctl) from [<c0189110>] (vfs_ioctl+0x30/0x44)
    [<c0189110>] (vfs_ioctl) from [<c01892e0>] (do_vfs_ioctl+0xa0/0x790)
    [<c01892e0>] (do_vfs_ioctl) from [<c0189a14>] (SyS_ioctl+0x44/0x68)
    [<c0189a14>] (SyS_ioctl) from [<c0010640>] (ret_fast_syscall+0x0/0x34)
    
    Locking idr_alloc/idr_remove removes the race and keeps gd->first_minor
    unique.
    
    Fixes: 2bf50d42f3a4 ("UBI: block: Dynamically allocate minor numbers")
    Signed-off-by: Bradley Bolen <bradleybolen@gmail.com>
    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 155e260ffa1475b4b02cbcdccbe249ab0e137b01
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Tue Dec 5 16:01:20 2017 +0100

    ubi: fastmap: Erase outdated anchor PEBs during attach
    
    commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c upstream.
    
    The fastmap update code might erase the current fastmap anchor PEB
    in case it doesn't find any new free PEB. When a power cut happens
    in this situation we must not have any outdated fastmap anchor PEB
    on the device, because that would be used to attach during next
    boot.
    The easiest way to make that sure is to erase all outdated fastmap
    anchor PEBs synchronously during attach.
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Reviewed-by: Richard Weinberger <richard@nod.at>
    Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85f7a399a3721701574f5923d16f0492236cb53b
Author: Clay McClure <clay@daemons.net>
Date:   Thu Sep 21 19:01:34 2017 -0700

    ubi: Fix race condition between ubi volume creation and udev
    
    commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream.
    
    Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
    device creation and udev"), we should make the volume active before
    registering it.
    
    Signed-off-by: Clay McClure <clay@daemons.net>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edb72dea6d46baeeb78d0359d2e6da0fe8c51d4d
Author: Miquel Raynal <miquel.raynal@free-electrons.com>
Date:   Wed Jan 24 23:49:31 2018 +0100

    mtd: nand: sunxi: Fix ECC strength choice
    
    commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 upstream.
    
    When the requested ECC strength does not exactly match the strengths
    supported by the ECC engine, the driver is selecting the closest
    strength meeting the 'selected_strength > requested_strength'
    constraint. Fix the fact that, in this particular case, ecc->strength
    value was not updated to match the 'selected_strength'.
    
    For instance, one can encounter this issue when no ECC requirement is
    filled in the device tree while the NAND chip minimum requirement is not
    a strength/step_size combo natively supported by the ECC engine.
    
    Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
    Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed538bc15951b77320ed6af6d1867a00274365e8
Author: Miquel Raynal <miquel.raynal@free-electrons.com>
Date:   Fri Jan 12 10:13:36 2018 +0100

    mtd: nand: Fix nand_do_read_oob() return value
    
    commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
    
    Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
    OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
    negative error, and the MTD layer expected it.
    
    However, the trend for the NAND layer is now to return an error or a
    positive number of bitflips. Deciding which status to return to the user
    belongs to the MTD layer.
    
    Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
    brought this logic to the mtd_read_oob() function while the return value
    coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
    left unchanged.
    
    Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
    Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b39c718d1a37c3bad79b9bfe3d7556ae23b9444c
Author: Kamal Dasu <kdasu.kdev@gmail.com>
Date:   Mon Jan 8 15:36:48 2018 -0500

    mtd: nand: brcmnand: Disable prefetch by default
    
    commit f953f0f89663c39f08f4baaa8a4a881401b65654 upstream.
    
    Brcm nand controller prefetch feature needs to be disabled
    by default. Enabling affects performance on random reads as
    well as dma reads.
    
    Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
    Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ea0377d0dcc71d177d8b3984fc6f44ce8083fb4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 11 15:54:10 2017 +0200

    mtd: cfi: convert inline functions to macros
    
    commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream.
    
    The map_word_() functions, dating back to linux-2.6.8, try to perform
    bitwise operations on a 'map_word' structure. This may have worked
    with compilers that were current then (gcc-3.4 or earlier), but end
    up being rather inefficient on any version I could try now (gcc-4.4 or
    higher). Specifically we hit a problem analyzed in gcc PR81715 where we
    fail to reuse the stack space for local variables.
    
    This can be seen immediately in the stack consumption for
    cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
    can be up to 2200 bytes. Changing the inline functions into macros brings
    this down to 1280 bytes.  Without KASAN, the same problem exists, but
    the stack consumption is lower to start with, my patch shrinks it from
    920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
    1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
    structures for each call to one of these helpers.
    
    With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
    but nobody uses that yet, so we should still work around it in mainline
    kernels and probably backport the workaround to stable kernels as well.
    We had a couple of other functions that suffered from the same gcc bug,
    and all of those had a simpler workaround involving dummy variables
    in the inline function. Unfortunately that did not work here, the
    macro hack was the best I could come up with.
    
    It would also be helpful to have someone to a little performance testing
    on the patch, to see how much it helps in terms of CPU utilitzation.
    
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d60ada32f9c19391626398fa8325e139b5dd05dc
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:21 2018 +0000

    arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
    
    
    Commit 3a0a397ff5ff upstream.
    
    Now that we've standardised on SMCCC v1.1 to perform the branch
    prediction invalidation, let's drop the previous band-aid.
    If vendors haven't updated their firmware to do SMCCC 1.1, they
    haven't updated PSCI either, so we don't loose anything.
    
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e301ef8189389349042709bff62dc7185e8ae02a
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:20 2018 +0000

    arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
    
    
    Commit b092201e0020 upstream.
    
    Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.
    It is lovely. Really.
    
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b3173cc081843424b14cd3626c7a88095cca550
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:19 2018 +0000

    arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
    
    
    Commit f2d3b2e8759a upstream.
    
    One of the major improvement of SMCCC v1.1 is that it only clobbers
    the first 4 registers, both on 32 and 64bit. This means that it
    becomes very easy to provide an inline version of the SMC call
    primitive, and avoid performing a function call to stash the
    registers that would otherwise be clobbered by SMCCC v1.0.
    
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fa82723fa1b35fcf37914925cb25783529653eb
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:18 2018 +0000

    arm/arm64: smccc: Make function identifiers an unsigned quantity
    
    
    Commit ded4c39e93f3 upstream.
    
    Function identifiers are a 32bit, unsigned quantity. But we never
    tell so to the compiler, resulting in the following:
    
     4ac:   b26187e0        mov     x0, #0xffffffff80000001
    
    We thus rely on the firmware narrowing it for us, which is not
    always a reasonable expectation.
    
    Cc: stable@vger.kernel.org
    Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eadba98b0dd90bb9e5a814115907cc00b4a8c590
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:17 2018 +0000

    firmware/psci: Expose SMCCC version through psci_ops
    
    
    Commit e78eef554a91 upstream.
    
    Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
    let's do that at boot time, and expose the version of the calling
    convention as part of the psci_ops structure.
    
    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5195a21d5ba08161710364147141a8376e18d154
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:16 2018 +0000

    firmware/psci: Expose PSCI conduit
    
    
    Commit 09a8d6d48499 upstream.
    
    In order to call into the firmware to apply workarounds, it is
    useful to find out whether we're using HVC or SMC. Let's expose
    this through the psci_ops.
    
    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a345e5e87310a898696806705a0f054be2aae09
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:15 2018 +0000

    arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
    
    
    Commit f72af90c3783 upstream.
    
    We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible.
    So let's intercept it as early as we can by testing for the
    function call number as soon as we've identified a HVC call
    coming from the guest.
    
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a1b576877dd7bb0f7bc647bb7770d7cb7b97151
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:14 2018 +0000

    arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support
    
    
    Commit 6167ec5c9145 upstream.
    
    A new feature of SMCCC 1.1 is that it offers firmware-based CPU
    workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides
    BP hardening for CVE-2017-5715.
    
    If the host has some mitigation for this issue, report that
    we deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the
    host workaround on every guest exit.
    
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    
    Conflicts:
            arch/arm/include/asm/kvm_host.h
            arch/arm64/include/asm/kvm_host.h
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b423ee888290c2524087875bf229844be0daf32
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:13 2018 +0000

    arm/arm64: KVM: Turn kvm_psci_version into a static inline
    
    
    Commit a4097b351118 upstream.
    
    We're about to need kvm_psci_version in HYP too. So let's turn it
    into a static inline, and pass the kvm structure as a second
    parameter (so that HYP can do a kern_hyp_va on it).
    
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d18561857b799de49ba70859d29c858226b579ef
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Wed Jan 3 16:38:37 2018 +0000

    arm64: KVM: Make PSCI_VERSION a fast path
    
    
    Commit 90348689d500 upstream.
    
    For those CPUs that require PSCI to perform a BP invalidation,
    going all the way to the PSCI code for not much is a waste of
    precious cycles. Let's terminate that call as early as possible.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68894ca72b4d0fed30a4d3296acb63e001bab864
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:12 2018 +0000

    arm/arm64: KVM: Advertise SMCCC v1.1
    
    
    Commit 09e6be12effd upstream.
    
    The new SMC Calling Convention (v1.1) allows for a reduced overhead
    when calling into the firmware, and provides a new feature discovery
    mechanism.
    
    Make it visible to KVM guests.
    
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9aecea071f020a8b9f1696ea1fa66f0d44cd9210
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:11 2018 +0000

    arm/arm64: KVM: Implement PSCI 1.0 support
    
    
    Commit 58e0b2239a4d upstream.
    
    PSCI 1.0 can be trivially implemented by providing the FEATURES
    call on top of PSCI 0.2 and returning 1.0 as the PSCI version.
    
    We happily ignore everything else, as they are either optional or
    are clarifications that do not require any additional change.
    
    PSCI 1.0 is now the default until we decide to add a userspace
    selection API.
    
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfc67e088515ff5c1214ec28361eea7e9dd6e41a
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:10 2018 +0000

    arm/arm64: KVM: Add smccc accessors to PSCI code
    
    
    Commit 84684fecd7ea upstream.
    
    Instead of open coding the accesses to the various registers,
    let's add explicit SMCCC accessors.
    
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 038a0579029deee98ab6801e48a305b1507bc60f
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:09 2018 +0000

    arm/arm64: KVM: Add PSCI_VERSION helper
    
    
    Commit d0a144f12a7c upstream.
    
    As we're about to trigger a PSCI version explosion, it doesn't
    hurt to introduce a PSCI_VERSION helper that is going to be
    used everywhere.
    
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf9708a5df1e945d19ab431e785d810d8de72e6d
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:08 2018 +0000

    arm/arm64: KVM: Consolidate the PSCI include files
    
    
    Commit 1a2fb94e6a77 upstream.
    
    As we're about to update the PSCI support, and because I'm lazy,
    let's move the PSCI include file to include/kvm so that both
    ARM architectures can find it.
    
    Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2843529c774c0a65a617f3b6aa25e514a189f8f
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Feb 6 17:56:07 2018 +0000

    arm64: KVM: Increment PC after handling an SMC trap
    
    
    Commit f5115e8869e1 upstream.
    
    When handling an SMC trap, the "preferred return address" is set
    to that of the SMC, and not the next PC (which is a departure from
    the behaviour of an SMC that isn't trapped).
    
    Increment PC in the handler, as the guest is otherwise forever
    stuck...
    
    Cc: stable@vger.kernel.org
    Fixes: acfb3b883f6d ("arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls")
    Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2458a525a4a91f3ae7fd80c3871622707bedf8b9
Author: Jayachandran C <jnair@caviumnetworks.com>
Date:   Fri Jan 19 04:22:47 2018 -0800

    arm64: Branch predictor hardening for Cavium ThunderX2
    
    
    Commit f3d795d9b360 upstream.
    
    Use PSCI based mitigation for speculative execution attacks targeting
    the branch predictor. We use the same mechanism as the one used for
    Cortex-A CPUs, we expect the PSCI version call to have a side effect
    of clearing the BTBs.
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2a40a765e317a75dcd1fb864dabc3d584009e9b
Author: Shanker Donthineni <shankerd@codeaurora.org>
Date:   Fri Jan 5 14:28:59 2018 -0600

    arm64: Implement branch predictor hardening for Falkor
    
    
    Commit ec82b567a74f upstream.
    
    Falkor is susceptible to branch predictor aliasing and can
    theoretically be attacked by malicious code. This patch
    implements a mitigation for these attacks, preventing any
    malicious entries from affecting other victim contexts.
    
    Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
    [will: fix label name when !CONFIG_KVM and remove references to MIDR_FALKOR]
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5152c0c11ccc0e72536c358493fc929bbe4caaf5
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Jan 3 12:46:21 2018 +0000

    arm64: Implement branch predictor hardening for affected Cortex-A CPUs
    
    
    Commit aa6acde65e03 upstream.
    
    Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
    and can theoretically be attacked by malicious code.
    
    This patch implements a PSCI-based mitigation for these CPUs when available.
    The call into firmware will invalidate the branch predictor state, preventing
    any malicious entries from affecting other victim contexts.
    
    Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df65d7b1c194d946f37006573d63e7bef8169eea
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Jan 3 11:19:34 2018 +0000

    arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75
    
    
    Commit a65d219fe5dc upstream.
    
    Hook up MIDR values for the Cortex-A72 and Cortex-A75 CPUs, since they
    will soon need MIDR matches for hardening the branch predictor.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40ad0b937384e4b1c48539557443f4a8f1bc0848
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Feb 2 17:31:40 2018 +0000

    arm64: entry: Apply BP hardening for suspicious interrupts from EL0
    
    
    Commit 30d88c0e3ace upstream.
    
    It is possible to take an IRQ from EL0 following a branch to a kernel
    address in such a way that the IRQ is prioritised over the instruction
    abort. Whilst an attacker would need to get the stars to align here,
    it might be sufficient with enough calibration so perform BP hardening
    in the rare case that we see a kernel address in the ELR when handling
    an IRQ from EL0.
    
    Reported-by: Dan Hettena <dhettena@nvidia.com>
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9444427e9f43132642120fb9104b911cda5c5d8b
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Feb 2 17:31:39 2018 +0000

    arm64: entry: Apply BP hardening for high-priority synchronous exceptions
    
    
    Commit 5dfc6ed27710 upstream.
    
    Software-step and PC alignment fault exceptions have higher priority than
    instruction abort exceptions, so apply the BP hardening hooks there too
    if the user PC appears to reside in kernel space.
    
    Reported-by: Dan Hettena <dhettena@nvidia.com>
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a7a2f40da4a334a379c7a4fc472a15e9d04104d
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Wed Jan 3 16:38:35 2018 +0000

    arm64: KVM: Use per-CPU vector when BP hardening is enabled
    
    
    Commit 6840bdd73d07 upstream.
    
    Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    
    Conflicts:
            arch/arm/include/asm/kvm_mmu.h
            arch/arm64/include/asm/kvm_mmu.h
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c2108a2db4914af9e22e53cbc83c49fc42ac472
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Fri Jan 19 15:42:09 2018 +0000

    arm64: Move BP hardening to check_and_switch_context
    
    
    Commit a8e4c0a919ae upstream.
    
    We call arm64_apply_bp_hardening() from post_ttbr_update_workaround,
    which has the unexpected consequence of being triggered on every
    exception return to userspace when ARM64_SW_TTBR0_PAN is selected,
    even if no context switch actually occured.
    
    This is a bit suboptimal, and it would be more logical to only
    invalidate the branch predictor when we actually switch to
    a different mm.
    
    In order to solve this, move the call to arm64_apply_bp_hardening()
    into check_and_switch_context(), where we're guaranteed to pick
    a different mm context.
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24f07bba953d16d61929e410bc6c351903af913c
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Jan 3 11:17:58 2018 +0000

    arm64: Add skeleton to harden the branch predictor against aliasing attacks
    
    
    Commit 0f15adbb2861 upstream.
    
    Aliasing attacks against CPU branch predictors can allow an attacker to
    redirect speculative control flow on some CPUs and potentially divulge
    information from one context to another.
    
    This patch adds initial skeleton code behind a new Kconfig option to
    enable implementation-specific mitigations against these attacks for
    CPUs that are affected.
    
    Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    
    Conflicts:
            arch/arm64/kernel/cpufeature.c
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8b634e69ce37e5ab375bfbaa2e5eb6fb05609b9
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Jan 2 18:19:39 2018 +0000

    arm64: Move post_ttbr_update_workaround to C code
    
    
    Commit 95e3de3590e3 upstream.
    
    We will soon need to invoke a CPU-specific function pointer after changing
    page tables, so move post_ttbr_update_workaround out into C code to make
    this possible.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    
    Conflicts:
            arch/arm64/include/asm/assembler.h
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f26eef7f2416abd79002341d2df0f8fbc068c38
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Jan 2 21:45:41 2018 +0000

    drivers/firmware: Expose psci_get_version through psci_ops structure
    
    
    Commit d68e3ba5303f upstream.
    
    Entry into recent versions of ARM Trusted Firmware will invalidate the CPU
    branch predictor state in order to protect against aliasing attacks.
    
    This patch exposes the PSCI "VERSION" function via psci_ops, so that it
    can be invoked outside of the PSCI driver where necessary.
    
    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4506169a1e1e33e5c0be6732a70b5dc3815ba5ad
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Jan 2 21:37:25 2018 +0000

    arm64: cpufeature: Pass capability structure to ->enable callback
    
    
    Commit 0a0d111d40fd upstream.
    
    In order to invoke the CPU capability ->matches callback from the ->enable
    callback for applying local-CPU workarounds, we need a handle on the
    capability structure.
    
    This patch passes a pointer to the capability structure to the ->enable
    callback.
    
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e780011c8fde3ae5e21c63cb879d80fae81f77c
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Wed Jan 17 17:42:20 2018 +0000

    arm64: Run enable method for errata work arounds on late CPUs
    
    
    Commit 55b35d070c25 upstream.
    
    When a CPU is brought up after we have finalised the system
    wide capabilities (i.e, features and errata), we make sure the
    new CPU doesn't need a new errata work around which has not been
    detected already. However we don't run enable() method on the new
    CPU for the errata work arounds already detected. This could
    cause the new CPU running without potential work arounds.
    It is upto the "enable()" method to decide if this CPU should
    do something about the errata.
    
    Fixes: commit 6a6efbb45b7d95c84 ("arm64: Verify CPU errata work arounds on hotplugged CPU")
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Andre Przywara <andre.przywara@arm.com>
    Cc: Dave Martin <dave.martin@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68330fdd469b7b9157e4bcd5b48986c2e4ed5815
Author: James Morse <james.morse@arm.com>
Date:   Mon Jan 15 19:38:54 2018 +0000

    arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early
    
    
    Commit edf298cfce47 upstream.
    
    this_cpu_has_cap() tests caps->desc not caps->matches, so it stops
    walking the list when it finds a 'silent' feature, instead of
    walking to the end of the list.
    
    Prior to v4.6's 644c2ae198412 ("arm64: cpufeature: Test 'matches' pointer
    to find the end of the list") we always tested desc to find the end of
    a capability list. This was changed for dubious things like PAN_NOT_UAO.
    v4.7's e3661b128e53e ("arm64: Allow a capability to be checked on
    single CPU") added this_cpu_has_cap() using the old desc style test.
    
    CC: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 835662c5bd55e9065b3049c4651f967aceff398c
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Feb 5 15:34:24 2018 +0000

    arm64: futex: Mask __user pointers prior to dereference
    
    
    Commit 91b2d3442f6a upstream.
    
    The arm64 futex code has some explicit dereferencing of user pointers
    where performing atomic operations in response to a futex command. This
    patch uses masking to limit any speculative futex operations to within
    the user address space.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15814374752a7ccede3684d9ad93081bfe201400
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Feb 5 15:34:23 2018 +0000

    arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user
    
    
    Commit f71c2ffcb20d upstream.
    
    Like we've done for get_user and put_user, ensure that user pointers
    are masked before invoking the underlying __arch_{clear,copy_*}_user
    operations.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ca9d1c25789aa2f345458529244d78c307856c9
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Feb 5 15:34:22 2018 +0000

    arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user
    
    
    Commit 84624087dd7e upstream.
    
    access_ok isn't an expensive operation once the addr_limit for the current
    thread has been loaded into the cache. Given that the initial access_ok
    check preceding a sequence of __{get,put}_user operations will take
    the brunt of the miss, we can make the __* variants identical to the
    full-fat versions, which brings with it the benefits of address masking.
    
    The likely cost in these sequences will be from toggling PAN/UAO, which
    we can address later by implementing the *_unsafe versions.
    
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e11038f4c1c7aae4e7467efbe347322958233c4b
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Feb 5 15:34:21 2018 +0000

    arm64: uaccess: Prevent speculative use of the current addr_limit
    
    
    Commit c2f0ad4fc089 upstream.
    
    A mispredicted conditional call to set_fs could result in the wrong
    addr_limit being forwarded under speculation to a subsequent access_ok
    check, potentially forming part of a spectre-v1 attack using uaccess
    routines.
    
    This patch prevents this forwarding from taking place, but putting heavy
    barriers in set_fs after writing the addr_limit.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf6df3266a9149cca2cf95787558cacd6483da88
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Feb 5 15:34:20 2018 +0000

    arm64: entry: Ensure branch through syscall table is bounded under speculation
    
    
    Commit 6314d90e6493 upstream.
    
    In a similar manner to array_index_mask_nospec, this patch introduces an
    assembly macro (mask_nospec64) which can be used to bound a value under
    speculation. This macro is then used to ensure that the indirect branch
    through the syscall table is bounded under speculation, with out-of-range
    addresses speculating as calls to sys_io_setup (0).
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d4e58257ef53a3c05f7355a1898cb91fe812c5a
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon Feb 5 15:34:19 2018 +0000

    arm64: Use pointer masking to limit uaccess speculation
    
    
    Commit 4d8efc2d5ee4 upstream.
    
    Similarly to x86, mitigate speculation past an access_ok() check by
    masking the pointer against the address limit before use.
    
    Even if we don't expect speculative writes per se, it is plausible that
    a CPU may still speculate at least as far as fetching a cache line for
    writing, hence we also harden put_user() and clear_user() for peace of
    mind.
    
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a8a65a284c8a8693ae700fbdf2c1a90533a0a48
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon Feb 5 15:34:18 2018 +0000

    arm64: Make USER_DS an inclusive limit
    
    
    Commit 51369e398d0d upstream.
    
    Currently, USER_DS represents an exclusive limit while KERNEL_DS is
    inclusive. In order to do some clever trickery for speculation-safe
    masking, we need them both to behave equivalently - there aren't enough
    bits to make KERNEL_DS exclusive, so we have precisely one option. This
    also happens to correct a longstanding false negative for a range
    ending on the very top byte of kernel memory.
    
    Mark Rutland points out that we've actually got the semantics of
    addresses vs. segments muddled up in most of the places we need to
    amend, so shuffle the {USER,KERNEL}_DS definitions around such that we
    can correct those properly instead of just pasting "-1"s everywhere.
    
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a17d329d36c81ccdc1cba58ac765dacbbac7d33b
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon Feb 5 15:34:17 2018 +0000

    arm64: Implement array_index_mask_nospec()
    
    
    Commit 022620eed3d0 upstream.
    
    Provide an optimised, assembly implementation of array_index_mask_nospec()
    for arm64 so that the compiler is not in a position to transform the code
    in ways which affect its ability to inhibit speculation (e.g. by introducing
    conditional branches).
    
    This is similar to the sequence used by x86, modulo architectural differences
    in the carry/borrow flags.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83c5e4e3c63489bc6aa0aa4f9082786e4c2d0d28
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Feb 5 15:34:16 2018 +0000

    arm64: barrier: Add CSDB macros to control data-value prediction
    
    
    Commit 669474e772b9 upstream.
    
    For CPUs capable of data value prediction, CSDB waits for any outstanding
    predictions to architecturally resolve before allowing speculative execution
    to continue. Provide macros to expose it to the arch code.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    
    Conflicts:
            arch/arm64/include/asm/assembler.h
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed6cfd54cc9bde19f19ee15b660712ba99a2e8cf
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Nov 27 15:49:53 2017 +0000

    perf: arm_spe: Fail device probe when arm64_kernel_unmapped_at_el0()
    
    
    Commit 7a4a0c1555b8 upstream.
    
    When running with the kernel unmapped whilst at EL0, the virtually-addressed
    SPE buffer is also unmapped, which can lead to buffer faults if userspace
    profiling is enabled and potentially also when writing back kernel samples
    unless an expensive drain operation is performed on exception return.
    
    For now, fail the SPE driver probe when arm64_kernel_unmapped_at_el0().
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eefd900d3450b9eb08d48519928dc7ea6d942b6a
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 29 12:00:00 2018 +0000

    arm64: idmap: Use "awx" flags for .idmap.text .pushsection directives
    
    
    Commit 439e70e27a51 upstream.
    
    The identity map is mapped as both writeable and executable by the
    SWAPPER_MM_MMUFLAGS and this is relied upon by the kpti code to manage
    a synchronisation flag. Update the .pushsection flags to reflect the
    actual mapping attributes.
    
    Reported-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b87b5ce113e1fe1c97b6a589ccc0f591d39287bd
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 29 11:59:58 2018 +0000

    arm64: entry: Reword comment about post_ttbr_update_workaround
    
    
    Commit f167211a93ac upstream.
    
    We don't fully understand the Cavium ThunderX erratum, but it appears
    that mapping the kernel as nG can lead to horrible consequences such as
    attempting to execute userspace from kernel context. Since kpti isn't
    enabled for these CPUs anyway, simplify the comment justifying the lack
    of post_ttbr_update_workaround in the exception trampoline.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccb60ecfe8782db3f72289ac78ee23579372fa42
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Mon Jan 29 11:59:56 2018 +0000

    arm64: Force KPTI to be disabled on Cavium ThunderX
    
    
    Commit 6dc52b15c4a4 upstream.
    
    Cavium ThunderX's erratum 27456 results in a corruption of icache
    entries that are loaded from memory that is mapped as non-global
    (i.e. ASID-tagged).
    
    As KPTI is based on memory being mapped non-global, let's prevent
    it from kicking in if this erratum is detected.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    [will: Update comment]
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 173358a4917308f10e35d317c4aa51870d1a1409
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Feb 6 22:22:50 2018 +0000

    arm64: kpti: Add ->enable callback to remap swapper using nG mappings
    
    
    Commit f992b4dfd58b upstream.
    
    Defaulting to global mappings for kernel space is generally good for
    performance and appears to be necessary for Cavium ThunderX. If we
    subsequently decide that we need to enable kpti, then we need to rewrite
    our existing page table entries to be non-global. This is fiddly, and
    made worse by the possible use of contiguous mappings, which require
    a strict break-before-make sequence.
    
    Since the enable callback runs on each online CPU from stop_machine
    context, we can have all CPUs enter the idmap, where secondaries can
    wait for the primary CPU to rewrite swapper with its MMU off. It's all
    fairly horrible, but at least it only runs once.
    
    Tested-by: Marc Zyngier <marc.zyngier@arm.com>
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Conflicts:
            arch/arm64/mm/proc.S
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e41ebd20f592d5d603966968d0edd20cb719df5
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 29 11:59:54 2018 +0000

    arm64: mm: Permit transitioning from Global to Non-Global without BBM
    
    
    Commit 4e6020565596 upstream.
    
    Break-before-make is not needed when transitioning from Global to
    Non-Global mappings, provided that the contiguous hint is not being used.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fb3a06fb8218335d59686192a1eb3ecb664ec1f
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Jan 29 11:59:53 2018 +0000

    arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0()
    
    
    Commit 41acec624087 upstream.
    
    To allow systems which do not require kpti to continue running with
    global kernel mappings (which appears to be a requirement for Cavium
    ThunderX due to a CPU erratum), make the use of nG in the kernel page
    tables dependent on arm64_kernel_unmapped_at_el0(), which is resolved
    at runtime.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56e4bdb0a3e9270bd373bf676dc5f160db33dbad
Author: Jayachandran C <jnair@caviumnetworks.com>
Date:   Fri Jan 19 04:22:48 2018 -0800

    arm64: Turn on KPTI only on CPUs that need it
    
    
    Commit 0ba2e29c7fc1 upstream.
    
    Whitelist Broadcom Vulcan/Cavium ThunderX2 processors in
    unmap_kernel_at_el0(). These CPUs are not vulnerable to
    CVE-2017-5754 and do not need KPTI when KASLR is off.
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb132ae43a2a0e8c86134cb12bd13c56837150d1
Author: Jayachandran C <jnair@caviumnetworks.com>
Date:   Sun Jan 7 22:53:35 2018 -0800

    arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs
    
    
    Commit 0d90718871fe upstream.
    
    Add the older Broadcom ID as well as the new Cavium ID for ThunderX2
    CPUs.
    
    Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7a062e77db3af4973188853de2f1c27ee08bf7a
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Wed Jan 10 13:18:30 2018 +0000

    arm64: kpti: Fix the interaction between ASID switching and software PAN
    
    
    Commit 6b88a32c7af6 upstream.
    
    With ARM64_SW_TTBR0_PAN enabled, the exception entry code checks the
    active ASID to decide whether user access was enabled (non-zero ASID)
    when the exception was taken. On return from exception, if user access
    was previously disabled, it re-instates TTBR0_EL1 from the per-thread
    saved value (updated in switch_mm() or efi_set_pgd()).
    
    Commit 7655abb95386 ("arm64: mm: Move ASID from TTBR0 to TTBR1") makes a
    TTBR0_EL1 + ASID switching non-atomic. Subsequently, commit 27a921e75711
    ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN") changes the
    __uaccess_ttbr0_disable() function and asm macro to first write the
    reserved TTBR0_EL1 followed by the ASID=0 update in TTBR1_EL1. If an
    exception occurs between these two, the exception return code will
    re-instate a valid TTBR0_EL1. Similar scenario can happen in
    cpu_switch_mm() between setting the reserved TTBR0_EL1 and the ASID
    update in cpu_do_switch_mm().
    
    This patch reverts the entry.S check for ASID == 0 to TTBR0_EL1 and
    disables the interrupts around the TTBR0_EL1 and ASID switching code in
    __uaccess_ttbr0_disable(). It also ensures that, when returning from the
    EFI runtime services, efi_set_pgd() doesn't leave a non-zero ASID in
    TTBR1_EL1 by using uaccess_ttbr0_{enable,disable}.
    
    The accesses to current_thread_info()->ttbr0 are updated to use
    READ_ONCE/WRITE_ONCE.
    
    As a safety measure, __uaccess_ttbr0_enable() always masks out any
    existing non-zero ASID TTBR1_EL1 before writing in the new ASID.
    
    Fixes: 27a921e75711 ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN")
    Acked-by: Will Deacon <will.deacon@arm.com>
    Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: James Morse <james.morse@arm.com>
    Tested-by: James Morse <james.morse@arm.com>
    Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    
    Conflicts:
            arch/arm64/include/asm/asm-uaccess.h
            arch/arm64/include/asm/uaccess.h
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7036e5f6774e8bfefc5f3f5c452195a48cef8b26
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Dec 1 17:33:48 2017 +0000

    arm64: mm: Introduce TTBR_ASID_MASK for getting at the ASID in the TTBR
    
    
    Commit b519538dfefc upstream.
    
    There are now a handful of open-coded masks to extract the ASID from a
    TTBR value, so introduce a TTBR_ASID_MASK and use that instead.
    
    Suggested-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0b74ca82f28c42c219737152648bf2dd196ffa6
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Tue Jan 9 16:12:18 2018 +0000

    arm64: capabilities: Handle duplicate entries for a capability
    
    
    Commit 67948af41f2e upstream.
    
    Sometimes a single capability could be listed multiple times with
    differing matches(), e.g, CPU errata for different MIDR versions.
    This breaks verify_local_cpu_feature() and this_cpu_has_cap() as
    we stop checking for a capability on a CPU with the first
    entry in the given table, which is not sufficient. Make sure we
    run the checks for all entries of the same capability. We do
    this by fixing __this_cpu_has_cap() to run through all the
    entries in the given table for a match and reuse it for
    verify_local_cpu_feature().
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f39015ae7127cab5113c7698a2d95b81e942c67f
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Nov 27 18:29:30 2017 +0000

    arm64: Take into account ID_AA64PFR0_EL1.CSV3
    
    
    Commit 179a56f6f9fb upstream.
    
    For non-KASLR kernels where the KPTI behaviour has not been overridden
    on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
    or not we should unmap the kernel whilst running at EL0.
    
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    
    Conflicts:
            arch/arm64/kernel/cpufeature.c
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14a756c2fda06bed7225e52473fbb683629e8488
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 16:19:39 2017 +0000

    arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry
    
    
    Commit 0617052ddde3 upstream.
    
    Although CONFIG_UNMAP_KERNEL_AT_EL0 does make KASLR more robust, it's
    actually more useful as a mitigation against speculation attacks that
    can leak arbitrary kernel data to userspace through speculation.
    
    Reword the Kconfig help message to reflect this, and make the option
    depend on EXPERT so that it is on by default for the majority of users.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c17f836255da1d574dd661379d7ac8afad105b0
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:41:01 2017 +0000

    arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0
    
    
    Commit 084eb77cd3a8 upstream.
    
    Add a Kconfig entry to control use of the entry trampoline, which allows
    us to unmap the kernel whilst running in userspace and improve the
    robustness of KASLR.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit feace1c8f6eb780adf8d5b6608186a0a76363f6f
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 16:15:59 2017 +0000

    arm64: use RET instruction for exiting the trampoline
    
    
    Commit be04a6d1126b upstream.
    
    Speculation attacks against the entry trampoline can potentially resteer
    the speculative instruction stream through the indirect branch and into
    arbitrary gadgets within the kernel.
    
    This patch defends against these attacks by forcing a misprediction
    through the return stack: a dummy BL instruction loads an entry into
    the stack, so that the predicted program flow of the subsequent RET
    instruction is to a branch-to-self instruction which is finally resolved
    as a branch to the kernel vectors with speculation suppressed.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6eac605e710376012e19cf9d5c11a3432cbcb7d7
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Dec 6 11:24:02 2017 +0000

    arm64: kaslr: Put kernel vectors address in separate data page
    
    
    Commit 6c27c4082f4f upstream.
    
    The literal pool entry for identifying the vectors base is the only piece
    of information in the trampoline page that identifies the true location
    of the kernel.
    
    This patch moves it into a page-aligned region of the .rodata section
    and maps this adjacent to the trampoline text via an additional fixmap
    entry, which protects against any accidental leakage of the trampoline
    contents.
    
    Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 064607a4fd292402d20e1450c4e3dab0a8ee93f7
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:38:19 2017 +0000

    arm64: entry: Add fake CPU feature for unmapping the kernel at EL0
    
    
    Commit ea1e3de85e94 upstream.
    
    Allow explicit disabling of the entry trampoline on the kernel command
    line (kpti=off) by adding a fake CPU feature (ARM64_UNMAP_KERNEL_AT_EL0)
    that can be used to toggle the alternative sequences in our entry code and
    avoid use of the trampoline altogether if desired. This also allows us to
    make use of a static key in arm64_kernel_unmapped_at_el0().
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b5deee12ce7d0010838daf29c1c1a109af75715
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:33:28 2017 +0000

    arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks
    
    
    Commit 18011eac28c7 upstream.
    
    When unmapping the kernel at EL0, we use tpidrro_el0 as a scratch register
    during exception entry from native tasks and subsequently zero it in
    the kernel_ventry macro. We can therefore avoid zeroing tpidrro_el0
    in the context-switch path for native tasks using the entry trampoline.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5ed8761f80154414b4d259381d3997c9b6edb4f
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Wed Dec 13 14:19:37 2017 -0800

    arm64: cpu_errata: Add Kryo to Falkor 1003 errata
    
    
    Commit bb48711800e6 upstream.
    
    The Kryo CPUs are also affected by the Falkor 1003 errata, so
    we need to do the same workaround on Kryo CPUs. The MIDR is
    slightly more complicated here, where the PART number is not
    always the same when looking at all the bits from 15 to 4. Drop
    the lower 8 bits and just look at the top 4 to see if it's '2'
    and then consider those as Kryo CPUs. This covers all the
    combinations without having to list them all out.
    
    Fixes: 38fd94b0275c ("arm64: Work around Falkor erratum 1003")
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    
    Conflicts:
            arch/arm64/include/asm/cputype.h
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26ce07109300b3d3a5930da4552a6fdc878bb468
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:29:19 2017 +0000

    arm64: erratum: Work around Falkor erratum #E1003 in trampoline code
    
    
    Commit d1777e686ad1 upstream.
    
    We rely on an atomic swizzling of TTBR1 when transitioning from the entry
    trampoline to the kernel proper on an exception. We can't rely on this
    atomicity in the face of Falkor erratum #E1003, so on affected cores we
    can issue a TLB invalidation to invalidate the walk cache prior to
    jumping into the kernel. There is still the possibility of a TLB conflict
    here due to conflicting walk cache entries prior to the invalidation, but
    this doesn't appear to be the case on these CPUs in practice.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89685f858b8fdfc7d8337733e4a9637cdf39e899
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:24:29 2017 +0000

    arm64: entry: Hook up entry trampoline to exception vectors
    
    
    Commit 4bf3286d29f3 upstream.
    
    Hook up the entry trampoline to our exception vectors so that all
    exceptions from and returns to EL0 go via the trampoline, which swizzles
    the vector base register accordingly. Transitioning to and from the
    kernel clobbers x30, so we use tpidrro_el0 and far_el1 as scratch
    registers for native tasks.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3117e455eee98d544add11cf9ddd7ad0e48abb98
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:20:21 2017 +0000

    arm64: entry: Explicitly pass exception level to kernel_ventry macro
    
    
    Commit 5b1f7fe41909 upstream.
    
    We will need to treat exceptions from EL0 differently in kernel_ventry,
    so rework the macro to take the exception level as an argument and
    construct the branch target using that.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f14b03dde8c71f0072a7fb4029723f932c4723f
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:14:17 2017 +0000

    arm64: mm: Map entry trampoline into trampoline and kernel page tables
    
    
    Commit 51a0048beb44 upstream.
    
    The exception entry trampoline needs to be mapped at the same virtual
    address in both the trampoline page table (which maps nothing else)
    and also the kernel page table, so that we can swizzle TTBR1_EL1 on
    exceptions from and return to EL0.
    
    This patch maps the trampoline at a fixed virtual address in the fixmap
    area of the kernel virtual address space, which allows the kernel proper
    to be randomized with respect to the trampoline when KASLR is enabled.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1f8eeab0e787cd29d4993ee231876c651baff5e
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 14:07:40 2017 +0000

    arm64: entry: Add exception trampoline page for exceptions from EL0
    
    
    Commit c7b9adaf85f8 upstream.
    
    To allow unmapping of the kernel whilst running at EL0, we need to
    point the exception vectors at an entry trampoline that can map/unmap
    the kernel on entry/exit respectively.
    
    This patch adds the trampoline page, although it is not yet plugged
    into the vector table and is therefore unused.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 392bb3ba68656dd53d7da3c9517baeed28b8088f
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 14:13:33 2017 +0100

    arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI
    
    
    Commit 9b0de864b5bc upstream.
    
    Since an mm has both a kernel and a user ASID, we need to ensure that
    broadcast TLB maintenance targets both address spaces so that things
    like CoW continue to work with the uaccess primitives in the kernel.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68e3fee6ea5c77ca58cd6616a7fe67f00f63254f
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Nov 14 13:58:08 2017 +0000

    arm64: mm: Add arm64_kernel_unmapped_at_el0 helper
    
    
    Commit fc0e1299da54 upstream.
    
    In order for code such as TLB invalidation to operate efficiently when
    the decision to map the kernel at EL0 is determined at runtime, this
    patch introduces a helper function, arm64_kernel_unmapped_at_el0, to
    determine whether or not the kernel is mapped whilst running in userspace.
    
    Currently, this just reports the value of CONFIG_UNMAP_KERNEL_AT_EL0,
    but will later be hooked up to a fake CPU capability using a static key.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75802ca67d6b1a07c355e1034a5f2f756c4a66d0
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 14:10:28 2017 +0100

    arm64: mm: Allocate ASIDs in pairs
    
    
    Commit 0c8ea531b774 upstream.
    
    In preparation for separate kernel/user ASIDs, allocate them in pairs
    for each mm_struct. The bottom bit distinguishes the two: if it is set,
    then the ASID will map only userspace.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c3ad6e6b8277d9e78e26628718b76425fc37291
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 13:58:16 2017 +0100

    arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN
    
    
    Commit 27a921e75711 upstream.
    
    With the ASID now installed in TTBR1, we can re-enable ARM64_SW_TTBR0_PAN
    by ensuring that we switch to a reserved ASID of zero when disabling
    user access and restore the active user ASID on the uaccess enable path.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc29c581cdf3422179033382d73b9dfd24bad4ec
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 13:34:30 2017 +0100

    arm64: mm: Rename post_ttbr0_update_workaround
    
    
    Commit 158d495899ce upstream.
    
    The post_ttbr0_update_workaround hook applies to any change to TTBRx_EL1.
    Since we're using TTBR1 for the ASID, rename the hook to make it clearer
    as to what it's doing.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5b604c97b91fe0a90ea28a042d02507d26844a7
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 13:29:06 2017 +0100

    arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003
    
    
    Commit 85d13c001497 upstream.
    
    The pre_ttbr0_update_workaround hook is called prior to context-switching
    TTBR0 because Falkor erratum E1003 can cause TLB allocation with the wrong
    ASID if both the ASID and the base address of the TTBR are updated at
    the same time.
    
    With the ASID sitting safely in TTBR1, we no longer update things
    atomically, so we can remove the pre_ttbr0_update_workaround macro as
    it's no longer required. The erratum infrastructure and documentation
    is left around for #E1003, as it will be required by the entry
    trampoline code in a future patch.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9586273ff1f88f73ab3882dfadedbe8e6f2a84b1
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 13:19:09 2017 +0100

    arm64: mm: Move ASID from TTBR0 to TTBR1
    
    
    Commit 7655abb95386 upstream.
    
    In preparation for mapping kernelspace and userspace with different
    ASIDs, move the ASID to TTBR1 and update switch_mm to context-switch
    TTBR0 via an invalid mapping (the zero page).
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c8c2e969339aaee1833ba2f48467552c7593a72
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 13:04:48 2017 +0100

    arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN
    
    
    Commit 376133b7edc2 upstream.
    
    We're about to rework the way ASIDs are allocated, switch_mm is
    implemented and low-level kernel entry/exit is handled, so keep the
    ARM64_SW_TTBR0_PAN code out of the way whilst we do the heavy lifting.
    
    It will be re-enabled in a subsequent patch.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 541214369fcbffa229dc9ded75415295b94a3fa7
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 10 12:56:18 2017 +0100

    arm64: mm: Use non-global mappings for kernel space
    
    
    Commit e046eb0c9bf2 upstream.
    
    In preparation for unmapping the kernel whilst running in userspace,
    make the kernel mappings non-global so we can avoid expensive TLB
    invalidation on kernel exit to userspace.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Laura Abbott <labbott@redhat.com>
    Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2eeaddcc139b5ccf1784148e08c7f2f57ec2c998
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Fri Sep 22 09:07:06 2017 -0400

    media: hdpvr: Fix an error handling path in hdpvr_probe()
    
    commit c0f71bbb810237a38734607ca4599632f7f5d47f upstream.
    
    Here, hdpvr_register_videodev() is responsible for setup and
    register a video device. Also defining and initializing a worker.
    hdpvr_register_videodev() is calling by hdpvr_probe at last.
    So no need to flush any work here.
    Unregister v4l2, free buffers and memory. If hdpvr_probe() will fail.
    
    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d1073cfbe7886710ae622305edcd2af5e48f885
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Tue Sep 26 17:10:21 2017 -0400

    media: dvb-usb-v2: lmedm04: move ts2020 attach to dm04_lme2510_tuner
    
    commit 7bf7a7116ed313c601307f7e585419369926ab05 upstream.
    
    When the tuner was split from m88rs2000 the attach function is in wrong
    place.
    
    Move to dm04_lme2510_tuner to trap errors on failure and removing
    a call to lme_coldreset.
    
    Prevents driver starting up without any tuner connected.
    
    Fixes to trap for ts2020 fail.
    LME2510(C): FE Found M88RS2000
    ts2020: probe of 0-0060 failed with error -11
    ...
    LME2510(C): TUN Found RS2000 tuner
    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20f3bae5957e3c0843e71a6564e3dbd040b7f469
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Tue Sep 26 17:10:20 2017 -0400

    media: dvb-usb-v2: lmedm04: Improve logic checking of warm start
    
    commit 3d932ee27e852e4904647f15b64dedca51187ad7 upstream.
    
    Warm start has no check as whether a genuine device has
    connected and proceeds to next execution path.
    
    Check device should read 0x47 at offset of 2 on USB descriptor read
    and it is the amount requested of 6 bytes.
    
    Fix for
    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access as
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 410179dfc2b8a491425aa10e5e720d8f19e02cd8
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Jan 23 20:45:38 2018 -0500

    sched/rt: Up the root domain ref count when passing it around via IPIs
    
    commit 364f56653708ba8bcdefd4f0da2a42904baa8eeb upstream.
    
    When issuing an IPI RT push, where an IPI is sent to each CPU that has more
    than one RT task scheduled on it, it references the root domain's rto_mask,
    that contains all the CPUs within the root domain that has more than one RT
    task in the runable state. The problem is, after the IPIs are initiated, the
    rq->lock is released. This means that the root domain that is associated to
    the run queue could be freed while the IPIs are going around.
    
    Add a sched_get_rd() and a sched_put_rd() that will increment and decrement
    the root domain's ref count respectively. This way when initiating the IPIs,
    the scheduler will up the root domain's ref count before releasing the
    rq->lock, ensuring that the root domain does not go away until the IPI round
    is complete.
    
    Reported-by: Pavan Kondeti <pkondeti@codeaurora.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
    Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtNA@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74adee6d7b791a5b55650cb1613eef9dc3e309a9
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Jan 23 20:45:37 2018 -0500

    sched/rt: Use container_of() to get root domain in rto_push_irq_work_func()
    
    commit ad0f1d9d65938aec72a698116cd73a980916895e upstream.
    
    When the rto_push_irq_work_func() is called, it looks at the RT overloaded
    bitmask in the root domain via the runqueue (rq->rd). The problem is that
    during CPU up and down, nothing here stops rq->rd from changing between
    taking the rq->rd->rto_lock and releasing it. That means the lock that is
    released is not the same lock that was taken.
    
    Instead of using this_rq()->rd to get the root domain, as the irq work is
    part of the root domain, we can simply get the root domain from the irq work
    that is passed to the routine:
    
     container_of(work, struct root_domain, rto_push_work)
    
    This keeps the root domain consistent.
    
    Reported-by: Pavan Kondeti <pkondeti@codeaurora.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
    Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtNA@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8709b63f2ebc9231cce8153ee63e5ce3e54508af
Author: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Date:   Mon Jan 29 08:33:46 2018 +0000

    Revert "drm/i915: mark all device info struct with __initconst"
    
    commit b5a756a722286af9702d565501e1f690d075d16b upstream.
    
    This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e.
    
     Conflicts:
            drivers/gpu/drm/i915/i915_pci.c
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805
    Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with __initconst")
    Link: https://patchwork.freedesktop.org/patch/msgid/20180129083346.29173-1-lionel.g.landwerlin@intel.com
    (cherry picked from commit 5db47e37b38755c5e26e6b8fbc1a32ce73495940)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Cc: Ozkan Sezer <sezeroz@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf8b6ada9508d9663e2ee2db8203a575a1a78293
Author: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date:   Thu Nov 9 14:39:55 2017 +0100

    watchdog: gpio_wdt: set WDOG_HW_RUNNING in gpio_wdt_stop
    
    commit bc137dfdbec27c0ec5731a89002daded4a4aa1ea upstream.
    
    The first patch above (https://patchwork.kernel.org/patch/9970181/)
    makes the oops go away, but it just papers over the problem. The real
    problem is that the watchdog core clears WDOG_HW_RUNNING in
    watchdog_stop, and the gpio driver fails to set it in its stop
    function when it doesn't actually stop it. This means that the core
    doesn't know that it now has responsibility for petting the device, in
    turn causing the device to reset the system (I hadn't noticed this
    because the board I'm working on has that reset logic disabled).
    
    How about this (other drivers may of course have the same problem, I
    haven't checked). One might say that ->stop should return an error
    when the device can't be stopped, but OTOH this brings parity between
    a device without a ->stop method and a GPIO wd that has always-running
    set. IOW, I think ->stop should only return an error when an actual
    attempt to stop the hardware failed.
    
    From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    
    The watchdog framework clears WDOG_HW_RUNNING before calling
    ->stop. If the driver is unable to stop the device, it is supposed to
    set that bit again so that the watchdog core takes care of sending
    heart-beats while the device is not open from user-space. Update the
    gpio_wdt driver to honour that contract (and get rid of the redundant
    clearing of WDOG_HW_RUNNING).
    
    Fixes: 3c10bbde10 ("watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function")
    Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5577da97bd3f64cc4b72407d837e917761db9772
Author: Sven Joachim <svenjoac@gmx.de>
Date:   Fri Jan 26 10:38:01 2018 +0100

    ssb: Do not disable PCI host on non-Mips
    
    commit a9e6d44ddeccd3522670e641f1ed9b068e746ff7 upstream.
    
    After upgrading an old laptop to 4.15-rc9, I found that the eth0 and
    wlan0 interfaces had disappeared.  It turns out that the b43 and b44
    drivers require SSB_PCIHOST_POSSIBLE which depends on
    PCI_DRIVERS_LEGACY, a config option that only exists on Mips.
    
    Fixes: 58eae1416b80 ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC")
    Signed-off-by: Sven Joachim <svenjoac@gmx.de>
    Reviewed-by: James Hogan <jhogan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a52b839c8d658208d6e4c2bb7c87b4b70dffed7e
Author: Yang Shunyong <shunyong.yang@hxt-semitech.com>
Date:   Mon Jan 29 14:40:11 2018 +0800

    dmaengine: dmatest: fix container_of member in dmatest_callback
    
    commit 66b3bd2356e0a1531c71a3dcf96944621e25c17c upstream.
    
    The type of arg passed to dmatest_callback is struct dmatest_done.
    It refers to test_done in struct dmatest_thread, not done_wait.
    
    Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
    Signed-off-by: Yang Shunyong <shunyong.yang@hxt-semitech.com>
    Acked-by: Adam Wallis <awallis@codeaurora.org>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76eac767a85be22059dae2792673880e182d21c4
Author: Andrew-sh Cheng <andrew-sh.cheng@mediatek.com>
Date:   Fri Dec 8 14:07:56 2017 +0800

    cpufreq: mediatek: add mediatek related projects into blacklist
    
    commit 6066998cbd2b1012a8d5bc9a2957cfd0ad53150e upstream.
    
    mediatek projects will use mediate-cpufreq.c as cpufreq driver,
    instead of using cpufreq_dt.c
    Add mediatek related projects into cpufreq-dt blacklist
    
    Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng@mediatek.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cb0b894e128284586531f087371347e083a1f65
Author: Aurelien Aptel <aaptel@suse.com>
Date:   Thu Jan 25 15:59:39 2018 +0100

    CIFS: zero sensitive data when freeing
    
    commit 97f4b7276b829a8927ac903a119bef2f963ccc58 upstream.
    
    also replaces memset()+kfree() by kzfree().
    
    Signed-off-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44fe87e83650ff1f87aa7d28e65ece0d3abbd18a
Author: Daniel N Pettersson <danielnp@axis.com>
Date:   Thu Jan 11 16:00:12 2018 +0100

    cifs: Fix autonegotiate security settings mismatch
    
    commit 9aca7e454415f7878b28524e76bebe1170911a88 upstream.
    
    Autonegotiation gives a security settings mismatch error if the SMB
    server selects an SMBv3 dialect that isn't SMB3.02. The exact error is
    "protocol revalidation - security settings mismatch".
    This can be tested using Samba v4.2 or by setting the global Samba
    setting max protocol = SMB3_00.
    
    The check that fails in smb3_validate_negotiate is the dialect
    verification of the negotiate info response. This is because it tries
    to verify against the protocol_id in the global smbdefault_values. The
    protocol_id in smbdefault_values is SMB3.02.
    In SMB2_negotiate the protocol_id in smbdefault_values isn't updated,
    it is global so it probably shouldn't be, but server->dialect is.
    
    This patch changes the check in smb3_validate_negotiate to use
    server->dialect instead of server->vals->protocol_id. The patch works
    with autonegotiate and when using a specific version in the vers mount
    option.
    
    Signed-off-by: Daniel N Pettersson <danielnp@axis.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0f967b072c973823dc6fe6737475d5b6d55b4da
Author: Matthew Wilcox <mawilcox@microsoft.com>
Date:   Fri Dec 15 12:48:32 2017 -0800

    cifs: Fix missing put_xid in cifs_file_strict_mmap
    
    commit f04a703c3d613845ae3141bfaf223489de8ab3eb upstream.
    
    If cifs_zap_mapping() returned an error, we would return without putting
    the xid that we got earlier.  Restructure cifs_file_strict_mmap() and
    cifs_file_mmap() to be more similar to each other and have a single
    point of return that always puts the xid.
    
    Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4fb3fda25d6935a78ec4ed57b89a299e238c917
Author: Matt Redfearn <matt.redfearn@mips.com>
Date:   Tue Nov 14 10:52:54 2017 +0000

    watchdog: indydog: Add dependency on SGI_HAS_INDYDOG
    
    commit 24f8d233074badd4c18e4dafd2fb97d65838afed upstream.
    
    Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
    enabled building the Indy watchdog driver when COMPILE_TEST is enabled.
    However, the driver makes reference to symbols that are only defined for
    certain platforms are selected in the config. These platforms select
    SGI_HAS_INDYDOG. Without this, link time errors result, for example
    when building a MIPS allyesconfig.
    
    drivers/watchdog/indydog.o: In function `indydog_write':
    indydog.c:(.text+0x18): undefined reference to `sgimc'
    indydog.c:(.text+0x1c): undefined reference to `sgimc'
    drivers/watchdog/indydog.o: In function `indydog_start':
    indydog.c:(.text+0x54): undefined reference to `sgimc'
    indydog.c:(.text+0x58): undefined reference to `sgimc'
    drivers/watchdog/indydog.o: In function `indydog_stop':
    indydog.c:(.text+0xa4): undefined reference to `sgimc'
    drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined
    references to `sgimc' follow
    make: *** [Makefile:1005: vmlinux] Error 1
    
    Fix this by ensuring that CONFIG_INDIDOG can only be selected when the
    necessary dependent platform symbols are built in.
    
    Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
    Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Suggested-by: James Hogan <james.hogan@mips.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>