commit 8e6a9240b1918c31a90e5d0a02c467ca68b160c6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Oct 10 08:54:28 2018 +0200

    Linux 4.14.75

commit 4e7ea65127acb4728b975e42764c32455a1aa9f5
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Thu Sep 13 21:16:20 2018 -0400

    dm thin metadata: fix __udivdi3 undefined on 32-bit
    
    commit 013ad043906b2befd4a9bfb06219ed9fedd92716 upstream.
    
    sector_div() is only viable for use with sector_t.
    dm_block_t is typedef'd to uint64_t -- so use div_u64() instead.
    
    Fixes: 3ab918281 ("dm thin metadata: try to avoid ever aborting transactions")
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07f79b39d474bab2288ef68dc8e64683758fa0ec
Author: Song Liu <songliubraving@fb.com>
Date:   Wed Oct 3 11:30:35 2018 -0700

    ixgbe: check return value of napi_complete_done()
    
    commit 4233cfe6ec4683497d7318f55ce7617e97f2e610 upstream.
    
    The NIC driver should only enable interrupts when napi_complete_done()
    returns true. This patch adds the check for ixgbe.
    
    Cc: stable@vger.kernel.org # 4.10+
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de0e2a92ccc5460eb8dd115de891cde63ae552bf
Author: Ashish Samant <ashish.samant@oracle.com>
Date:   Fri Oct 5 15:52:15 2018 -0700

    ocfs2: fix locking for res->tracking and dlm->tracking_list
    
    commit cbe355f57c8074bc4f452e5b6e35509044c6fa23 upstream.
    
    In dlm_init_lockres() we access and modify res->tracking and
    dlm->tracking_list without holding dlm->track_lock.  This can cause list
    corruptions and can end up in kernel panic.
    
    Fix this by locking res->tracking and dlm->tracking_list with
    dlm->track_lock instead of dlm->spinlock.
    
    Link: http://lkml.kernel.org/r/1529951192-4686-1-git-send-email-ashish.samant@oracle.com
    Signed-off-by: Ashish Samant <ashish.samant@oracle.com>
    Reviewed-by: Changwei Ge <ge.changwei@h3c.com>
    Acked-by: Joseph Qi <jiangqi903@gmail.com>
    Acked-by: Jun Piao <piaojun@huawei.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <ge.changwei@h3c.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8566a92ab75d442a823453414c6158b0b3c5ce7
Author: Jann Horn <jannh@google.com>
Date:   Fri Oct 5 15:51:58 2018 -0700

    proc: restrict kernel stack dumps to root
    
    commit f8a00cef17206ecd1b30d3d9f99e10d9fa707aa7 upstream.
    
    Currently, you can use /proc/self/task/*/stack to cause a stack walk on
    a task you control while it is running on another CPU.  That means that
    the stack can change under the stack walker.  The stack walker does
    have guards against going completely off the rails and into random
    kernel memory, but it can interpret random data from your kernel stack
    as instruction pointers and stack pointers.  This can cause exposure of
    kernel stack contents to userspace.
    
    Restrict the ability to inspect kernel stacks of arbitrary tasks to root
    in order to prevent a local attacker from exploiting racy stack unwinding
    to leak kernel task stack contents.  See the added comment for a longer
    rationale.
    
    There don't seem to be any users of this userspace API that can't
    gracefully bail out if reading from the file fails.  Therefore, I believe
    that this change is unlikely to break things.  In the case that this patch
    does end up needing a revert, the next-best solution might be to fake a
    single-entry stack based on wchan.
    
    Link: http://lkml.kernel.org/r/20180927153316.200286-1-jannh@google.com
    Fixes: 2ec220e27f50 ("proc: add /proc/*/stack")
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Ken Chen <kenchen@google.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H . Peter Anvin" <hpa@zytor.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4de0fb95a2875252ab023f63c44762c7219b6da6
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Sep 17 04:14:55 2018 +0000

    tools: hv: fcopy: set 'error' in case an unknown operation was requested
    
    commit c2d68afba86d1ff01e7300c68bc16a9234dcd8e9 upstream.
    
    'error' variable is left uninitialized in case we see an unknown operation.
    As we don't immediately return and proceed to pwrite() we need to set it
    to something, HV_E_FAIL sounds good enough.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d24e2609002ccab8e00bb23dbd3abc94566091f
Author: Dexuan Cui <decui@microsoft.com>
Date:   Mon Sep 17 04:14:54 2018 +0000

    Drivers: hv: vmbus: Use get/put_cpu() in vmbus_connect()
    
    commit 41e270f6898e7502be9fd6920ee0a108ca259d36 upstream.
    
    With CONFIG_DEBUG_PREEMPT=y, I always see this warning:
    BUG: using smp_processor_id() in preemptible [00000000]
    
    Fix the false warning by using get/put_cpu().
    
    Here vmbus_connect() sends a message to the host and waits for the
    host's response. The host will deliver the response message and an
    interrupt on CPU msg->target_vcpu, and later the interrupt handler
    will wake up vmbus_connect(). vmbus_connect() doesn't really have
    to run on the same cpu as CPU msg->target_vcpu, so it's safe to
    call put_cpu() just here.
    
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Cc: stable@vger.kernel.org
    Cc: K. Y. Srinivasan <kys@microsoft.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 119bf9470be955060893fa1072b097053e8f48a1
