commit d0b1397a9aac7a77c95fed5ea02ef35c29279915
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 9 12:15:13 2018 +0200

    Linux 4.17.14

commit 2972e3f6816c7dc0d4804ae82a3d02ffb94068dc
Author: Shankara Pailoor <shankarapailoor@gmail.com>
Date:   Tue Jun 5 08:33:27 2018 -0500

    jfs: Fix inconsistency between memory allocation and ea_buf->max_size
    
    commit 92d34134193e5b129dc24f8d79cb9196626e8d7a upstream.
    
    The code is assuming the buffer is max_size length, but we weren't
    allocating enough space for it.
    
    Signed-off-by: Shankara Pailoor <shankarapailoor@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39dc3fb32fd4bf0fde9e8c971dec8228722f0a70
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue Apr 17 17:17:34 2018 -0700

    xfs: validate cached inodes are free when allocated
    
    commit afca6c5b2595fc44383919fba740c194b0b76aff upstream.
    
    A recent fuzzed filesystem image cached random dcache corruption
    when the reproducer was run. This often showed up as panics in
    lookup_slow() on a null inode->i_ops pointer when doing pathwalks.
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    ....
    Call Trace:
     lookup_slow+0x44/0x60
     walk_component+0x3dd/0x9f0
     link_path_walk+0x4a7/0x830
     path_lookupat+0xc1/0x470
     filename_lookup+0x129/0x270
     user_path_at_empty+0x36/0x40
     path_listxattr+0x98/0x110
     SyS_listxattr+0x13/0x20
     do_syscall_64+0xf5/0x280
     entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    but had many different failure modes including deadlocks trying to
    lock the inode that was just allocated or KASAN reports of
    use-after-free violations.
    
    The cause of the problem was a corrupt INOBT on a v4 fs where the
    root inode was marked as free in the inobt record. Hence when we
    allocated an inode, it chose the root inode to allocate, found it in
    the cache and re-initialised it.
    
    We recently fixed a similar inode allocation issue caused by inobt
    record corruption problem in xfs_iget_cache_miss() in commit
    ee457001ed6c ("xfs: catch inode allocation state mismatch
    corruption"). This change adds similar checks to the cache-hit path
    to catch it, and turns the reproducer into a corruption shutdown
    situation.
    
    Reported-by: Wen Xu <wen.xu@gatech.edu>
    Signed-Off-By: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    [darrick: fix typos in comment]
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Cc: Eduardo Valentin <eduval@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 173f00f40107e5099eb8a74ea7b7ff0e662ec80b
Author: Eric Sandeen <sandeen@sandeen.net>
Date:   Fri Jun 8 09:53:49 2018 -0700

    xfs: don't call xfs_da_shrink_inode with NULL bp
    
    commit bb3d48dcf86a97dc25fe9fc2c11938e19cb4399a upstream.
    
    xfs_attr3_leaf_create may have errored out before instantiating a buffer,
    for example if the blkno is out of range.  In that case there is no work
    to do to remove it, and in fact xfs_da_shrink_inode will lead to an oops
    if we try.
    
    This also seems to fix a flaw where the original error from
    xfs_attr3_leaf_create gets overwritten in the cleanup case, and it
    removes a pointless assignment to bp which isn't used after this.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199969
    Reported-by: Xu, Wen <wen.xu@gatech.edu>
    Tested-by: Xu, Wen <wen.xu@gatech.edu>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Cc: Eduardo Valentin <eduval@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9c16a87da687ee730032d564764da9b506fcf90
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Aug 3 12:22:09 2018 -0700

    Partially revert "block: fail op_is_write() requests to read-only partitions"
    
    commit a32e236eb93e62a0f692e79b7c3c9636689559b9 upstream.
    
    It turns out that commit 721c7fc701c7 ("block: fail op_is_write()
    requests to read-only partitions"), while obviously correct, causes
    problems for some older lvm2 installations.
    
    The reason is that the lvm snapshotting will continue to write to the
    snapshow COW volume, even after the volume has been marked read-only.
    End result: snapshot failure.
    
    This has actually been fixed in newer version of the lvm2 tool, but the
    old tools still exist, and the breakage was reported both in the kernel
    bugzilla and in the Debian bugzilla:
    
      https://bugzilla.kernel.org/show_bug.cgi?id=200439
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900442
    
    The lvm2 fix is here
    
      https://sourceware.org/git/?p=lvm2.git;a=commit;h=a6fdb9d9d70f51c49ad11a87ab4243344e6701a3
    
    but until everybody has updated to recent versions, we'll have to weaken
    the "never write to read-only partitions" check.  It now allows the
    write to happen, but causes a warning, something like this:
    
      generic_make_request: Trying to write to read-only block-device dm-3 (partno X)
      Modules linked in: nf_tables xt_cgroup xt_owner kvm_intel iwlmvm kvm irqbypass iwlwifi
      CPU: 1 PID: 77 Comm: kworker/1:1 Not tainted 4.17.9-gentoo #3
      Hardware name: LENOVO 20B6A019RT/20B6A019RT, BIOS GJET91WW (2.41 ) 09/21/2016
      Workqueue: ksnaphd do_metadata
      RIP: 0010:generic_make_request_checks+0x4ac/0x600
      ...
      Call Trace:
       generic_make_request+0x64/0x400
       submit_bio+0x6c/0x140
       dispatch_io+0x287/0x430
       sync_io+0xc3/0x120
       dm_io+0x1f8/0x220
       do_metadata+0x1d/0x30
       process_one_work+0x1b9/0x3e0
       worker_thread+0x2b/0x3c0
       kthread+0x113/0x130
       ret_from_fork+0x35/0x40
    
    Note that this is a "revert" in behavior only.  I'm leaving alone the
    actual code cleanups in commit 721c7fc701c7, but letting the previously
    uncaught request go through with a warning instead of stopping it.
    
    Fixes: 721c7fc701c7 ("block: fail op_is_write() requests to read-only partitions")
    Reported-and-tested-by: WGH <wgh@torlan.ru>
    Acked-by: Mike Snitzer <snitzer@redhat.com>
    Cc: Sagi Grimberg <sagi@grimberg.me>
    Cc: Ilya Dryomov <idryomov@gmail.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Zdenek Kabelac <zkabelac@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 288e990ae129def6d0ff3c9ac6b8de4552482024
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jul 12 01:36:43 2018 +0100

    Btrfs: fix file data corruption after cloning a range and fsync
    
    commit bd3599a0e142cd73edd3b6801068ac3f48ac771a upstream.
    
    When we clone a range into a file we can end up dropping existing
    extent maps (or trimming them) and replacing them with new ones if the
    range to be cloned overlaps with a range in the destination inode.
    When that happens we add the new extent maps to the list of modified
    extents in the inode's extent map tree, so that a "fast" fsync (the flag
    BTRFS_INODE_NEEDS_FULL_SYNC not set in the inode) will see the extent maps
    and log corresponding extent items. However, at the end of range cloning
    operation we do truncate all the pages in the affected range (in order to
    ensure future reads will not get stale data). Sometimes this truncation
    will release the corresponding extent maps besides the pages from the page
    cache. If this happens, then a "fast" fsync operation will miss logging
    some extent items, because it relies exclusively on the extent maps being
    present in the inode's extent tree, leading to data loss/corruption if
    the fsync ends up using the same transaction used by the clone operation
    (that transaction was not committed in the meanwhile). An extent map is
    released through the callback btrfs_invalidatepage(), which gets called by
    truncate_inode_pages_range(), and it calls __btrfs_releasepage(). The
    later ends up calling try_release_extent_mapping() which will release the
    extent map if some conditions are met, like the file size being greater
    than 16Mb, gfp flags allow blocking and the range not being locked (which
    is the case during the clone operation) nor being the extent map flagged
    as pinned (also the case for cloning).
    
    The following example, turned into a test for fstests, reproduces the
    issue:
    
      $ mkfs.btrfs -f /dev/sdb
      $ mount /dev/sdb /mnt
    
      $ xfs_io -f -c "pwrite -S 0x18 9000K 6908K" /mnt/foo
      $ xfs_io -f -c "pwrite -S 0x20 2572K 156K" /mnt/bar
    
      $ xfs_io -c "fsync" /mnt/bar
      # reflink destination offset corresponds to the size of file bar,
      # 2728Kb minus 4Kb.
      $ xfs_io -c ""reflink ${SCRATCH_MNT}/foo 0 2724K 15908K" /mnt/bar
      $ xfs_io -c "fsync" /mnt/bar
    
      $ md5sum /mnt/bar
      95a95813a8c2abc9aa75a6c2914a077e  /mnt/bar
    
      <power fail>
    
      $ mount /dev/sdb /mnt
      $ md5sum /mnt/bar
      207fd8d0b161be8a84b945f0df8d5f8d  /mnt/bar
      # digest should be 95a95813a8c2abc9aa75a6c2914a077e like before the
      # power failure
    
    In the above example, the destination offset of the clone operation
    corresponds to the size of the "bar" file minus 4Kb. So during the clone
    operation, the extent map covering the range from 2572Kb to 2728Kb gets
    trimmed so that it ends at offset 2724Kb, and a new extent map covering
    the range from 2724Kb to 11724Kb is created. So at the end of the clone
    operation when we ask to truncate the pages in the range from 2724Kb to
    2724Kb + 15908Kb, the page invalidation callback ends up removing the new
    extent map (through try_release_extent_mapping()) when the page at offset
    2724Kb is passed to that callback.
    
    Fix this by setting the bit BTRFS_INODE_NEEDS_FULL_SYNC whenever an extent
    map is removed at try_release_extent_mapping(), forcing the next fsync to
    search for modified extents in the fs/subvolume tree instead of relying on
    the presence of extent maps in memory. This way we can continue doing a
    "fast" fsync if the destination range of a clone operation does not
    overlap with an existing range or if any of the criteria necessary to
    remove an extent map at try_release_extent_mapping() is not met (file
    size not bigger then 16Mb or gfp flags do not allow blocking).
    
    CC: stable@vger.kernel.org # 3.16+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cde10ea1da605542610b2a87cf09d52912108a1
Author: Esben Haabendal <eha@deif.com>
Date:   Mon Jul 9 11:43:01 2018 +0200

    i2c: imx: Fix reinit_completion() use
    
    commit 9f9e3e0d4dd3338b3f3dde080789f71901e1e4ff upstream.
    
    Make sure to call reinit_completion() before dma is started to avoid race
    condition where reinit_completion() is called after complete() and before
    wait_for_completion_timeout().
    
    Signed-off-by: Esben Haabendal <eha@deif.com>
    Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0dbc2f3e81050b9aa19110bd29f7f0fdf5f603f
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Sat Jul 14 01:28:15 2018 +0900

    ring_buffer: tracing: Inherit the tracing setting to next ring buffer
    
    commit 73c8d8945505acdcbae137c2e00a1232e0be709f upstream.
    
    Maintain the tracing on/off setting of the ring_buffer when switching
    to the trace buffer snapshot.
    
    Taking a snapshot is done by swapping the backup ring buffer
    (max_tr_buffer). But since the tracing on/off setting is defined
    by the ring buffer, when swapping it, the tracing on/off setting
    can also be changed. This causes a strange result like below:
    
      /sys/kernel/debug/tracing # cat tracing_on
      1
      /sys/kernel/debug/tracing # echo 0 > tracing_on
      /sys/kernel/debug/tracing # cat tracing_on
      0
      /sys/kernel/debug/tracing # echo 1 > snapshot
      /sys/kernel/debug/tracing # cat tracing_on
      1
      /sys/kernel/debug/tracing # echo 1 > snapshot
      /sys/kernel/debug/tracing # cat tracing_on
      0
    
    We don't touch tracing_on, but snapshot changes tracing_on
    setting each time. This is an anomaly, because user doesn't know
    that each "ring_buffer" stores its own tracing-enable state and
    the snapshot is done by swapping ring buffers.
    
    Link: http://lkml.kernel.org/r/153149929558.11274.11730609978254724394.stgit@devbox
    
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
    Cc: Hiraku Toyooka <hiraku.toyooka@cybertrust.co.jp>
    Cc: stable@vger.kernel.org
    Fixes: debdd57f5145 ("tracing: Make a snapshot feature available from userspace")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    [ Updated commit log and comment in the code ]
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cb3f3924d507856788e5072ee873dd8ecad1d5e
Author: Dmitry Safonov <dima@arista.com>
Date:   Sun Aug 5 01:35:53 2018 +0100

    netlink: Don't shift on 64 for ngroups
    
    commit 91874ecf32e41b5d86a4cb9d60e0bee50d828058 upstream.
    
    It's legal to have 64 groups for netlink_sock.
    
    As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
    only to first 32 groups.
    
    The check for correctness of .bind() userspace supplied parameter
    is done by applying mask made from ngroups shift. Which broke Android
    as they have 64 groups and the shift for mask resulted in an overflow.
    
    Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org
    Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e6812bffc91ea1269fd3ed34384f5341ac8061f
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Fri Aug 3 15:31:34 2018 +0200

    nohz: Fix missing tick reprogram when interrupting an inline softirq
    
    commit 0a0e0829f990120cef165bbb804237f400953ec2 upstream.
    
    The full nohz tick is reprogrammed in irq_exit() only if the exit is not in
    a nesting interrupt. This stands as an optimization: whether a hardirq or a
    softirq is interrupted, the tick is going to be reprogrammed when necessary
    at the end of the inner interrupt, with even potential new updates on the
    timer queue.
    
    When soft interrupts are interrupted, it's assumed that they are executing
    on the tail of an interrupt return. In that case tick_nohz_irq_exit() is
    called after softirq processing to take care of the tick reprogramming.
    
    But the assumption is wrong: softirqs can be processed inline as well, ie:
    outside of an interrupt, like in a call to local_bh_enable() or from
    ksoftirqd.
    
    Inline softirqs don't reprogram the tick once they are done, as opposed to
    interrupt tail softirq processing. So if a tick interrupts an inline
    softirq processing, the next timer will neither be reprogrammed from the
    interrupting tick's irq_exit() nor after the interrupted softirq
    processing. This situation may leave the tick unprogrammed while timers are
    armed.
    
    To fix this, simply keep reprogramming the tick even if a softirq has been
    interrupted. That can be optimized further, but for now correctness is more
    important.
    
    Note that new timers enqueued in nohz_full mode after a softirq gets
    interrupted will still be handled just fine through self-IPIs triggered by
    the timer code.
    
    Reported-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
    Cc: stable@vger.kernel.org # 4.14+
    Link: https://lkml.kernel.org/r/1533303094-15855-1-git-send-email-frederic@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba15482a75a84bd68e04816a4dc14e65cc43316b
Author: Anna-Maria Gleixner <anna-maria@linutronix.de>
Date:   Tue Jul 31 18:13:58 2018 +0200

    nohz: Fix local_timer_softirq_pending()
    
    commit 80d20d35af1edd632a5e7a3b9c0ab7ceff92769e upstream.
    
    local_timer_softirq_pending() checks whether the timer softirq is
    pending with: local_softirq_pending() & TIMER_SOFTIRQ.
    
    This is wrong because TIMER_SOFTIRQ is the softirq number and not a
    bitmask. So the test checks for the wrong bit.
    
    Use BIT(TIMER_SOFTIRQ) instead.
    
    Fixes: 5d62c183f9e9 ("nohz: Prevent a timer interrupt storm in tick_nohz_stop_sched_tick()")
    Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com>
    Acked-by: Frederic Weisbecker <frederic@kernel.org>
    Cc: bigeasy@linutronix.de
    Cc: peterz@infradead.org
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20180731161358.29472-1-anna-maria@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58207429db63a531d21a173a9780a8cd9be48725
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Mon Jul 30 08:28:08 2018 -0400

    perf/x86/intel/uncore: Fix hardcoded index of Broadwell extra PCI devices
    
    commit 156c8b58ef5cfd97245928c95669fd4cb0f9c388 upstream.
    
    Masayoshi Mizuma reported that a warning message is shown while a CPU is
    hot-removed on Broadwell servers:
    
      WARNING: CPU: 126 PID: 6 at arch/x86/events/intel/uncore.c:988
      uncore_pci_remove+0x10b/0x150
      Call Trace:
       pci_device_remove+0x42/0xd0
       device_release_driver_internal+0x148/0x220
       pci_stop_bus_device+0x76/0xa0
       pci_stop_root_bus+0x44/0x60
       acpi_pci_root_remove+0x1f/0x80
       acpi_bus_trim+0x57/0x90
       acpi_bus_trim+0x2e/0x90
       acpi_device_hotplug+0x2bc/0x4b0
       acpi_hotplug_work_fn+0x1a/0x30
       process_one_work+0x174/0x3a0
       worker_thread+0x4c/0x3d0
       kthread+0xf8/0x130
    
    This bug was introduced by:
    
      commit 15a3e845b01c ("perf/x86/intel/uncore: Fix SBOX support for Broadwell CPUs")
    
    The index of "QPI Port 2 filter" was hardcode to 2, but this conflicts with the
    index of "PCU.3" which is "HSWEP_PCI_PCU_3", which equals to 2 as well.
    
    To fix the conflict, the hardcoded index needs to be cleaned up:
    
     - introduce a new enumerator "BDX_PCI_QPI_PORT2_FILTER" for "QPI Port 2
       filter" on Broadwell,
     - increase UNCORE_EXTRA_PCI_DEV_MAX by one,
     - clean up the hardcoded index.
    
    Debugged-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Suggested-by: Ingo Molnar <mingo@kernel.org>
    Reported-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Cc: msys.mizuma@gmail.com
    Cc: stable@vger.kernel.org
    Fixes: 15a3e845b01c ("perf/x86/intel/uncore: Fix SBOX support for Broadwell CPUs")
    Link: http://lkml.kernel.org/r/1532953688-15008-1-git-send-email-kan.liang@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26af0b9e95520b9a3f3b6979379415a76ffe570c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Aug 3 14:44:59 2018 +0200

    genirq: Make force irq threading setup more robust
    
    commit d1f0301b3333eef5efbfa1fe0f0edbea01863d5d upstream.
    
    The support of force threading interrupts which are set up with both a
    primary and a threaded handler wreckaged the setup of regular requested
    threaded interrupts (primary handler == NULL).
    
    The reason is that it does not check whether the primary handler is set to
    the default handler which wakes the handler thread. Instead it replaces the
    thread handler with the primary handler as it would do with force threaded
    interrupts which have been requested via request_irq(). So both the primary
    and the thread handler become the same which then triggers the warnon that
    the thread handler tries to wakeup a not configured secondary thread.
    
    Fortunately this only happens when the driver omits the IRQF_ONESHOT flag
    when requesting the threaded interrupt, which is normaly caught by the
    sanity checks when force irq threading is disabled.
    
    Fix it by skipping the force threading setup when a regular threaded
    interrupt is requested. As a consequence the interrupt request which lacks
    the IRQ_ONESHOT flag is rejected correctly instead of silently wreckaging
    it.
    
    Fixes: 2a1d3ab8986d ("genirq: Handle force threading of irqs with primary and thread handler")
    Reported-by: Kurt Kanzenbach <kurt.kanzenbach@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Kurt Kanzenbach <kurt.kanzenbach@linutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6505a712d8aad5a295312896095e318b6616e987
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Aug 3 12:52:58 2018 -0700

    jfs: Fix usercopy whitelist for inline inode data
    
    commit 961b33c244e5ba1543ae26270a1ba29f29c2db83 upstream.
    
    Bart Massey reported what turned out to be a usercopy whitelist false
    positive in JFS when symlink contents exceeded 128 bytes. The inline
    inode data (i_inline) is actually designed to overflow into the "extended
    area" following it (i_inline_ea) when needed. So the whitelist needed to
    be expanded to include both i_inline and i_inline_ea (the whole size
    of which is calculated internally using IDATASIZE, 256, instead of
    sizeof(i_inline), 128).
    
    $ cd /mnt/jfs
    $ touch $(perl -e 'print "B" x 250')
    $ ln -s B* b
    $ ls -l >/dev/null
    
    [  249.436410] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'jfs_ip' (offset 616, size 250)!
    
    Reported-by: Bart Massey <bart.massey@gmail.com>
    Fixes: 8d2704d382a9 ("jfs: Define usercopy region in jfs_ip slab cache")
    Cc: Dave Kleikamp <shaggy@kernel.org>
    Cc: jfs-discussion@lists.sourceforge.net
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37be2e37d83cd965a9146fe7a3560e08b77caf70
Author: Anil Gurumurthy <anil.gurumurthy@cavium.com>
Date:   Wed Jul 18 14:29:55 2018 -0700

    scsi: qla2xxx: Return error when TMF returns
    
    commit b4146c4929ef61d5afca011474d59d0918a0cd82 upstream.
    
    Propagate the task management completion status properly to avoid
    unnecessary waits for commands to complete.
    
    Fixes: faef62d13463 ("[SCSI] qla2xxx: Fix Task Management command asynchronous handling")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Anil Gurumurthy <anil.gurumurthy@cavium.com>
    Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29af9c350ea57bbc34a0dd5acac4a1893391a170
Author: Quinn Tran <quinn.tran@cavium.com>
Date:   Wed Jul 18 14:29:54 2018 -0700

    scsi: qla2xxx: Fix ISP recovery on unload
    
    commit b08abbd9f5996309f021684f9ca74da30dcca36a upstream.
    
    During unload process, the chip can encounter problem where a FW dump would
    be captured. For this case, the full reset sequence will be skip to bring
    the chip back to full operational state.
    
    Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla data structure refactoring")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
    Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37b94b0c72c6ab8475a8d735e661772d766f710f
Author: Quinn Tran <quinn.tran@cavium.com>
Date:   Wed Jul 18 14:29:53 2018 -0700

    scsi: qla2xxx: Fix driver unload by shutting down chip
    
    commit 45235022da9925b2b070c0139629233173e50089 upstream.
    
    Use chip shutdown at the start of unload to stop all DMA + traffic and
    bring down the laser. This prevents any link activities from triggering the
    driver to be re-engaged.
    
    Fixes: 4b60c82736d0 ("scsi: qla2xxx: Add fw_started flags to qpair")
    Cc: <stable@vger.kernel.org> #4.16
    Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
    Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 030680c5b21d4ec33234d17503827800e4550345
Author: Quinn Tran <quinn.tran@cavium.com>
Date:   Wed Jul 18 14:29:52 2018 -0700

    scsi: qla2xxx: Fix NPIV deletion by calling wait_for_sess_deletion
    
    commit efa93f48fa9d423fda166bc3b6c0cbb09682492e upstream.
    
    Add wait for session deletion to finish before freeing an NPIV scsi host.
    
    Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
    Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7bc915396d49ec46cc42dee301af718b215e3d0
Author: Quinn Tran <quinn.tran@cavium.com>
Date:   Wed Jul 18 14:29:51 2018 -0700

    scsi: qla2xxx: Fix unintialized List head crash
    
    commit e3dde080ebbdbb4bda8eee35d770714fee8c59ac upstream.
    
    In case of IOCB Queue full or system where memory is low and driver
    receives large number of RSCN storm, the stale sp pointer can stay on
    gpnid_list resulting in page_fault.
    
    This patch fixes this issue by initializing the sp->elem list head and
    removing sp->elem before memory is freed.
    
    Following stack trace is seen
    
     9 [ffff987b37d1bc60] page_fault at ffffffffad516768 [exception RIP: qla24xx_async_gpnid+496]
    10 [ffff987b37d1bd10] qla24xx_async_gpnid at ffffffffc039866d [qla2xxx]
    11 [ffff987b37d1bd80] qla2x00_do_work at ffffffffc036169c [qla2xxx]
    12 [ffff987b37d1be38] qla2x00_do_dpc_all_vps at ffffffffc03adfed [qla2xxx]
    13 [ffff987b37d1be78] qla2x00_do_dpc at ffffffffc036458a [qla2xxx]
    14 [ffff987b37d1bec8] kthread at ffffffffacebae31
    
    Fixes: 2d73ac6102d9 ("scsi: qla2xxx: Serialize GPNID for multiple RSCN")
    Cc: <stable@vger.kernel.org> # v4.17+
    Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
    Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>