Author: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Date:   Thu Sep 13 15:37:04 2018 +0200

    gpiolib: Free the last requested descriptor
    
    commit 19a4fbffc94e41abaa2a623a25ce2641d69eccf0 upstream.
    
    The current code only frees N-1 gpios if an error occurs during
    gpiod_set_transitory, gpiod_direction_output or gpiod_direction_input.
    Leading to gpios that cannot be used by userspace nor other drivers.
    
    Cc: Timur Tabi <timur@codeaurora.org>
    Cc: stable@vger.kernel.org
    Fixes: ab3dbcf78f60f46d ("gpioib: do not free unrequested descriptors)
    Reported-by: Jan Lorenzen <jl@newtec.dk>
    Reported-by: Jim Paris <jim@jtan.com>
    Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1df517a4cafde215d3e7f853eb2b6edb7cd72dab
Author: Horia Geantă <horia.geanta@nxp.com>
Date:   Fri Sep 14 18:34:28 2018 +0300

    crypto: caam/jr - fix ablkcipher_edesc pointer arithmetic
    
    commit 13cc6f48c7434ce46ba6dbc90003a136a263d75a upstream.
    
    In some cases the zero-length hw_desc array at the end of
    ablkcipher_edesc struct requires for 4B of tail padding.
    
    Due to tail padding and the way pointers to S/G table and IV
    are computed:
            edesc->sec4_sg = (void *)edesc + sizeof(struct ablkcipher_edesc) +
                             desc_bytes;
            iv = (u8 *)edesc->hw_desc + desc_bytes + sec4_sg_bytes;
    first 4 bytes of IV are overwritten by S/G table.
    
    Update computation of pointer to S/G table to rely on offset of hw_desc
    member and not on sizeof() operator.
    
    Cc: <stable@vger.kernel.org> # 4.13+
    Fixes: 115957bb3e59 ("crypto: caam - fix IV DMA mapping and updating")
    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 3b1a8535b8e13c7e3493f042d02226328bbceff0
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Fri Sep 21 18:03:18 2018 +0300

    crypto: mxs-dcp - Fix wait logic on chan threads
    
    commit d80771c08363ad7fbf0f56f5301e7ca65065c582 upstream.
    
    When compiling with CONFIG_DEBUG_ATOMIC_SLEEP=y the mxs-dcp driver
    prints warnings such as:
    
    WARNING: CPU: 0 PID: 120 at kernel/sched/core.c:7736 __might_sleep+0x98/0x9c
    do not call blocking ops when !TASK_RUNNING; state=1 set at [<8081978c>] dcp_chan_thread_sha+0x3c/0x2ec
    
    The problem is that blocking ops will manipulate current->state
    themselves so it is not allowed to call them between
    set_current_state(TASK_INTERRUPTIBLE) and schedule().
    
    Fix this by converting the per-chan mutex to a spinlock (it only
    protects tiny list ops anyway) and rearranging the wait logic so that
    callbacks are called current->state as TASK_RUNNING. Those callbacks
    will indeed call blocking ops themselves so this is required.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90ecb700345ce38c940e6c8b78ee7369bcca82f9
Author: Waiman Long <longman@redhat.com>
Date:   Sat Sep 22 20:41:55 2018 -0400

    crypto: qat - Fix KASAN stack-out-of-bounds bug in adf_probe()
    
    commit ba439a6cbfa2936a6713f64cb499de7943673fe3 upstream.
    
    The following KASAN warning was printed when booting a 64-bit kernel
    on some systems with Intel CPUs:
    
    [   44.512826] ==================================================================
    [   44.520165] BUG: KASAN: stack-out-of-bounds in find_first_bit+0xb0/0xc0
    [   44.526786] Read of size 8 at addr ffff88041e02fc50 by task kworker/0:2/124
    
    [   44.535253] CPU: 0 PID: 124 Comm: kworker/0:2 Tainted: G               X --------- ---  4.18.0-12.el8.x86_64+debug #1
    [   44.545858] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS BKVDTRL1.86B.0005.D08.1712070559 12/07/2017
    [   44.555682] Workqueue: events work_for_cpu_fn
    [   44.560043] Call Trace:
    [   44.562502]  dump_stack+0x9a/0xe9
    [   44.565832]  print_address_description+0x65/0x22e
    [   44.570683]  ? find_first_bit+0xb0/0xc0
    [   44.570689]  kasan_report.cold.6+0x92/0x19f
    [   44.578726]  find_first_bit+0xb0/0xc0
    [   44.578737]  adf_probe+0x9eb/0x19a0 [qat_c62x]
    [   44.578751]  ? adf_remove+0x110/0x110 [qat_c62x]
    [   44.591490]  ? mark_held_locks+0xc8/0x140
    [   44.591498]  ? _raw_spin_unlock+0x30/0x30
    [   44.591505]  ? trace_hardirqs_on_caller+0x381/0x570
    [   44.604418]  ? adf_remove+0x110/0x110 [qat_c62x]
    [   44.604427]  local_pci_probe+0xd4/0x180
    [   44.604432]  ? pci_device_shutdown+0x110/0x110
    [   44.617386]  work_for_cpu_fn+0x51/0xa0
    [   44.621145]  process_one_work+0x8fe/0x16e0
    [   44.625263]  ? pwq_dec_nr_in_flight+0x2d0/0x2d0
    [   44.629799]  ? lock_acquire+0x14c/0x400
    [   44.633645]  ? move_linked_works+0x12e/0x2a0
    [   44.637928]  worker_thread+0x536/0xb50
    [   44.641690]  ? __kthread_parkme+0xb6/0x180
    [   44.645796]  ? process_one_work+0x16e0/0x16e0
    [   44.650160]  kthread+0x30c/0x3d0
    [   44.653400]  ? kthread_create_worker_on_cpu+0xc0/0xc0
    [   44.658457]  ret_from_fork+0x3a/0x50
    
    [   44.663557] The buggy address belongs to the page:
    [   44.668350] page:ffffea0010780bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
    [   44.676356] flags: 0x17ffffc0000000()
    [   44.680023] raw: 0017ffffc0000000 ffffea0010780bc8 ffffea0010780bc8 0000000000000000
    [   44.687769] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    [   44.695510] page dumped because: kasan: bad access detected
    
    [   44.702578] Memory state around the buggy address:
    [   44.707372]  ffff88041e02fb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   44.714593]  ffff88041e02fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   44.721810] >ffff88041e02fc00: 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 f2 f2 f2 f2
    [   44.729028]                                                  ^
    [   44.734864]  ffff88041e02fc80: f2 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
    [   44.742082]  ffff88041e02fd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   44.749299] ==================================================================
    
    Looking into the code:
    
      int ret, bar_mask;
        :
      for_each_set_bit(bar_nr, (const unsigned long *)&bar_mask,
    
    It is casting a 32-bit integer pointer to a 64-bit unsigned long
    pointer. There are two problems here. First, the 32-bit pointer address
    may not be 64-bit aligned. Secondly, it is accessing an extra 4 bytes.
    
    This is fixed by changing the bar_mask type to unsigned long.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5bb359c078a6475caf267f78392137701f9b890
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Thu Oct 4 11:39:42 2018 +0800

    ALSA: hda/realtek - Cannot adjust speaker's volume on Dell XPS 27 7760
    
    commit 709ae62e8e6d9ac4df7dadb3b8ae432675c45ef9 upstream.
    
    The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
    adjust speaker's volume on a Dell AIO"), the output requires to connect
    to a node with Amp-out capability.
    
    Applying the same fixup ALC298_FIXUP_SPK_VOLUME can fix the issue.
    
    BugLink: https://bugs.launchpad.net/bugs/1775068
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06f93e40f939f4df9efa57467f1bf195ce50d138
Author: Singh, Brijesh <brijesh.singh@amd.com>
Date:   Thu Oct 4 21:40:23 2018 +0000

    iommu/amd: Clear memory encryption mask from physical address
    
    commit b3e9b515b08e407ab3a026dc2e4d935c48d05f69 upstream.
    
    Boris Ostrovsky reported a memory leak with device passthrough when SME
    is active.
    
    The VFIO driver uses iommu_iova_to_phys() to get the physical address for
    an iova. This physical address is later passed into vfio_unmap_unpin() to
    unpin the memory. The vfio_unmap_unpin() uses pfn_valid() before unpinning
    the memory. The pfn_valid() check was failing because encryption mask was
    part of the physical address returned. This resulted in the memory not
    being unpinned and therefore leaked after the guest terminates.
    
    The memory encryption mask must be cleared from the physical address in
    iommu_iova_to_phys().
    
    Fixes: 2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")
    Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: <iommu@lists.linux-foundation.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: kvm@vger.kernel.org
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcdb2262d3892c60d171208cd63071ce69281585
Author: Aurelien Aptel <aaptel@suse.com>
Date:   Thu May 17 16:35:07 2018 +0200

    smb2: fix missing files in root share directory listing
    
    commit 0595751f267994c3c7027377058e4185b3a28e75 upstream.
    
    When mounting a Windows share that is the root of a drive (eg. C$)
    the server does not return . and .. directory entries. This results in
    the smb2 code path erroneously skipping the 2 first entries.
    
    Pseudo-code of the readdir() code path:
    
    cifs_readdir(struct file, struct dir_context)
        initiate_cifs_search            <-- if no reponse cached yet
            server->ops->query_dir_first
    
        dir_emit_dots
            dir_emit                    <-- adds "." and ".." if we're at pos=0
    
        find_cifs_entry
            initiate_cifs_search        <-- if pos < start of current response
                                             (restart search)
            server->ops->query_dir_next <-- if pos > end of current response
                                             (fetch next search res)
    
        for(...)                        <-- loops over cur response entries
                                              starting at pos
            cifs_filldir                <-- skip . and .., emit entry
                cifs_fill_dirent
                dir_emit
            pos++
    
    A) dir_emit_dots() always adds . & ..
       and sets the current dir pos to 2 (0 and 1 are done).
    
    Therefore we always want the index_to_find to be 2 regardless of if
    the response has . and ..
    
    B) smb1 code initializes index_of_last_entry with a +2 offset
    
      in cifssmb.c CIFSFindFirst():
                    psrch_inf->index_of_last_entry = 2 /* skip . and .. */ +
                            psrch_inf->entries_in_buffer;
    
    Later in find_cifs_entry() we want to find the next dir entry at pos=2
    as a result of (A)
    
            first_entry_in_buffer = cfile->srch_inf.index_of_last_entry -
                                            cfile->srch_inf.entries_in_buffer;
    
    This var is the dir pos that the first entry in the buffer will
    have therefore it must be 2 in the first call.
    
    If we don't offset index_of_last_entry by 2 (like in (B)),
    first_entry_in_buffer=0 but we were instructed to get pos=2 so this
    code in find_cifs_entry() skips the 2 first which is ok for non-root
    shares, as it skips . and .. from the response but is not ok for root
    shares where the 2 first are actual files
    
                    pos_in_buf = index_to_find - first_entry_in_buffer;
                    // pos_in_buf=2
                    // we skip 2 first response entries :(
                    for (i = 0; (i < (pos_in_buf)) && (cur_ent != NULL); i++) {
                            /* go entry by entry figuring out which is first */
                            cur_ent = nxt_dir_entry(cur_ent, end_of_smb,
                                                    cfile->srch_inf.info_level);
                    }
    
    C) cifs_filldir() skips . and .. so we can safely ignore them for now.
    
    Sample program:
    
    int main(int argc, char **argv)
    {
            const char *path = argc >= 2 ? argv[1] : ".";
            DIR *dh;
            struct dirent *de;
    
            printf("listing path <%s>\n", path);
            dh = opendir(path);
            if (!dh) {
                    printf("opendir error %d\n", errno);
                    return 1;
            }
    
            while (1) {
                    de = readdir(dh);
                    if (!de) {
                            if (errno) {
                                    printf("readdir error %d\n", errno);
                                    return 1;
                            }
                            printf("end of listing\n");
                            break;
                    }
                    printf("off=%lu <%s>\n", de->d_off, de->d_name);
            }
    
            return 0;
    }
    
    Before the fix with SMB1 on root shares:
    
    <.>            off=1
    <..>           off=2
    <$Recycle.Bin> off=3
    <bootmgr>      off=4
    
    and on non-root shares:
    
    <.>    off=1
    <..>   off=4  <-- after adding .., the offsets jumps to +2 because
    <2536> off=5       we skipped . and .. from response buffer (C)
    <411>  off=6       but still incremented pos
    <file> off=7
    <fsx>  off=8
    
    Therefore the fix for smb2 is to mimic smb1 behaviour and offset the
    index_of_last_entry by 2.
    
    Test results comparing smb1 and smb2 before/after the fix on root
    share, non-root shares and on large directories (ie. multi-response
    dir listing):
    
    PRE FIX
    =======
    pre-1-root VS pre-2-root:
            ERR pre-2-root is missing [bootmgr, $Recycle.Bin]
    pre-1-nonroot VS pre-2-nonroot:
            OK~ same files, same order, different offsets
    pre-1-nonroot-large VS pre-2-nonroot-large:
            OK~ same files, same order, different offsets
    
    POST FIX
    ========
    post-1-root VS post-2-root:
            OK same files, same order, same offsets
    post-1-nonroot VS post-2-nonroot:
            OK same files, same order, same offsets
    post-1-nonroot-large VS post-2-nonroot-large:
            OK same files, same order, same offsets
    
    REGRESSION?
    ===========
    pre-1-root VS post-1-root:
            OK same files, same order, same offsets
    pre-1-nonroot VS post-1-nonroot:
            OK same files, same order, same offsets
    
    BugLink: https://bugzilla.samba.org/show_bug.cgi?id=13107
    Signed-off-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Paulo Alcantara <palcantara@suse.deR>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b420b7b7923b9fd1a955eb176b43d88175065262
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Tue Sep 18 00:36:36 2018 -0400

    sysfs: Do not return POSIX ACL xattrs via listxattr
    
    commit ffc4c92227db5699493e43eb140b4cb5904c30ff upstream.
    
    Commit 786534b92f3c introduced a regression that caused listxattr to
    return the POSIX ACL attribute names even though sysfs doesn't support
    POSIX ACLs.  This happens because simple_xattr_list checks for NULL
    i_acl / i_default_acl, but inode_init_always initializes those fields
    to ACL_NOT_CACHED ((void *)-1).  For example:
        $ getfattr -m- -d /sys
        /sys: system.posix_acl_access: Operation not supported
        /sys: system.posix_acl_default: Operation not supported
    Fix this in simple_xattr_list by checking if the filesystem supports POSIX ACLs.
    
    Fixes: 786534b92f3c ("tmpfs: listxattr should include POSIX ACL xattrs")
    Reported-by:  Marc Aurèle La France <tsi@tuyoix.net>
    Tested-by: Marc Aurèle La France <tsi@tuyoix.net>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Cc: stable@vger.kernel.org # v4.5+
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa7d75f64b8011b33d50296e0d3805fa91dfb5e7
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Oct 4 14:49:10 2018 +0200

    ovl: fix format of setxattr debug
    
    commit 1a8f8d2a443ef9ad9a3065ba8c8119df714240fa upstream.
    
    Format has a typo: it was meant to be "%.*s", not "%*s".  But at some point
    callers grew nonprintable values as well, so use "%*pE" instead with a
    maximized length.
    
    Reported-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")
    Cc: <stable@vger.kernel.org> # v4.12
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d75ecc13fdc58f39451f99f62d4d6940fd5397f
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Tue Sep 18 16:34:31 2018 +0300

    ovl: fix memory leak on unlink of indexed file
    
    commit 63e132528032ce937126aba591a7b37ec593a6bb upstream.
    
    The memory leak was detected by kmemleak when running xfstests
    overlay/051,053
    
    Fixes: caf70cb2ba5d ("ovl: cleanup orphan index entries")
    Cc: <stable@vger.kernel.org> # v4.13
    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 be406434737b1bc806517a5163941292f1a84fa0
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Fri Sep 28 21:00:48 2018 +0300

    ovl: fix access beyond unterminated strings
    
    commit 601350ff58d5415a001769532f6b8333820e5786 upstream.
    
    KASAN detected slab-out-of-bounds access in printk from overlayfs,
    because string format used %*s instead of %.*s.
    
    > BUG: KASAN: slab-out-of-bounds in string+0x298/0x2d0 lib/vsprintf.c:604
    > Read of size 1 at addr ffff8801c36c66ba by task syz-executor2/27811
    >
    > CPU: 0 PID: 27811 Comm: syz-executor2 Not tainted 4.19.0-rc5+ #36
    ...
    >  printk+0xa7/0xcf kernel/printk/printk.c:1996
    >  ovl_lookup_index.cold.15+0xe8/0x1f8 fs/overlayfs/namei.c:689
    
    Reported-by: syzbot+376cea2b0ef340db3dd4@syzkaller.appspotmail.com
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: 359f392ca53e ("ovl: lookup index entry for copy up origin")
    Cc: <stable@vger.kernel.org> # v4.13
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa41fb9593afc819483826aef6e4c7937bdf62e4
Author: Josh Abraham <j.abraham1776@gmail.com>
Date:   Wed Sep 12 15:13:54 2018 -1000

    xen: fix GCC warning and remove duplicate EVTCHN_ROW/EVTCHN_COL usage
    
    [ Upstream commit 4dca864b59dd150a221730775e2f21f49779c135 ]
    
    This patch removes duplicate macro useage in events_base.c.
    
    It also fixes gcc warning:
    variable ‘col’ set but not used [-Wunused-but-set-variable]
    
    Signed-off-by: Joshua Abraham <j.abraham1776@gmail.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a502165dae0960615efb0b1dbc45c09f5dc1db3d
Author: Olaf Hering <olaf@aepfle.de>
Date:   Fri Sep 7 16:31:35 2018 +0200

    xen: avoid crash in disable_hotplug_cpu
    
    [ Upstream commit 3366cdb6d350d95466ee430ac50f3c8415ca8f46 ]
    
    The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
    
    BUG: unable to handle kernel NULL pointer dereference at 00000000000002d8
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-default #1 openSUSE Tumbleweed (unreleased)
    Hardware name: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
    RIP: e030:device_offline+0x9/0xb0
    Code: 77 24 00 e9 ce fe ff ff 48 8b 13 e9 68 ff ff ff 48 8b 13 e9 29 ff ff ff 48 8b 13 e9 ea fe ff ff 90 66 66 66 66 90 41 54 55 53 <f6> 87 d8 02 00 00 01 0f 85 88 00 00 00 48 c7 c2 20 09 60 81 31 f6
    RSP: e02b:ffffc90040f27e80 EFLAGS: 00010203
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: ffff8801f3800000 RSI: ffffc90040f27e70 RDI: 0000000000000000
    RBP: 0000000000000000 R08: ffffffff820e47b3 R09: 0000000000000000
    R10: 0000000000007ff0 R11: 0000000000000000 R12: ffffffff822e6d30
    R13: dead000000000200 R14: dead000000000100 R15: ffffffff8158b4e0
    FS:  00007ffa595158c0(0000) GS:ffff8801f39c0000(0000) knlGS:0000000000000000
    CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000000002d8 CR3: 00000001d9602000 CR4: 0000000000002660
    Call Trace:
     handle_vcpu_hotplug_event+0xb5/0xc0
     xenwatch_thread+0x80/0x140
     ? wait_woken+0x80/0x80
     kthread+0x112/0x130
     ? kthread_create_worker_on_cpu+0x40/0x40
     ret_from_fork+0x3a/0x50
    
    This happens because handle_vcpu_hotplug_event is called twice. In the
    first iteration cpu_present is still true, in the second iteration
    cpu_present is false which causes get_cpu_device to return NULL.
    In case of cpu#0, cpu_online is apparently always true.
    
    Fix this crash by checking if the cpu can be hotplugged, which is false
    for a cpu that was just removed.
    
    Also check if the cpu was actually offlined by device_remove, otherwise
    leave the cpu_present state as it is.
    
    Rearrange to code to do all work with device_hotplug_lock held.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e1494794ebcbbace76c0da4e2d0d7a2857a13f0
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Thu Sep 6 13:26:08 2018 +0200

    xen/manage: don't complain about an empty value in control/sysrq node
    
    [ Upstream commit 87dffe86d406bee8782cac2db035acb9a28620a7 ]
    
    When guest receives a sysrq request from the host it acknowledges it by
    writing '\0' to control/sysrq xenstore node. This, however, make xenstore
    watch fire again but xenbus_scanf() fails to parse empty value with "%c"
    format string:
    
     sysrq: SysRq : Emergency Sync
     Emergency Sync complete
     xen:manage: Error -34 reading sysrq code in control/sysrq
    
    Ignore -ERANGE the same way we already ignore -ENOENT, empty value in
    control/sysrq is totally legal.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Reviewed-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfb29d69e4d85de6dbc95672892113cb225bf1f2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Sep 6 12:47:01 2018 +0300

    cifs: read overflow in is_valid_oplock_break()
    
    [ Upstream commit 097f5863b1a0c9901f180bbd56ae7d630655faaa ]
    
    We need to verify that the "data_offset" is within bounds.
    
    Reported-by: Dr Silvio Cesare of InfoSect <silvio.cesare@gmail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d60f98cde7a1ed5e4ebc508c9d2e0d415d4e71d
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Wed Sep 12 15:31:35 2018 +0200

    s390/qeth: don't dump past end of unknown HW header
    
    [ Upstream commit 0ac1487c4b2de383b91ecad1be561b8f7a2c15f4 ]
    
    For inbound data with an unsupported HW header format, only dump the
    actual HW header. We have no idea how much payload follows it, and what
    it contains. Worst case, we dump past the end of the Inbound Buffer and
    access whatever is located next in memory.
    
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5afd6b6eae543467398e4c35c344a163deec37a
Author: Wenjia Zhang <wenjia@linux.ibm.com>
Date:   Wed Sep 12 15:31:34 2018 +0200

    s390/qeth: use vzalloc for QUERY OAT buffer
    
    [ Upstream commit aec45e857c5538664edb76a60dd452e3265f37d1 ]
    
    qeth_query_oat_command() currently allocates the kernel buffer for
    the SIOC_QETH_QUERY_OAT ioctl with kzalloc. So on systems with
    fragmented memory, large allocations may fail (eg. the qethqoat tool by
    default uses 132KB).
    
    Solve this issue by using vzalloc, backing the allocation with
    non-contiguous memory.
    
    Signed-off-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Reviewed-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad297898159ff167a7ea0ebc6f2508a49ade6262
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Sep 11 01:51:43 2018 +0800

    r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED
    
    [ Upstream commit 6ad569019999300afd8e614d296fdc356550b77f ]
    
    After system suspend, sometimes the r8169 doesn't work when ethernet
    cable gets pluggued.
    
    This issue happens because rtl_reset_work() doesn't get called from
    rtl8169_runtime_resume(), after system suspend.
    
    In rtl_task(), RTL_FLAG_TASK_* only gets cleared if this condition is
    met:
    if (!netif_running(dev) ||
        !test_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags))
        ...
    
    If RTL_FLAG_TASK_ENABLED was cleared during system suspend while
    RTL_FLAG_TASK_RESET_PENDING was set, the next rtl_schedule_task() won't
    schedule task as the flag is still there.
    
    So in addition to clearing RTL_FLAG_TASK_ENABLED, also clears other
    flags.
    
    Cc: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7b86faf0bd11ae44d009d7d68ec8af5491119fe
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Sep 10 15:52:55 2018 +0200

    drm/amdgpu: fix error handling in amdgpu_cs_user_fence_chunk
    
    [ Upstream commit 0165de983272d1fae0809ed9db47c46a412279bc ]
    
    Slowly leaking memory one page at a time :)
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2c9d68ed3c2cda6df03afcc150e1c6ad1d072d5
Author: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Sun Sep 9 17:47:31 2018 +0200

    arm64: jump_label.h: use asm_volatile_goto macro instead of "asm goto"
    
    [ Upstream commit 13aceef06adfaf93d52e01e28a8bc8a0ad471d83 ]
    
    All other uses of "asm goto" go through asm_volatile_goto, which avoids
    a miscompile when using GCC < 4.8.2. Replace our open-coded "asm goto"
    statements with the asm_volatile_goto macro to avoid issues with older
    toolchains.
    
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a2df42a5371a09cca5a272f1edb29ced625221e
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jul 22 16:03:58 2018 -0700

    hexagon: modify ffs() and fls() to return int
    
    [ Upstream commit 5c41aaad409c097cf1ef74f2c649fed994744ef5 ]
    
    Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
    printk format build warning.  This is due to hexagon's ffs() being
    coded as returning long instead of int.
    
    Fix the printk format warning by changing all of hexagon's ffs() and
    fls() functions to return int instead of long.  The variables that
    they return are already int instead of long.  This return type
    matches the return type in <asm-generic/bitops/>.
    
    ../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
    ../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]
    
    There are no ffs() or fls() allmodconfig build errors after making this
    change.
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Richard Kuo <rkuo@codeaurora.org>
    Cc: linux-hexagon@vger.kernel.org
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Patch-mainline: linux-kernel @ 07/22/2018, 16:03
    Signed-off-by: Richard Kuo <rkuo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2eb3072b2785047aa7cbbd5bcbeb8da7db82ecf7
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Jul 20 20:17:35 2018 -0700

    arch/hexagon: fix kernel/dma.c build warning
    
    [ Upstream commit 200f351e27f014fcbf69b544b0b4b72aeaf45fd3 ]
    
    Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
    to unsigned long to match the function parameter type.
    
    ../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
    ../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 'gen_pool_add' makes integer from pointer without a cast [enabled by default]
    ../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but argument is of type 'void *'
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Cc: linux-sh@vger.kernel.org
    Patch-mainline: linux-kernel @ 07/20/2018, 20:17
    [rkuo@codeaurora.org: fixed architecture name]
    Signed-off-by: Richard Kuo <rkuo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1484d4ff277007f1a852e4c02f4edc5eb3e1e7d6
Author: Joe Thornber <ejt@redhat.com>
Date:   Mon Sep 10 16:50:09 2018 +0100

    dm thin metadata: try to avoid ever aborting transactions
    
    [ Upstream commit 3ab91828166895600efd9cdc3a0eb32001f7204a ]
    
    Committing a transaction can consume some metadata of it's own, we now
    reserve a small amount of metadata to cover this.  Free metadata
    reported by the kernel will not include this reserve.
    
    If any of the reserve has been used after a commit we enter a new
    internal state PM_OUT_OF_METADATA_SPACE.  This is reported as
    PM_READ_ONLY, so no userland changes are needed.  If the metadata
    device is resized the pool will move back to PM_WRITE.
    
    These changes mean we never need to abort and rollback a transaction due
    to running out of metadata space.  This is particularly important
    because there have been a handful of reports of data corruption against
    DM thin-provisioning that can all be attributed to the thin-pool having
    ran out of metadata space.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e9054e75d22d9c3087d100397cc4eae9be53bf7
Author: Jacek Tomaka <jacek.tomaka@poczta.fm>
Date:   Thu Aug 2 09:38:30 2018 +0800

    perf/x86/intel: Add support/quirk for the MISPREDICT bit on Knights Landing CPUs
    
    [ Upstream commit 16160c1946b702dcfa95ef63389a56deb2f1c7cb ]
    
    Problem: perf did not show branch predicted/mispredicted bit in brstack.
    
    Output of perf -F brstack for profile collected
    
    Before:
    
     0x4fdbcd/0x4fdc03/-/-/-/0
     0x45f4c1/0x4fdba0/-/-/-/0
     0x45f544/0x45f4bb/-/-/-/0
     0x45f555/0x45f53c/-/-/-/0
     0x7f66901cc24b/0x45f555/-/-/-/0
     0x7f66901cc22e/0x7f66901cc23d/-/-/-/0
     0x7f66901cc1ff/0x7f66901cc20f/-/-/-/0
     0x7f66901cc1e8/0x7f66901cc1fc/-/-/-/0
    
    After:
    
     0x4fdbcd/0x4fdc03/P/-/-/0
     0x45f4c1/0x4fdba0/P/-/-/0
     0x45f544/0x45f4bb/P/-/-/0
     0x45f555/0x45f53c/P/-/-/0
     0x7f66901cc24b/0x45f555/P/-/-/0
     0x7f66901cc22e/0x7f66901cc23d/P/-/-/0
     0x7f66901cc1ff/0x7f66901cc20f/P/-/-/0
     0x7f66901cc1e8/0x7f66901cc1fc/P/-/-/0
    
    Cause:
    
    As mentioned in Software Development Manual vol 3, 17.4.8.1,
    IA32_PERF_CAPABILITIES[5:0] indicates the format of the address that is
    stored in the LBR stack. Knights Landing reports 1 (LBR_FORMAT_LIP) as
    its format. Despite that, registers containing FROM address of the branch,
    do have MISPREDICT bit but because of the format indicated in
    IA32_PERF_CAPABILITIES[5:0], LBR did not read MISPREDICT bit.
    
    Solution:
    
    Teach LBR about above Knights Landing quirk and make it read MISPREDICT bit.
    
    Signed-off-by: Jacek Tomaka <jacek.tomaka@poczta.fm>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20180802013830.10600-1-jacekt@dugeo.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36918e899e3cd1f920b45cbb3d8b4c90f9e952a1
Author: Netanel Belgazal <netanel@amazon.com>
Date:   Sun Sep 9 08:15:25 2018 +0000

    net: ena: fix missing calls to READ_ONCE
    
    [ Upstream commit 28abf4e9c9201eda5c4d29ea609d07e877b464b8 ]
    
    Add READ_ONCE calls where necessary (for example when iterating
    over a memory field that gets updated by the hardware).
    
    Signed-off-by: Netanel Belgazal <netanel@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e2cc5bd61fe7f105657611c3105c0f2bddc120c
Author: Netanel Belgazal <netanel@amazon.com>
Date:   Sun Sep 9 08:15:21 2018 +0000

    net: ena: fix driver when PAGE_SIZE == 64kB
    
    [ Upstream commit ef5b0771d247379c90c8bf1332ff32f7f74bff7f ]
    
    The buffer length field in the ena rx descriptor is 16 bit, and the
    current driver passes a full page in each ena rx descriptor.
    When PAGE_SIZE equals 64kB or more, the buffer length field becomes
    zero.
    To solve this issue, limit the ena Rx descriptor to use 16kB even
    when allocating 64kB kernel pages. This change would not impact ena
    device functionality, as 16kB is still larger than maximum MTU.
    
    Signed-off-by: Netanel Belgazal <netanel@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5bdc726e5ffa32d7fbf1a2b646c4e59ac075c09
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Mon Sep 3 13:15:58 2018 +1000

    fs/cifs: suppress a string overflow warning
    
    [ Upstream commit bcfb84a996f6fa90b5e6e2954b2accb7a4711097 ]
    
    A powerpc build of cifs with gcc v8.2.0 produces this warning:
    
    fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
    fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
       strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Since we are already doing a strlen() on the source, change the strncpy
    to a memcpy().
    
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3941dbe190ba7ba704a7c932aef20b87e5ac199c
Author: Heinz Mauelshagen <heinzm@redhat.com>
Date:   Thu Sep 6 18:33:40 2018 +0200

    dm raid: fix rebuild of specific devices by updating superblock
    
    [ Upstream commit c44a5ee803d2b7ed8c2e6ce24a5c4dd60778886e ]
    
    Update superblock when particular devices are requested via rebuild
    (e.g. lvconvert --replace ...) to avoid spurious failure with the "New
    device injected into existing raid set without 'delta_disks' or
    'rebuild' parameter specified" error message.
    
    Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 112d65a51f2bd14b0e090201def35a3a34643217
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Sep 4 15:57:09 2018 +1000

    drm/nouveau/disp: fix DP disable race
    
    [ Upstream commit e04cfdc9b7398c60dbc70212415ea63b6c6a93ae ]
    
    If a HPD pulse signalling the need to retrain the link occurs between
    the KMS driver releasing the output and the supervisor interrupt that
    finishes the teardown, it was possible get a NULL-ptr deref.
    
    Avoid this by marking the link as inactive earlier.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a255bf1e749d7f4556272365c35578e210e4bed
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Sep 4 15:56:57 2018 +1000

    drm/nouveau/TBDdevinit: don't fail when PMU/PRE_OS is missing from VBIOS
    
    [ Upstream commit 0a6986c6595e9afd20ff7280dab36431c1e467f8 ]
    
    This Falcon application doesn't appear to be present on some newer
    systems, so let's not fail init if we can't find it.
    
    TBD: is there a way to determine whether it *should* be there?
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34d54566ae4ab95d9d4c199f0f9b47c8a0afd00d
Author: Daniel Jurgens <danielj@mellanox.com>
Date:   Mon Aug 27 09:09:46 2018 -0500

    net/mlx5: Consider PCI domain in search for next dev
    
    [ Upstream commit df7ddb2396cd162e64aaff9401be05e31e438961 ]
    
    The PCI BDF is not unique. PCI domain must also be considered when
    searching for the next physical device during lag setup. Example below:
    
    mlx5_core 0000:01:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(128) RxCqeCmprss(0)
    mlx5_core 0000:01:00.1: MLX5E: StrdRq(1) RqSz(8) StrdSz(128) RxCqeCmprss(0)
    mlx5_core 0001:01:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(128) RxCqeCmprss(0)
    mlx5_core 0001:01:00.1: MLX5E: StrdRq(1) RqSz(8) StrdSz(128) RxCqeCmprss(0)
    
    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
    Reviewed-by: Aviv Heller <avivh@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f36f3ebdf1e1a211c3be521e187d69a94b30db77
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon Sep 3 03:47:07 2018 -0700

    nvmet-rdma: fix possible bogus dereference under heavy load
    
    [ Upstream commit 8407879c4e0d7731f6e7e905893cecf61a7762c7 ]
    
    Currently we always repost the recv buffer before we send a response
    capsule back to the host. Since ordering is not guaranteed for send
    and recv completions, it is posible that we will receive a new request
    from the host before we got a send completion for the response capsule.
    
    Today, we pre-allocate 2x rsps the length of the queue, but in reality,
    under heavy load there is nothing that is really preventing the gap to
    expand until we exhaust all our rsps.
    
    To fix this, if we don't have any pre-allocated rsps left, we dynamically
    allocate a rsp and make sure to free it when we are done. If under memory
    pressure we fail to allocate a rsp, we silently drop the command and
    wait for the host to retry.
    
    Reported-by: Steve Wise <swise@opengridcomputing.com>
    Tested-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    [hch: dropped a superflous assignment]
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a90a52c51ad46b8c1407b1113aabd8cf6e7c197d
Author: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date:   Wed Aug 15 21:45:37 2018 +0100

    USB: yurex: Check for truncation in yurex_read()
    
    [ Upstream commit 14427b86837a4baf1c121934c6599bdb67dfa9fc ]
    
    snprintf() always returns the full length of the string it could have
    printed, even if it was truncated because the buffer was too small.
    So in case the counter value is truncated, we will over-read from
    in_buffer and over-write to the caller's buffer.
    
    I don't think it's actually possible for this to happen, but in case
    truncation occurs, WARN and return -EIO.
    
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c423318f07ccde11162e40f2bd4c47bbe9a00cf
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Aug 18 10:12:08 2018 +0200

    HID: sensor-hub: Restore fixup for Lenovo ThinkPad Helix 2 sensor hub report
    
    [ Upstream commit ade573eb1e03d1ee5abcb3359b1259469ab6e8ed ]
    
    Commit b0f847e16c1e ("HID: hid-sensor-hub: Force logical minimum to 1 for
    power and report state") not only replaced the descriptor fixup done for
    devices with the HID_SENSOR_HUB_ENUM_QUIRK with a generic fix, but also
    accidentally removed the unrelated descriptor fixup for the Lenovo ThinkPad
    Helix 2 sensor hub. This commit restores this fixup.
    
    Restoring this fixup not only fixes the Lenovo ThinkPad Helix 2's sensors,
    but also the Lenovo ThinkPad 8's sensors.
    
    Fixes: b0f847e16c1e ("HID: hid-sensor-hub: Force logical minimum ...")
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: Fernando D S Lima <fernandodsl@gmail.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4da7122031726329bd444ad51d9944c821c9af4
Author: Jann Horn <jannh@google.com>
Date:   Mon Sep 3 18:54:14 2018 +0200

    RDMA/ucma: check fd type in ucma_migrate_id()
    
    [ Upstream commit 0d23ba6034b9cf48b8918404367506da3e4b3ee5 ]
    
    The current code grabs the private_data of whatever file descriptor
    userspace has supplied and implicitly casts it to a `struct ucma_file *`,
    potentially causing a type confusion.
    
    This is probably fine in practice because the pointer is only used for
    comparisons, it is never actually dereferenced; and even in the
    comparisons, it is unlikely that a file from another filesystem would have
    a ->private_data pointer that happens to also be valid in this context.
    But ->private_data is not always guaranteed to be a valid pointer to an
    object owned by the file's filesystem; for example, some filesystems just
    cram numbers in there.
    
    Check the type of the supplied file descriptor to be safe, analogous to how
    other places in the kernel do it.
    
    Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60ea8815d6e82dd7b35944f0b563c70227304118
Author: Matt Ranostay <matt.ranostay@konsulko.com>
Date:   Sat Aug 25 02:00:48 2018 -0700

    Revert "iio: temperature: maxim_thermocouple: add MAX31856 part"
    
    [ Upstream commit 65099ea85e885c3ea1272eca8774b771419d8ce8 ]
    
    This reverts commit 535fba29b3e1afef4ba201b3c69a6992583ec0bd.
    
    Seems the submitter (er me, hang head in shame) didn't look at the datasheet
    enough to see that the registers are quite different.
    
    This needs to be reverted because a) would never work b) to open it  be added
    to a Maxim RTDs (Resistance Temperature Detectors) under development by author
    
    Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1173678a4f4ad4f7fd5f2a88f522ef98418c9e87
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sun Aug 26 02:35:44 2018 +0900

    netfilter: nf_tables: release chain in flushing set
    
    [ Upstream commit 7acfda539c0b9636a58bfee56abfb3aeee806d96 ]
    
    When element of verdict map is deleted, the delete routine should
    release chain. however, flush element of verdict map routine doesn't
    release chain.
    
    test commands:
       %nft add table ip filter
       %nft add chain ip filter c1
       %nft add map ip filter map1 { type ipv4_addr : verdict \; }
       %nft add element ip filter map1 { 1 : jump c1 }
       %nft flush map ip filter map1
       %nft flush ruleset
    
    splat looks like:
    [ 4895.170899] kernel BUG at net/netfilter/nf_tables_api.c:1415!
    [ 4895.178114] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
    [ 4895.178880] CPU: 0 PID: 1670 Comm: nft Not tainted 4.18.0+ #55
    [ 4895.178880] RIP: 0010:nf_tables_chain_destroy.isra.28+0x39/0x220 [nf_tables]
    [ 4895.178880] Code: fc ff df 53 48 89 fb 48 83 c7 50 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 09 3c 03 7f 05 e8 3e 4c 25 e1 8b 43 50 85 c0 74 02 <0f> 0b 48 89 da 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02
    [ 4895.228342] RSP: 0018:ffff88010b98f4c0 EFLAGS: 00010202
    [ 4895.234841] RAX: 0000000000000001 RBX: ffff8801131c6968 RCX: ffff8801146585b0
    [ 4895.234841] RDX: 1ffff10022638d37 RSI: ffff8801191a9348 RDI: ffff8801131c69b8
    [ 4895.234841] RBP: ffff8801146585a8 R08: 1ffff1002323526a R09: 0000000000000000
    [ 4895.234841] R10: 0000000000000000 R11: 0000000000000000 R12: dead000000000200
    [ 4895.234841] R13: dead000000000100 R14: ffffffffa3638af8 R15: dffffc0000000000
    [ 4895.234841] FS:  00007f6d188e6700(0000) GS:ffff88011b600000(0000) knlGS:0000000000000000
    [ 4895.234841] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 4895.234841] CR2: 00007ffe72b8df88 CR3: 000000010e2d4000 CR4: 00000000001006f0
    [ 4895.234841] Call Trace:
    [ 4895.234841]  nf_tables_commit+0x2704/0x2c70 [nf_tables]
    [ 4895.234841]  ? nfnetlink_rcv_batch+0xa4f/0x11b0 [nfnetlink]
    [ 4895.234841]  ? nf_tables_setelem_notify.constprop.48+0x1a0/0x1a0 [nf_tables]
    [ 4895.323824]  ? __lock_is_held+0x9d/0x130
    [ 4895.323824]  ? kasan_unpoison_shadow+0x30/0x40
    [ 4895.333299]  ? kasan_kmalloc+0xa9/0xc0
    [ 4895.333299]  ? kmem_cache_alloc_trace+0x2c0/0x310
    [ 4895.333299]  ? nfnetlink_rcv_batch+0xa4f/0x11b0 [nfnetlink]
    [ 4895.333299]  nfnetlink_rcv_batch+0xdb9/0x11b0 [nfnetlink]
    [ 4895.333299]  ? debug_show_all_locks+0x290/0x290
    [ 4895.333299]  ? nfnetlink_net_init+0x150/0x150 [nfnetlink]
    [ 4895.333299]  ? sched_clock_cpu+0xe5/0x170
    [ 4895.333299]  ? sched_clock_local+0xff/0x130
    [ 4895.333299]  ? sched_clock_cpu+0xe5/0x170
    [ 4895.333299]  ? find_held_lock+0x39/0x1b0
    [ 4895.333299]  ? sched_clock_local+0xff/0x130
    [ 4895.333299]  ? memset+0x1f/0x40
    [ 4895.333299]  ? nla_parse+0x33/0x260
    [ 4895.333299]  ? ns_capable_common+0x6e/0x110
    [ 4895.333299]  nfnetlink_rcv+0x2c0/0x310 [nfnetlink]
    [ ... ]
    
    Fixes: 591054469b3e ("netfilter: nf_tables: revisit chain/object refcounting from elements")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c00f01c402115960bb9592ed842b42964cb3c069
Author: Sandipan Das <sandipan@linux.ibm.com>
Date:   Tue Aug 28 14:38:48 2018 +0530

    perf probe powerpc: Ignore SyS symbols irrespective of endianness
    
    [ Upstream commit fa694160cca6dbba17c57dc7efec5f93feaf8795 ]
    
    This makes sure that the SyS symbols are ignored for any powerpc system,
    not just the big endian ones.
    
    Reported-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
    Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
    Fixes: fb6d59423115 ("perf probe ppc: Use the right prefix when ignoring SyS symbols on ppc")
    Link: http://lkml.kernel.org/r/20180828090848.1914-1-sandipan@linux.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4095fd29fee754299221613d0646a93636c48df0
Author: Chris Phlipot <cphlipot0@gmail.com>
Date:   Tue Aug 28 23:19:54 2018 -0700

    perf util: Fix bad memory access in trace info.
    
    [ Upstream commit a72f64261359b7451f8478f2a2bf357b4e6c757f ]
    
    In the write to the output_fd in the error condition of
    record_saved_cmdline(), we are writing 8 bytes from a memory location on
    the stack that contains a primitive that is only 4 bytes in size.
    Change the primitive to 8 bytes in size to match the size of the write
    in order to avoid reading unknown memory from the stack.
    
    Signed-off-by: Chris Phlipot <cphlipot0@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20180829061954.18871-1-cphlipot0@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d7bc329c123bbdc7db20a02e20e788a91c7c775
Author: Hisao Tanabe <xtanabe@gmail.com>
Date:   Sat Aug 25 00:45:56 2018 +0900

    perf evsel: Fix potential null pointer dereference in perf_evsel__new_idx()
    
    [ Upstream commit fd8d2702791a970c751f8b526a17d8e725a05b46 ]
    
    If evsel is NULL, we should return NULL to avoid a NULL pointer
    dereference a bit later in the code.
    
    Signed-off-by: Hisao Tanabe <xtanabe@gmail.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Fixes: 03e0a7df3efd ("perf tools: Introduce bpf-output event")
    LPU-Reference: 20180824154556.23428-1-xtanabe@gmail.com
    Link: https://lkml.kernel.org/n/tip-e5plzjhx6595a5yjaf22jss3@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b98b7eeb45d92a3037dc4258b98b344c73f31b9
Author: Nilesh Javali <nilesh.javali@cavium.com>
Date:   Wed Aug 29 23:55:53 2018 -0700

    scsi: qedi: Add the CRC size within iSCSI NVM image
    
    [ Upstream commit c77a2fa3ff8f73d1a485e67e6f81c64823739d59 ]
    
    The QED driver commit, 1ac4329a1cff ("qed: Add configuration information
    to register dump and debug data"), removes the CRC length validation
    causing nvm_get_image failure while loading qedi driver:
    
    [qed_mcp_get_nvm_image:2700(host_10-0)]Image [0] is too big - 00006008 bytes
    where only 00006004 are available
    [qedi_get_boot_info:2253]:10: Could not get NVM image. ret = -12
    
    Hence add and adjust the CRC size to iSCSI NVM image to read boot info at
    qedi load time.
    
    Signed-off-by: Nilesh Javali <nilesh.javali@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd44c35cc16c4307409c180c35e29c64809289ac
Author: Vincent Pelletier <plr.vincent@gmail.com>
Date:   Mon Aug 27 14:45:15 2018 -0500

    scsi: iscsi: target: Set conn->sess to NULL when iscsi_login_set_conn_values fails
    
    [ Upstream commit 7915919bb94e12460c58e27c708472e6f85f6699 ]
    
    Fixes a use-after-free reported by KASAN when later
    iscsi_target_login_sess_out gets called and it tries to access
    conn->sess->se_sess:
    
    Disabling lock debugging due to kernel taint
    iSCSI Login timeout on Network Portal [::]:3260
    iSCSI Login negotiation failed.
    ==================================================================
    BUG: KASAN: use-after-free in
    iscsi_target_login_sess_out.cold.12+0x58/0xff [iscsi_target_mod]
    Read of size 8 at addr ffff880109d070c8 by task iscsi_np/980
    
    CPU: 1 PID: 980 Comm: iscsi_np Tainted: G           O
    4.17.8kasan.sess.connops+ #4
    Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB,
    BIOS 5.6.5 05/19/2014
    Call Trace:
     dump_stack+0x71/0xac
     print_address_description+0x65/0x22e
     ? iscsi_target_login_sess_out.cold.12+0x58/0xff [iscsi_target_mod]
     kasan_report.cold.6+0x241/0x2fd
     iscsi_target_login_sess_out.cold.12+0x58/0xff [iscsi_target_mod]
     iscsi_target_login_thread+0x1086/0x1710 [iscsi_target_mod]
     ? __sched_text_start+0x8/0x8
     ? iscsi_target_login_sess_out+0x250/0x250 [iscsi_target_mod]
     ? __kthread_parkme+0xcc/0x100
     ? parse_args.cold.14+0xd3/0xd3
     ? iscsi_target_login_sess_out+0x250/0x250 [iscsi_target_mod]
     kthread+0x1a0/0x1c0
     ? kthread_bind+0x30/0x30
     ret_from_fork+0x35/0x40
    
    Allocated by task 980:
     kasan_kmalloc+0xbf/0xe0
     kmem_cache_alloc_trace+0x112/0x210
     iscsi_target_login_thread+0x816/0x1710 [iscsi_target_mod]
     kthread+0x1a0/0x1c0
     ret_from_fork+0x35/0x40
    
    Freed by task 980:
     __kasan_slab_free+0x125/0x170
     kfree+0x90/0x1d0
     iscsi_target_login_thread+0x1577/0x1710 [iscsi_target_mod]
     kthread+0x1a0/0x1c0
     ret_from_fork+0x35/0x40
    
    The buggy address belongs to the object at ffff880109d06f00
     which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 456 bytes inside of
     512-byte region [ffff880109d06f00, ffff880109d07100)
    The buggy address belongs to the page:
    page:ffffea0004274180 count:1 mapcount:0 mapping:0000000000000000
    index:0x0 compound_mapcount: 0
    flags: 0x17fffc000008100(slab|head)
    raw: 017fffc000008100 0000000000000000 0000000000000000 00000001000c000c
    raw: dead000000000100 dead000000000200 ffff88011b002e00 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff880109d06f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff880109d07000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff880109d07080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                  ^
     ffff880109d07100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff880109d07180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ==================================================================
    
    Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
    [rebased against idr/ida changes and to handle ret review comments from Matthew]
    Signed-off-by: Mike Christie <mchristi@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Reviewed-by: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6515e0f915b747593a863b60486e04d8af1e520
Author: Harry Mallon <hjmallon@gmail.com>
Date:   Tue Aug 28 22:51:29 2018 +0100

    HID: hid-saitek: Add device ID for RAT 7 Contagion
    
    [ Upstream commit 43822c98f2ebb2cbd5e467ab72bbcdae7f0caa22 ]
    
    Signed-off-by: Harry Mallon <hjmallon@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81c823c22355df0f4133637b6abd83621c7555a7
Author: Anton Vasilyev <vasilyev@ispras.ru>
Date:   Tue Aug 7 14:44:48 2018 +0300

    usb: gadget: fotg210-udc: Fix memory leak of fotg210->ep[i]
    
    [ Upstream commit c37bd52836296ecc9a0fc8060b819089aebdbcde ]
    
    There is no deallocation of fotg210->ep[i] elements, allocated at
    fotg210_udc_probe.
    
    The patch adds deallocation of fotg210->ep array elements and simplifies
    error path of fotg210_udc_probe().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6cc0ba2cbf4b4e04f9531f256496a07e82b1177
Author: Sean O'Brien <seobrien@chromium.org>
Date:   Mon Aug 27 13:02:15 2018 -0700

    HID: add support for Apple Magic Keyboards
    
    [ Upstream commit ee345492437043a79db058a3d4f029ebcb52089a ]
    
    USB device
            Vendor 05ac (Apple)
            Device 026c (Magic Keyboard with Numeric Keypad)
    
    Bluetooth devices
            Vendor 004c (Apple)
            Device 0267 (Magic Keyboard)
            Device 026c (Magic Keyboard with Numeric Keypad)
    
    Support already exists for the Magic Keyboard over USB connection.
    Add support for the Magic Keyboard over Bluetooth connection, and for
    the Magic Keyboard with Numeric Keypad over Bluetooth and USB
    connection.
    
    Signed-off-by: Sean O'Brien <seobrien@chromium.org>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b969656b46626a674232c0eadf92a394b89df07c
Author: Martin Willi <martin@strongswan.org>
Date:   Wed Aug 22 10:27:17 2018 +0200

    netfilter: xt_cluster: add dependency on conntrack module
    
    [ Upstream commit c1dc2912059901f97345d9e10c96b841215fdc0f ]
    
    The cluster match requires conntrack for matching packets. If the
    netns does not have conntrack hooks registered, the match does not
    work at all.
    
    Implicitly load the conntrack hook for the family, exactly as many
    other extensions do. This ensures that the match works even if the
    hooks have not been registered by other means.
    
    Signed-off-by: Martin Willi <martin@strongswan.org>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10fdfea70d4667abf3724c31443e5d5922fecebd
Author: Jann Horn <jannh@google.com>
Date:   Fri Oct 5 18:17:59 2018 +0200

    bpf: 32-bit RSH verification must truncate input before the ALU op
    
    commit b799207e1e1816b09e7a5920fbb2d5fcf6edd681 upstream.
    
    When I wrote commit 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification"), I
    assumed that, in order to emulate 64-bit arithmetic with 32-bit logic, it
    is sufficient to just truncate the output to 32 bits; and so I just moved
    the register size coercion that used to be at the start of the function to
    the end of the function.
    
    That assumption is true for almost every op, but not for 32-bit right
    shifts, because those can propagate information towards the least
    significant bit. Fix it by always truncating inputs for 32-bit ops to 32
    bits.
    
    Also get rid of the coerce_reg_to_size() after the ALU op, since that has
    no effect.
    
    Fixes: 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification")
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcc89aaf5a8dbe431daa026ad41d87a139fd5542
Author: Daniel Black <daniel@linux.ibm.com>
Date:   Fri Oct 5 15:52:19 2018 -0700

    mm: madvise(MADV_DODUMP): allow hugetlbfs pages
    
    commit d41aa5252394c065d1f04d1ceea885b70d00c9c6 upstream.
    
    Reproducer, assuming 2M of hugetlbfs available:
    
    Hugetlbfs mounted, size=2M and option user=testuser
    
      # mount | grep ^hugetlbfs
      hugetlbfs on /dev/hugepages type hugetlbfs (rw,pagesize=2M,user=dan)
      # sysctl vm.nr_hugepages=1
      vm.nr_hugepages = 1
      # grep Huge /proc/meminfo
      AnonHugePages:         0 kB
      ShmemHugePages:        0 kB
      HugePages_Total:       1
      HugePages_Free:        1
      HugePages_Rsvd:        0
      HugePages_Surp:        0
      Hugepagesize:       2048 kB
      Hugetlb:            2048 kB
    
    Code:
    
      #include <sys/mman.h>
      #include <stddef.h>
      #define SIZE 2*1024*1024
      int main()
      {
        void *ptr;
        ptr = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_HUGETLB | MAP_ANONYMOUS, -1, 0);
        madvise(ptr, SIZE, MADV_DONTDUMP);
        madvise(ptr, SIZE, MADV_DODUMP);
      }
    
    Compile and strace:
    
      mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = 0x7ff7c9200000
      madvise(0x7ff7c9200000, 2097152, MADV_DONTDUMP) = 0
      madvise(0x7ff7c9200000, 2097152, MADV_DODUMP) = -1 EINVAL (Invalid argument)
    
    hugetlbfs pages have VM_DONTEXPAND in the VmFlags driver pages based on
    author testing with analysis from Florian Weimer[1].
    
    The inclusion of VM_DONTEXPAND into the VM_SPECIAL defination was a
    consequence of the large useage of VM_DONTEXPAND in device drivers.
    
    A consequence of [2] is that VM_DONTEXPAND marked pages are unable to be
    marked DODUMP.
    
    A user could quite legitimately madvise(MADV_DONTDUMP) their hugetlbfs
    memory for a while and later request that madvise(MADV_DODUMP) on the same
    memory.  We correct this omission by allowing madvice(MADV_DODUMP) on
    hugetlbfs pages.
    
    [1] https://stackoverflow.com/questions/52548260/madvisedodump-on-the-same-ptr-size-as-a-successful-madvisedontdump-fails-wit
    [2] commit 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers")
    
    Link: http://lkml.kernel.org/r/20180930054629.29150-1-daniel@linux.ibm.com
    Link: https://lists.launchpad.net/maria-discuss/msg05245.html
    Fixes: 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers")
    Reported-by: Kenneth Penza <kpenza@gmail.com>
    Signed-off-by: Daniel Black <daniel@linux.ibm.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee0516c4a1fec5d52d2d7702d22787fca1ed8fc0
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Tue Sep 4 15:45:51 2018 -0700

    tools/vm/page-types.c: fix "defined but not used" warning
    
    [ Upstream commit 7ab660f8baecfe26c1c267fa8e64d2073feae2bb ]
    
    debugfs_known_mountpoints[] is not used any more, so let's remove it.
    
    Link: http://lkml.kernel.org/r/1535102651-19418-1-git-send-email-n-horiguchi@ah.jp.nec.com
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cbf015b971c8bf9bb9b6796dc92d78b51bc62b5
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Tue Sep 4 15:45:48 2018 -0700

    tools/vm/slabinfo.c: fix sign-compare warning
    
    [ Upstream commit 904506562e0856f2535d876407d087c9459d345b ]
    
    Currently we get the following compiler warning:
    
        slabinfo.c:854:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
           if (s->object_size < min_objsize)
                              ^
    
    due to the mismatch of signed/unsigned comparison.  ->object_size and
    ->slab_size are never expected to be negative, so let's define them as
    unsigned int.
    
    [n-horiguchi@ah.jp.nec.com: convert everything - none of these can be negative]
      Link: http://lkml.kernel.org/r/20180826234947.GA9787@hori1.linux.bs1.fc.nec.co.jp
    Link: http://lkml.kernel.org/r/1535103134-20239-1-git-send-email-n-horiguchi@ah.jp.nec.com
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27c4ad84fd015d1a4e9dae5f949e19507afb75c1
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Fri Aug 31 11:31:13 2018 +0300

    mac80211: shorten the IBSS debug messages
    
    [ Upstream commit c6e57b3896fc76299913b8cfd82d853bee8a2c84 ]
    
    When tracing is enabled, all the debug messages are recorded and must
    not exceed MAX_MSG_LEN (100) columns. Longer debug messages grant the
    user with:
    
    WARNING: CPU: 3 PID: 32642 at /tmp/wifi-core-20180806094828/src/iwlwifi-stack-dev/net/mac80211/./trace_msg.h:32 trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
    Workqueue: phy1 ieee80211_iface_work [mac80211]
     RIP: 0010:trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
     Call Trace:
      __sdata_dbg+0xbd/0x120 [mac80211]
      ieee80211_ibss_rx_queued_mgmt+0x15f/0x510 [mac80211]
      ieee80211_iface_work+0x21d/0x320 [mac80211]
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e132eb09fdd2b8a2db7af79e01b2d798604f63d9
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Fri Aug 31 11:31:12 2018 +0300

    mac80211: don't Tx a deauth frame if the AP forbade Tx
    
    [ Upstream commit 6c18b27d6e5c6a7206364eae2b47bc8d8b2fa68f ]
    
    If the driver fails to properly prepare for the channel
    switch, mac80211 will disconnect. If the CSA IE had mode
    set to 1, it means that the clients are not allowed to send
    any Tx on the current channel, and that includes the
    deauthentication frame.
    
    Make sure that we don't send the deauthentication frame in
    this case.
    
    In iwlwifi, this caused a failure to flush queues since the
    firmware already closed the queues after having parsed the
    CSA IE. Then mac80211 would wait until the deauthentication
    frame would go out (drv_flush(drop=false)) and that would
    never happen.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8788737af389eeb82dea693abf726bca61971bfc
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Fri Aug 31 11:31:10 2018 +0300

    mac80211: Fix station bandwidth setting after channel switch
    
    [ Upstream commit 0007e94355fdb71a1cf5dba0754155cba08f0666 ]
    
    When performing a channel switch flow for a managed interface, the
    flow did not update the bandwidth of the AP station and the rate
    scale algorithm. In case of a channel width downgrade, this would
    result with the rate scale algorithm using a bandwidth that does not
    match the interface channel configuration.
    
    Fix this by updating the AP station bandwidth and rate scaling algorithm
    before the actual channel change in case of a bandwidth downgrade, or
    after the actual channel change in case of a bandwidth upgrade.
    
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37cdc7e35ae4b4499826216ee54499f572bc6eb4
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Fri Aug 31 11:31:06 2018 +0300

    mac80211: fix a race between restart and CSA flows
    
    [ Upstream commit f3ffb6c3a28963657eb8b02a795d75f2ebbd5ef4 ]
    
    We hit a problem with iwlwifi that was caused by a bug in
    mac80211. A bug in iwlwifi caused the firwmare to crash in
    certain cases in channel switch. Because of that bug,
    drv_pre_channel_switch would fail and trigger the restart
    flow.
    Now we had the hw restart worker which runs on the system's
    workqueue and the csa_connection_drop_work worker that runs
    on mac80211's workqueue that can run together. This is
    obviously problematic since the restart work wants to
    reconfigure the connection, while the csa_connection_drop_work
    worker does the exact opposite: it tries to disconnect.
    
    Fix this by cancelling the csa_connection_drop_work worker
    in the restart worker.
    
    Note that this can sound racy: we could have:
    
    driver   iface_work   CSA_work   restart_work
    +++++++++++++++++++++++++++++++++++++++++++++
                  |
     <--drv_cs ---|
    <FW CRASH!>
    -CS FAILED-->
                  |                       |
                  |                 cancel_work(CSA)
               schedule                   |
               CSA work                   |
                             |            |
                            Race between those 2
    
    But this is not possible because we flush the workqueue
    in the restart worker before we cancel the CSA worker.
    That would be bullet proof if we could guarantee that
    we schedule the CSA worker only from the iface_work
    which runs on the workqueue (and not on the system's
    workqueue), but unfortunately we do have an instance
    in which we schedule the CSA work outside the context
    of the workqueue (ieee80211_chswitch_done).
    
    Note also that we should probably cancel other workers
    like beacon_connection_loss_work and possibly others
    for different types of interfaces, at the very least,
    IBSS should suffer from the exact same problem, but for
    now, do the minimum to fix the actual bug that was actually
    experienced and reproduced.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fa55f6d29fd1bc3fa366751cc7ac90975b07ca2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 31 11:10:55 2018 +0300

    cfg80211: fix a type issue in ieee80211_chandef_to_operating_class()
    
    [ Upstream commit 8442938c3a2177ba16043b3a935f2c78266ad399 ]
    
    The "chandef->center_freq1" variable is a u32 but "freq" is a u16 so we
    are truncating away the high bits.  I noticed this bug because in commit
    9cf0a0b4b64a ("cfg80211: Add support for 60GHz band channels 5 and 6")
    we made "freq <= 56160 + 2160 * 6" a valid requency when before it was
    only "freq <= 56160 + 2160 * 4" that was valid.  It introduces a static
    checker warning:
    
        net/wireless/util.c:1571 ieee80211_chandef_to_operating_class()
        warn: always true condition '(freq <= 56160 + 2160 * 6) => (0-u16max <= 69120)'
    
    But really we probably shouldn't have been truncating the high bits
    away to begin with.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43a01409ef4c401c955d4a3f55523a6a77fdee5d
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Fri Aug 31 01:04:13 2018 +0200

    mac80211: fix an off-by-one issue in A-MSDU max_subframe computation
    
    [ Upstream commit 66eb02d839e8495ae6b612e2d09ff599374b80e2 ]
    
    Initialize 'n' to 2 in order to take into account also the first
    packet in the estimation of max_subframe limit for a given A-MSDU
    since frag_tail pointer is NULL when ieee80211_amsdu_aggregate
    routine analyzes the second frame.
    
    Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25cb8544342a23784f89a5e856c27509f30d99be
Author: Jon Kuhn <jkuhn@barracuda.com>
Date:   Mon Jul 9 14:33:14 2018 +0000

    fs/cifs: don't translate SFM_SLASH (U+F026) to backslash
    
    [ Upstream commit c15e3f19a6d5c89b1209dc94b40e568177cb0921 ]
    
    When a Mac client saves an item containing a backslash to a file server
    the backslash is represented in the CIFS/SMB protocol as as U+F026.
    Before this change, listing a directory containing an item with a
    backslash in its name will return that item with the backslash
    represented with a true backslash character (U+005C) because
    convert_sfm_character mapped U+F026 to U+005C when interpretting the
    CIFS/SMB protocol response.  However, attempting to open or stat the
    path using a true backslash will result in an error because
    convert_to_sfm_char does not map U+005C back to U+F026 causing the
    CIFS/SMB request to be made with the backslash represented as U+005C.
    
    This change simply prevents the U+F026 to U+005C conversion from
    happenning.  This is analogous to how the code does not do any
    translation of UNI_SLASH (U+F000).
    
    Signed-off-by: Jon Kuhn <jkuhn@barracuda.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8590e6fecb5e672e522daa840f01e33272c13b88
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Sat Sep 1 20:11:05 2018 +0800

    net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx()
    
    [ Upstream commit 16fe10cf92783ed9ceb182d6ea2b8adf5e8ec1b8 ]
    
    The kernel module may sleep with holding a spinlock.
    
    The function call paths (from bottom to top) in Linux-4.16 are:
    
    [FUNC] usleep_range
    drivers/net/ethernet/cadence/macb_main.c, 648:
            usleep_range in macb_halt_tx
    drivers/net/ethernet/cadence/macb_main.c, 730:
            macb_halt_tx in macb_tx_error_task
    drivers/net/ethernet/cadence/macb_main.c, 721:
            _raw_spin_lock_irqsave in macb_tx_error_task
    
    To fix this bug, usleep_range() is replaced with udelay().
    
    This bug is found by my static analysis tool DSAC.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b08d15cc921f9bdd472dc4b264998e88cd7d0071
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Fri Aug 31 23:30:48 2018 +0900

    i2c: uniphier-f: issue STOP only for last message or I2C_M_STOP
    
    [ Upstream commit 4c85609b08c4761eca0a40fd7beb06bc650f252d ]
    
    This driver currently emits a STOP if the next message is not
    I2C_MD_RD.  It should not do it because it disturbs the I2C_RDWR
    ioctl, where read/write transactions are combined without STOP
    between.
    
    Issue STOP only when the message is the last one _or_ flagged with
    I2C_M_STOP.
    
    Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82fc9c6b7b9a355b3e794386c7630a076d762072
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Fri Aug 31 23:30:47 2018 +0900

    i2c: uniphier: issue STOP only for last message or I2C_M_STOP
    
    [ Upstream commit 38f5d8d8cbb2ffa2b54315118185332329ec891c ]
    
    This driver currently emits a STOP if the next message is not
    I2C_MD_RD.  It should not do it because it disturbs the I2C_RDWR
    ioctl, where read/write transactions are combined without STOP
    between.
    
    Issue STOP only when the message is the last one _or_ flagged with
    I2C_M_STOP.
    
    Fixes: dd6fd4a32793 ("i2c: uniphier: add UniPhier FIFO-less I2C driver")
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da26e5729c04de59b41da0e245cae3742bfaaefb
Author: Xiao Ni <xni@redhat.com>
Date:   Thu Aug 30 15:57:09 2018 +0800

    RAID10 BUG_ON in raise_barrier when force is true and conf->barrier is 0
    
    [ Upstream commit 1d0ffd264204eba1861865560f1f7f7a92919384 ]
    
    In raid10 reshape_request it gets max_sectors in read_balance. If the underlayer disks
    have bad blocks, the max_sectors is less than last. It will call goto read_more many
    times. It calls raise_barrier(conf, sectors_done != 0) every time. In this condition
    sectors_done is not 0. So the value passed to the argument force of raise_barrier is
    true.
    
    In raise_barrier it checks conf->barrier when force is true. If force is true and
    conf->barrier is 0, it panic. In this case reshape_request submits bio to under layer
    disks. And in the callback function of the bio it calls lower_barrier. If the bio
    finishes before calling raise_barrier again, it can trigger the BUG_ON.
    
    Add one pair of raise_barrier/lower_barrier to fix this bug.
    
    Signed-off-by: Xiao Ni <xni@redhat.com>
    Suggested-by: Neil Brown <neilb@suse.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36fadeb87be802a609f03564e950a9f50b9e3855
Author: Shaohua Li <shli@fb.com>
Date:   Wed Aug 29 11:05:42 2018 -0700

    md/raid5-cache: disable reshape completely
    
    [ Upstream commit e254de6bcf3f5b6e78a92ac95fb91acef8adfe1a ]
    
    We don't support reshape yet if an array supports log device. Previously we
    determine the fact by checking ->log. However, ->log could be NULL after a log
    device is removed, but the array is still marked to support log device. Don't
    allow reshape in this case too. User can disable log device support by setting
    'consistency_policy' to 'resync' then do reshape.
    
    Reported-by: Xiao Ni <xni@redhat.com>
    Tested-by: Xiao Ni <xni@redhat.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc492842b7001b299299ffafe078ba5777096edd
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Aug 30 13:52:38 2018 -0700

    ARC: atomics: unbork atomic_fetch_##op()
    
    [ Upstream commit 3fcbb8260a87efb691d837e8cd24e81f65b3eb70 ]
    
    In 4.19-rc1, Eugeniy reported weird boot and IO errors on ARC HSDK
    
    | INFO: task syslogd:77 blocked for more than 10 seconds.
    |       Not tainted 4.19.0-rc1-00007-gf213acea4e88 #40
    | "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
    | message.
    | syslogd         D    0    77     76 0x00000000
    |
    | Stack Trace:
    |  __switch_to+0x0/0xac
    |  __schedule+0x1b2/0x730
    |  io_schedule+0x5c/0xc0
    |  __lock_page+0x98/0xdc
    |  find_lock_entry+0x38/0x100
    |  shmem_getpage_gfp.isra.3+0x82/0xbfc
    |  shmem_fault+0x46/0x138
    |  handle_mm_fault+0x5bc/0x924
    |  do_page_fault+0x100/0x2b8
    |  ret_from_exception+0x0/0x8
    
    He bisected to 84c6591103db ("locking/atomics,
    asm-generic/bitops/lock.h: Rewrite using atomic_fetch_*()")
    
    This commit however only unmasked the real issue introduced by commit
    4aef66c8ae9 ("locking/atomic, arch/arc: Fix build") which missed the
    retry-if-scond-failed branch in atomic_fetch_##op() macros.
    
    The bisected commit started using atomic_fetch_##op() macros for building
    the rest of atomics.
    
    Fixes: 4aef66c8ae9 ("locking/atomic, arch/arc: Fix build")
    Reported-by: Eugeniy Paltsev <paltsev@synopsys.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    [vgupta: wrote changelog]
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e259a0537be13317661f96e472e24a70e7d760c
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Fri Aug 31 09:04:18 2018 +0200

    gpio: Fix crash due to registration race
    
    [ Upstream commit d49b48f088c323dbacae44dfbe56d9c985c8a2a1 ]
    
    gpiochip_add_data_with_key() adds the gpiochip to the gpio_devices list
    before of_gpiochip_add() is called, but it's only the latter which sets
    the ->of_xlate function pointer.  gpiochip_find() can be called by
    someone else between these two actions, and it can find the chip and
    call of_gpiochip_match_node_and_xlate() which leads to the following
    crash due to a NULL ->of_xlate().
    
     Unhandled prefetch abort: page domain fault (0x01b) at 0x00000000
     Modules linked in: leds_gpio(+) gpio_generic(+)
     CPU: 0 PID: 830 Comm: insmod Not tainted 4.18.0+ #43
     Hardware name: ARM-Versatile Express
     PC is at   (null)
     LR is at of_gpiochip_match_node_and_xlate+0x2c/0x38
     Process insmod (pid: 830, stack limit = 0x(ptrval))
      (of_gpiochip_match_node_and_xlate) from  (gpiochip_find+0x48/0x84)
      (gpiochip_find) from  (of_get_named_gpiod_flags+0xa8/0x238)
      (of_get_named_gpiod_flags) from  (gpiod_get_from_of_node+0x2c/0xc8)
      (gpiod_get_from_of_node) from  (devm_fwnode_get_index_gpiod_from_child+0xb8/0x144)
      (devm_fwnode_get_index_gpiod_from_child) from  (gpio_led_probe+0x208/0x3c4 [leds_gpio])
      (gpio_led_probe [leds_gpio]) from  (platform_drv_probe+0x48/0x9c)
      (platform_drv_probe) from  (really_probe+0x1d0/0x3d4)
      (really_probe) from  (driver_probe_device+0x78/0x1c0)
      (driver_probe_device) from  (__driver_attach+0x120/0x13c)
      (__driver_attach) from  (bus_for_each_dev+0x68/0xb4)
      (bus_for_each_dev) from  (bus_add_driver+0x1a8/0x268)
      (bus_add_driver) from  (driver_register+0x78/0x10c)
      (driver_register) from  (do_one_initcall+0x54/0x1fc)
      (do_one_initcall) from  (do_init_module+0x64/0x1f4)
      (do_init_module) from  (load_module+0x2198/0x26ac)
      (load_module) from  (sys_finit_module+0xe0/0x110)
      (sys_finit_module) from  (ret_fast_syscall+0x0/0x54)
    
    One way to fix this would be to rework the hairy registration sequence
    in gpiochip_add_data_with_key(), but since I'd probably introduce a
    couple of new bugs if I attempted that, simply add a check for a
    non-NULL of_xlate function pointer in
    of_gpiochip_match_node_and_xlate().  This works since the driver looking
    for the gpio will simply fail to find the gpio and defer its probe and
    be reprobed when the driver which is registering the gpiochip has fully
    completed its probe.
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b83a52796cda8bbcfad6e0e4710ff17f0d09b8d
Author: Stefan Raspl <stefan.raspl@de.ibm.com>
Date:   Fri Aug 24 14:03:56 2018 +0200

    tools/kvm_stat: fix handling of invalid paths in debugfs provider
    
    [ Upstream commit 617c66b9f236d20f11cecbb3f45e6d5675b2fae1 ]
    
    When filtering by guest, kvm_stat displays garbage when the guest is
    destroyed - see sample output below.
    We add code to remove the invalid paths from the providers, so at least
    no more garbage is displayed.
    Here's a sample output to illustrate:
    
      kvm statistics - pid 13986 (foo)
    
       Event                                         Total %Total CurAvg/s
       diagnose_258                                     -2    0.0        0
       deliver_program_interruption                     -3    0.0        0
       diagnose_308                                     -4    0.0        0
       halt_poll_invalid                               -91    0.0       -6
       deliver_service_signal                         -244    0.0      -16
       halt_successful_poll                           -250    0.1      -17
       exit_pei                                       -285    0.1      -19
       exit_external_request                          -312    0.1      -21
       diagnose_9c                                    -328    0.1      -22
       userspace_handled                              -713    0.1      -47
       halt_attempted_poll                            -939    0.2      -62
       deliver_emergency_signal                      -3126    0.6     -208
       halt_wakeup                                   -7199    1.5     -481
       exit_wait_state                               -7379    1.5     -493
       diagnose_500                                 -56499   11.5    -3757
       exit_null                                    -85491   17.4    -5685
       diagnose_44                                 -133300   27.1    -8874
       exit_instruction                            -195898   39.8   -13037
       Total                                       -492063
    
    Signed-off-by: Stefan Raspl <raspl@linux.vnet.ibm.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52614f7bf1b59d0c93402444cd3e4011429f5371
Author: Stefan Raspl <stefan.raspl@de.ibm.com>
Date:   Fri Aug 24 14:03:55 2018 +0200

    tools/kvm_stat: fix python3 issues
    
    [ Upstream commit 58f33cfe73076b6497bada4f7b5bda961ed68083 ]
    
    Python3 returns a float for a regular division - switch to a division
    operator that returns an integer.
    Furthermore, filters return a generator object instead of the actual
    list - wrap result in yet another list, which makes it still work in
    both, Python2 and 3.
    
    Signed-off-by: Stefan Raspl <raspl@linux.ibm.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d66ce6878690b600bf03ad1bfa9ebf5c043b778
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Aug 30 10:55:49 2018 +0200

    mac80211: always account for A-MSDU header changes
    
    [ Upstream commit aa58acf325b4aadeecae2bfc90658273b47dbace ]
    
    In the error path of changing the SKB headroom of the second
    A-MSDU subframe, we would not account for the already-changed
    length of the first frame that just got converted to be in
    A-MSDU format and thus is a bit longer now.
    
    Fix this by doing the necessary accounting.
    
    It would be possible to reorder the operations, but that would
    make the code more complex (to calculate the necessary pad),
    and the headroom expansion should not fail frequently enough
    to make that worthwhile.
    
    Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2592adfe326bc98674b53da76fdec7a02a51de07
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Wed Aug 29 21:03:25 2018 +0200

    mac80211: do not convert to A-MSDU if frag/subframe limited
    
    [ Upstream commit 1eb507903665442360a959136dfa3234c43db085 ]
    
    Do not start to aggregate packets in a A-MSDU frame (converting the
    first subframe to A-MSDU, adding the header) if max_tx_fragments or
    max_amsdu_subframes limits are already exceeded by it. In particular,
    this happens when drivers set the limit to 1 to avoid A-MSDUs at all.
    
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    [reword commit message to be more precise]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b22a5d20aab1968d9fd896971ca1706e7c999af9
Author: Arunk Khandavalli <akhandav@codeaurora.org>
Date:   Thu Aug 30 00:40:16 2018 +0300

    cfg80211: nl80211_update_ft_ies() to validate NL80211_ATTR_IE
    
    [ Upstream commit 4f0223bfe9c3e62d8f45a85f1ef1b18a8a263ef9 ]
    
    nl80211_update_ft_ies() tried to validate NL80211_ATTR_IE with
    is_valid_ie_attr() before dereferencing it, but that helper function
    returns true in case of NULL pointer (i.e., attribute not included).
    This can result to dereferencing a NULL pointer. Fix that by explicitly
    checking that NL80211_ATTR_IE is included.
    
    Fixes: 355199e02b83 ("cfg80211: Extend support for IEEE 802.11r Fast BSS Transition")
    Signed-off-by: Arunk Khandavalli <akhandav@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7577a1f1a65956fe6981b97f3002478e293dc8d
Author: Peng Li <lipeng321@huawei.com>
Date:   Mon Aug 27 09:59:30 2018 +0800

    net: hns: add netif_carrier_off before change speed and duplex
    
    [ Upstream commit 455c4401fe7a538facaffb35b906ce19f1ece474 ]
    
    If there are packets in hardware when changing the speed
    or duplex, it may cause hardware hang up.
    
    This patch adds netif_carrier_off before change speed and
    duplex in ethtool_ops.set_link_ksettings, and adds
    netif_carrier_on after complete the change.
    
    Signed-off-by: Peng Li <lipeng321@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fd11a1ad542ab719f18e6480e4de4f7aad711eb
Author: Peng Li <lipeng321@huawei.com>
Date:   Mon Aug 27 09:59:29 2018 +0800

    net: hns: add the code for cleaning pkt in chip
    
    [ Upstream commit 31fabbee8f5c658c3fa1603c66e9e4f51ea8c2c6 ]
    
    If there are packets in hardware when changing the speed
    or duplex, it may cause hardware hang up.
    
    This patch adds the code for waiting chip to clean the all
    pkts(TX & RX) in chip when the driver uses the function named
    "adjust link".
    
    This patch cleans the pkts as follows:
    1) close rx of chip, close tx of protocol stack.
    2) wait rcb, ppe, mac to clean.
    3) adjust link
    4) open rx of chip, open tx of protocol stack.
    
    Signed-off-by: Peng Li <lipeng321@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdd29365a74cda76fd60445af113ea8e5299d409
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Aug 14 16:07:03 2018 +0200

    gpiolib-acpi: Register GpioInt ACPI event handlers from a late_initcall
    
    [ Upstream commit 78d3a92edbfb02e8cb83173cad84c3f2d5e1f070 ]
    
    GpioInt ACPI event handlers may see there IRQ triggered immediately
    after requesting the IRQ (esp. level triggered ones). This means that they
    may run before any other (builtin) drivers have had a chance to register
    their OpRegion handlers, leading to errors like this:
    
    [    1.133274] ACPI Error: No handler for Region [PMOP] ((____ptrval____)) [UserDefinedRegion] (20180531/evregion-132)
    [    1.133286] ACPI Error: Region UserDefinedRegion (ID=141) has no handler (20180531/exfldio-265)
    [    1.133297] ACPI Error: Method parse/execution failed \_SB.GPO2._L01, AE_NOT_EXIST (20180531/psparse-516)
    
    We already defer the manual initial trigger of edge triggered interrupts
    by running it from a late_initcall handler, this commit replaces this with
    deferring the entire acpi_gpiochip_request_interrupts() call till then,
    fixing the problem of some OpRegions not being registered yet.
    
    Note that this removes the need to have a list of edge triggered handlers
    which need to run, since the entire acpi_gpiochip_request_interrupts() call
    is now delayed, acpi_gpiochip_request_interrupt() can call these directly
    now.
    
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73bfec0a6bde1765d7ad377d390db7e13e714ba9
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Aug 13 19:00:27 2018 +0300

    gpiolib: acpi: Switch to cansleep version of GPIO library call
    
    [ Upstream commit 993b9bc5c47fda86f8ab4e53d68c6fea5ff2764a ]
    
    The commit ca876c7483b6
    
      ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
    
    added a initial value check for pin which is about to be locked as IRQ.
    Unfortunately, not all GPIO drivers can do that atomically. Thus,
    switch to cansleep version of the call. Otherwise we have a warning:
    
    ...
      WARNING: CPU: 2 PID: 1408 at drivers/gpio/gpiolib.c:2883 gpiod_get_value+0x46/0x50
    ...
      RIP: 0010:gpiod_get_value+0x46/0x50
    ...
    
    The change tested on Intel Broxton with Whiskey Cove PMIC GPIO controller.
    
    Fixes: ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a5d353908db44d639108dee9fe05c0a8803b572
Author: Sara Sharon <sara.sharon@intel.com>
Date:   Wed Aug 29 08:57:02 2018 +0200

    mac80211: avoid kernel panic when building AMSDU from non-linear SKB
    
    [ Upstream commit 166ac9d55b0ab70b644e429be1f217fe8393cbd7 ]
    
    When building building AMSDU from non-linear SKB, we hit a
    kernel panic when trying to push the padding to the tail.
    Instead, put the padding at the head of the next subframe.
    This also fixes the A-MSDU subframes to not have the padding
    accounted in the length field and not have pad at all for
    the last subframe, both required by the spec.
    
    Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
    Signed-off-by: Sara Sharon <sara.sharon@intel.com>
    Reviewed-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79448960e3d701f498accd3aa493c5e0851c639c
Author: Yuan-Chi Pang <fu3mo6goo@gmail.com>
Date:   Wed Aug 29 09:30:08 2018 +0800

    mac80211: mesh: fix HWMP sequence numbering to follow standard
    
    [ Upstream commit 1f631c3201fe5491808df143d8fcba81b3197ffd ]
    
    IEEE 802.11-2016 14.10.8.3 HWMP sequence numbering says:
    If it is a target mesh STA, it shall update its own HWMP SN to
    maximum (current HWMP SN, target HWMP SN in the PREQ element) + 1
    immediately before it generates a PREP element in response to a
    PREQ element.
    
    Signed-off-by: Yuan-Chi Pang <fu3mo6goo@gmail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34bec4daf88c2c5ca6294e844318c190ea37a1a4
Author: Michael Hennerich <michael.hennerich@analog.com>
Date:   Mon Aug 13 15:57:44 2018 +0200

    gpio: adp5588: Fix sleep-in-atomic-context bug
    
    [ Upstream commit 6537886cdc9a637711fd6da980dbb87c2c87c9aa ]
    
    This fixes:
    [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug
                              in adp5588_gpio_write()
    [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug
                              in adp5588_gpio_direction_input()
    
    Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0081e67083edc3acce6fd3c6d086e8f790077b70
Author: Danek Duvall <duvall@comfychair.org>
Date:   Wed Aug 22 16:01:05 2018 -0700

    mac80211_hwsim: correct use of IEEE80211_VHT_CAP_RXSTBC_X
    
    [ Upstream commit d7c863a2f65e48f442379f4ee1846d52e0c5d24d ]
    
    The mac80211_hwsim driver intends to say that it supports up to four
    STBC receive streams, but instead it ends up saying something undefined.
    The IEEE80211_VHT_CAP_RXSTBC_X macros aren't independent bits that can
    be ORed together, but values.  In this case, _4 is the appropriate one
    to use.
    
    Signed-off-by: Danek Duvall <duvall@comfychair.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c209ebc7f152d3440c00f5dda4dab06a9b4c39b
Author: Danek Duvall <duvall@comfychair.org>
Date:   Wed Aug 22 16:01:04 2018 -0700

    mac80211: correct use of IEEE80211_VHT_CAP_RXSTBC_X
    
    [ Upstream commit 67d1ba8a6dc83d90cd58b89fa6cbf9ae35a0cf7f ]
    
    The mod mask for VHT capabilities intends to say that you can override
    the number of STBC receive streams, and it does, but only by accident.
    The IEEE80211_VHT_CAP_RXSTBC_X aren't bits to be set, but values (albeit
    left-shifted).  ORing the bits together gets the right answer, but we
    should use the _MASK macro here instead.
    
    Signed-off-by: Danek Duvall <duvall@comfychair.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6054817c5e07702922603efc64c9568d60e3ee78
Author: Varun Prakash <varun@chelsio.com>
Date:   Sat Aug 11 21:03:58 2018 +0530

    scsi: csiostor: add a check for NULL pointer after kmalloc()
    
    [ Upstream commit 89809b028b6f54187b7d81a0c69b35d394c52e62 ]
    
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Varun Prakash <varun@chelsio.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e380c50cf12f07d01262b81f5c61249503d2ce3
Author: Anand Jain <anand.jain@oracle.com>
Date:   Mon Aug 6 18:12:37 2018 +0800

    btrfs: btrfs_shrink_device should call commit transaction at the end
    
    [ Upstream commit 801660b040d132f67fac6a95910ad307c5929b49 ]
    
    Test case btrfs/164 reports use-after-free:
    
    [ 6712.084324] general protection fault: 0000 [#1] PREEMPT SMP
    ..
    [ 6712.195423]  btrfs_update_commit_device_size+0x75/0xf0 [btrfs]
    [ 6712.201424]  btrfs_commit_transaction+0x57d/0xa90 [btrfs]
    [ 6712.206999]  btrfs_rm_device+0x627/0x850 [btrfs]
    [ 6712.211800]  btrfs_ioctl+0x2b03/0x3120 [btrfs]
    
    Reason for this is that btrfs_shrink_device adds the resized device to
    the fs_devices::resized_devices after it has called the last commit
    transaction.
    
    So the list fs_devices::resized_devices is not empty when
    btrfs_shrink_device returns.  Now the parent function
    btrfs_rm_device calls:
    
            btrfs_close_bdev(device);
            call_rcu(&device->rcu, free_device_rcu);
    
    and then does the transactio ncommit. It goes through the
    fs_devices::resized_devices in btrfs_update_commit_device_size and
    leads to use-after-free.
    
    Fix this by making sure btrfs_shrink_device calls the last needed
    btrfs_commit_transaction before the return. This is consistent with what
    the grow counterpart does and this makes sure the on-disk state is
    persistent when the function returns.
    
    Reported-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
    Tested-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ update changelog ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e685bec07ae0348a895c777d593c3a1b1954745
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Mon Aug 20 16:05:45 2018 +1000

    KVM: PPC: Book3S HV: Don't truncate HPTE index in xlate function
    
    [ Upstream commit 46dec40fb741f00f1864580130779aeeaf24fb3d ]
    
    This fixes a bug which causes guest virtual addresses to get translated
    to guest real addresses incorrectly when the guest is using the HPT MMU
    and has more than 256GB of RAM, or more specifically has a HPT larger
    than 2GB.  This has showed up in testing as a failure of the host to
    emulate doorbell instructions correctly on POWER9 for HPT guests with
    more than 256GB of RAM.
    
    The bug is that the HPTE index in kvmppc_mmu_book3s_64_hv_xlate()
    is stored as an int, and in forming the HPTE address, the index gets
    shifted left 4 bits as an int before being signed-extended to 64 bits.
    The simple fix is to make the variable a long int, matching the
    return type of kvmppc_hv_find_lock_hpte(), which is what calculates
    the index.
    
    Fixes: 697d3899dcb4 ("KVM: PPC: Implement MMIO emulation support for Book3S HV guests")
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 381538ae75cfdcbda1ea7e3735ddb0cd369be67f
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Aug 15 18:17:03 2018 +0200

    mac80211_hwsim: require at least one channel
    
    [ Upstream commit 484004339d4514fde425f6e8a9f6a6cc979bb0c3 ]
    
    Syzbot continues to try to create mac80211_hwsim radios, and
    manages to pass parameters that are later checked with WARN_ON
    in cfg80211 - catch another one in hwsim directly.
    
    Reported-by: syzbot+2a12f11c306afe871c1f@syzkaller.appspotmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ae9a73be7ac5805a841a6da2bc792c046936c1c
Author: Toke Høiland-Jørgensen <toke@toke.dk>
Date:   Mon Aug 13 14:16:25 2018 +0200

    mac80211: Run TXQ teardown code before de-registering interfaces
    
    [ Upstream commit 77cfaf52eca5cac30ed029507e0cab065f888995 ]
    
    The TXQ teardown code can reference the vif data structures that are
    stored in the netdev private memory area if there are still packets on
    the queue when it is being freed. Since the TXQ teardown code is run
    after the netdevs are freed, this can lead to a use-after-free. Fix this
    by moving the TXQ teardown code to earlier in ieee80211_unregister_hw().
    
    Reported-by: Ben Greear <greearb@candelatech.com>
    Tested-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a738e7f734ce0308377fbed37683bf355f0c12f
Author: Len Brown <len.brown@intel.com>
Date:   Fri Dec 8 17:38:17 2017 -0500

    tools/power turbostat: fix possible sprintf buffer overflow
    
    commit 46c2797826cc6d1ae36fcbd966e76f9fa1907eef upstream.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Cc: Alakesh Haloi <alakeshh@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdb2d37d345d694fcf83291c1a5b5465f743fd73
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Sun Aug 26 19:49:32 2018 +0200

    serial: mvebu-uart: Fix reporting of effective CSIZE to userspace
    
    commit e0bf2d4982fe7d9ddaf550dd023803ea286f47fc upstream.
    
    Apparently, this driver (or the hardware) does not support character
    length settings. It's apparently running in 8-bit mode, but it makes
    userspace believe it's in 5-bit mode. That makes tcsetattr with CS8
    incorrectly fail, breaking e.g. getty from busybox, thus the login shell
    on ttyMVx.
    
    Fix by hard-wiring CS8 into c_cflag.
    
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port")
    Cc: stable <stable@vger.kernel.org> # 4.6+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a17e2a72e714ca20c31e41827ab6088df896c190
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jul 17 10:52:29 2018 -0500

    drm/amdgpu: add another ATPX quirk for TOPAZ
    
    commit b3fc2ab37e27f8d6588a4755382346ba2335a7c7 upstream.
    
    Needs ATPX rather than _PR3.
    
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=200517
    Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9e61345652beaafc371092fd7a4532ef351b759
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed Jun 6 13:18:31 2018 +0100

    drm/amd/pp: initialize result to before or'ing in data
    
    commit c4ff91dd40e2253ab6dd028011469c2c694e1e19 upstream.
    
    The current use of result is or'ing in values and checking for
    a non-zero result, however, result is not initialized to zero
    so it potentially contains garbage to start with. Fix this by
    initializing it to the first return from the call to
    vega10_program_didt_config_registers.
    
    Detected by cppcheck:
    "(error) Uninitialized variable: result"
    
    Fixes: 9b7b8154cdb8 ("drm/amd/powerplay: added didt support for vega10")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Huang Rui <ray.huang@amd.com>
    [Fix the subject as Colin's comment]
    Signed-off-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
