commit e7d199e92956587695510d147c8de795f944cec9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 13 09:33:17 2018 +0200

    Linux 4.18.14

commit 91da9ba7bbbd361cb14d2b47cdbfbe68dee54768
Author: Zhi Chen <zhichen@codeaurora.org>
Date:   Mon Jun 18 17:00:39 2018 +0300

    ath10k: fix scan crash due to incorrect length calculation
    
    commit c8291988806407e02a01b4b15b4504eafbcc04e0 upstream.
    
    Length of WMI scan message was not calculated correctly. The allocated
    buffer was smaller than what we expected. So WMI message corrupted
    skb_info, which is at the end of skb->data. This fix takes TLV header
    into account even if the element is zero-length.
    
    Crash log:
      [49.629986] Unhandled kernel unaligned access[#1]:
      [49.634932] CPU: 0 PID: 1176 Comm: logd Not tainted 4.4.60 #180
      [49.641040] task: 83051460 ti: 8329c000 task.ti: 8329c000
      [49.646608] $ 0   : 00000000 00000001 80984a80 00000000
      [49.652038] $ 4   : 45259e89 8046d484 8046df30 8024ba70
      [49.657468] $ 8   : 00000000 804cc4c0 00000001 20306320
      [49.662898] $12   : 33322037 000110f2 00000000 31203930
      [49.668327] $16   : 82792b40 80984a80 00000001 804207fc
      [49.673757] $20   : 00000000 0000012c 00000040 80470000
      [49.679186] $24   : 00000000 8024af7c
      [49.684617] $28   : 8329c000 8329db88 00000001 802c58d0
      [49.690046] Hi    : 00000000
      [49.693022] Lo    : 453c0000
      [49.696013] epc   : 800efae4 put_page+0x0/0x58
      [49.700615] ra    : 802c58d0 skb_release_data+0x148/0x1d4
      [49.706184] Status: 1000fc03 KERNEL EXL IE
      [49.710531] Cause : 00800010 (ExcCode 04)
      [49.714669] BadVA : 45259e89
      [49.717644] PrId  : 00019374 (MIPS 24Kc)
    
    Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Cc: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7903dacfc64e2775276d9e9ecab714b459b72702
Author: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date:   Mon Jul 30 22:48:41 2018 -0700

    rds: rds_ib_recv_alloc_cache() should call alloc_percpu_gfp() instead
    
    commit f394ad28feffbeebab77c8bf9a203bd49b957c9a upstream.
    
    Currently, rds_ib_conn_alloc() calls rds_ib_recv_alloc_caches()
    without passing along the gfp_t flag.  But rds_ib_recv_alloc_caches()
    and rds_ib_recv_alloc_cache() should take a gfp_t parameter so that
    rds_ib_recv_alloc_cache() can call alloc_percpu_gfp() using the
    correct flag instead of calling alloc_percpu().
    
    Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: HÃ¥kon Bugge <haakon.bugge@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef37df3b8284c43ef0901c4c59d443ae790a31bb
Author: Richard Weinberger <richard@nod.at>
Date:   Mon Sep 3 23:06:23 2018 +0200

    ubifs: Check for name being NULL while mounting
    
    commit 37f31b6ca4311b94d985fb398a72e5399ad57925 upstream.
    
    The requested device name can be NULL or an empty string.
    Check for that and refuse to continue. UBIFS has to do this manually
    since we cannot use mount_bdev(), which checks for this condition.
    
    Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system")
    Reported-by: syzbot+38bd0f7865e5c6379280@syzkaller.appspotmail.com
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09fbdca26741ce4dac3fdec6d5098f71cc607bc2
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Wed Sep 12 16:27:44 2018 -0700

    ucma: fix a use-after-free in ucma_resolve_ip()
    
    commit 5fe23f262e0548ca7f19fb79f89059a60d087d22 upstream.
    
    There is a race condition between ucma_close() and ucma_resolve_ip():
    
    CPU0                            CPU1
    ucma_resolve_ip():              ucma_close():
    
    ctx = ucma_get_ctx(file, cmd.id);
    
            list_for_each_entry_safe(ctx, tmp, &file->ctx_list, list) {
                    mutex_lock(&mut);
                    idr_remove(&ctx_idr, ctx->id);
                    mutex_unlock(&mut);
                    ...
                    mutex_lock(&mut);
                    if (!ctx->closing) {
                            mutex_unlock(&mut);
                            rdma_destroy_id(ctx->cm_id);
                    ...
                    ucma_free_ctx(ctx);
    
    ret = rdma_resolve_addr();
    ucma_put_ctx(ctx);
    
    Before idr_remove(), ucma_get_ctx() could still find the ctx
    and after rdma_destroy_id(), rdma_resolve_addr() may still
    access id_priv pointer. Also, ucma_put_ctx() may use ctx after
    ucma_free_ctx() too.
    
    ucma_close() should call ucma_put_ctx() too which tests the
    refcnt and waits for the last one releasing it. The similar
    pattern is already used by ucma_destroy_id().
    
    Reported-and-tested-by: syzbot+da2591e115d57a9cbb8b@syzkaller.appspotmail.com
    Reported-by: syzbot+cfe3c1e8ef634ba8964b@syzkaller.appspotmail.com
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Doug Ledford <dledford@redhat.com>
    Cc: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9753a6f7497d9a42f710869b10961db92f94b30f
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Tue Sep 4 14:54:55 2018 -0700

    tipc: call start and done ops directly in __tipc_nl_compat_dumpit()
    
    commit 8f5c5fcf353302374b36232d6885c1a3b579e5ca upstream.
    
    __tipc_nl_compat_dumpit() uses a netlink_callback on stack,
    so the only way to align it with other ->dumpit() call path
    is calling tipc_dump_start() and tipc_dump_done() directly
    inside it. Otherwise ->dumpit() would always get NULL from
    cb->args[].
    
    But tipc_dump_start() uses sock_net(cb->skb->sk) to retrieve
    net pointer, the cb->skb here doesn't set skb->sk, the net pointer
    is saved in msg->net instead, so introduce a helper function
    __tipc_dump_start() to pass in msg->net.
    
    Ying pointed out cb->args[0...3] are already used by other
    callbacks on this call path, so we can't use cb->args[0] any
    more, use cb->args[4] instead.
    
    Fixes: 9a07efa9aea2 ("tipc: switch to rhashtable iterator")
    Reported-and-tested-by: syzbot+e93a2c41f91b8e2c7d9b@syzkaller.appspotmail.com
    Cc: Jon Maloy <jon.maloy@ericsson.com>
    Cc: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a04224bbd1a0e11dec78ff5abe442e307a684df
Author: Chao Yu <yuchao0@huawei.com>
Date:   Thu Aug 2 22:59:12 2018 +0800

    f2fs: fix invalid memory access
    
    commit d3f07c049dab1a3f1740f476afd3d5e5b738c21c upstream.
    
    syzbot found the following crash on:
    
    HEAD commit:    d9bd94c0bcaa Add linux-next specific files for 20180801
    git tree:       linux-next
    console output: https://syzkaller.appspot.com/x/log.txt?x=1001189c400000
    kernel config:  https://syzkaller.appspot.com/x/.config?x=cc8964ea4d04518c
    dashboard link: https://syzkaller.appspot.com/bug?extid=c966a82db0b14aa37e81
    compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
    
    Unfortunately, I don't have any reproducer for this crash yet.
    
    IMPORTANT: if you fix the bug, please add the following tag to the commit:
    Reported-by: syzbot+c966a82db0b14aa37e81@syzkaller.appspotmail.com
    
    loop7: rw=12288, want=8200, limit=20
    netlink: 65342 bytes leftover after parsing attributes in process `syz-executor4'.
    openvswitch: netlink: Message has 8 unknown bytes.
    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] SMP KASAN
    CPU: 1 PID: 7615 Comm: syz-executor7 Not tainted 4.18.0-rc7-next-20180801+ #29
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
    RIP: 0010:compound_head include/linux/page-flags.h:142 [inline]
    RIP: 0010:PageLocked include/linux/page-flags.h:272 [inline]
    RIP: 0010:f2fs_put_page fs/f2fs/f2fs.h:2011 [inline]
    RIP: 0010:validate_checkpoint+0x66d/0xec0 fs/f2fs/checkpoint.c:835
    Code: e8 58 05 7f fe 4c 8d 6b 80 4d 8d 74 24 08 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 c6 04 02 00 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 f4 06 00 00 4c 89 ea 4d 8b 7c 24 08 48 b8 00 00
    RSP: 0018:ffff8801937cebe8 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: ffff8801937cef30 RCX: ffffc90006035000
    RDX: 0000000000000000 RSI: ffffffff82fd9658 RDI: 0000000000000005
    RBP: ffff8801937cef58 R08: ffff8801ab254700 R09: fffff94000d9e026
    R10: fffff94000d9e026 R11: ffffea0006cf0137 R12: fffffffffffffffb
    R13: ffff8801937ceeb0 R14: 0000000000000003 R15: ffff880193419b40
    FS:  00007f36a61d5700(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc04ff93000 CR3: 00000001d0562000 CR4: 00000000001426e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     f2fs_get_valid_checkpoint+0x436/0x1ec0 fs/f2fs/checkpoint.c:860
     f2fs_fill_super+0x2d42/0x8110 fs/f2fs/super.c:2883
     mount_bdev+0x314/0x3e0 fs/super.c:1344
     f2fs_mount+0x3c/0x50 fs/f2fs/super.c:3133
     legacy_get_tree+0x131/0x460 fs/fs_context.c:729
     vfs_get_tree+0x1cb/0x5c0 fs/super.c:1743
     do_new_mount fs/namespace.c:2603 [inline]
     do_mount+0x6f2/0x1e20 fs/namespace.c:2927
     ksys_mount+0x12d/0x140 fs/namespace.c:3143
     __do_sys_mount fs/namespace.c:3157 [inline]
     __se_sys_mount fs/namespace.c:3154 [inline]
     __x64_sys_mount+0xbe/0x150 fs/namespace.c:3154
     do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x45943a
    Code: b8 a6 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 bd 8a fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 9a 8a fb ff c3 66 0f 1f 84 00 00 00 00 00
    RSP: 002b:00007f36a61d4a88 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
    RAX: ffffffffffffffda RBX: 00007f36a61d4b30 RCX: 000000000045943a
    RDX: 00007f36a61d4ad0 RSI: 0000000020000100 RDI: 00007f36a61d4af0
    RBP: 0000000020000100 R08: 00007f36a61d4b30 R09: 00007f36a61d4ad0
    R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000013
    R13: 0000000000000000 R14: 00000000004c8ea0 R15: 0000000000000000
    Modules linked in:
    Dumping ftrace buffer:
       (ftrace buffer empty)
    ---[ end trace bd8550c129352286 ]---
    RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
    RIP: 0010:compound_head include/linux/page-flags.h:142 [inline]
    RIP: 0010:PageLocked include/linux/page-flags.h:272 [inline]
    RIP: 0010:f2fs_put_page fs/f2fs/f2fs.h:2011 [inline]
    RIP: 0010:validate_checkpoint+0x66d/0xec0 fs/f2fs/checkpoint.c:835
    Code: e8 58 05 7f fe 4c 8d 6b 80 4d 8d 74 24 08 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 c6 04 02 00 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 f4 06 00 00 4c 89 ea 4d 8b 7c 24 08 48 b8 00 00
    RSP: 0018:ffff8801937cebe8 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: ffff8801937cef30 RCX: ffffc90006035000
    RDX: 0000000000000000 RSI: ffffffff82fd9658 RDI: 0000000000000005
    netlink: 65342 bytes leftover after parsing attributes in process `syz-executor4'.
    RBP: ffff8801937cef58 R08: ffff8801ab254700 R09: fffff94000d9e026
    openvswitch: netlink: Message has 8 unknown bytes.
    R10: fffff94000d9e026 R11: ffffea0006cf0137 R12: fffffffffffffffb
    R13: ffff8801937ceeb0 R14: 0000000000000003 R15: ffff880193419b40
    FS:  00007f36a61d5700(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc04ff93000 CR3: 00000001d0562000 CR4: 00000000001426e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    In validate_checkpoint(), if we failed to call get_checkpoint_version(), we
    will pass returned invalid page pointer into f2fs_put_page, cause accessing
    invalid memory, this patch tries to handle error path correctly to fix this
    issue.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>

commit 50231468deda8ca533c61e9dfeb767ed03b263d9
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Fri Oct 5 12:48:48 2018 -0700

    ARC: clone syscall to setp r25 as thread pointer
    
    commit c58a584f05e35d1d4342923cd7aac07d9c3d3d16 upstream.
    
    Per ARC TLS ABI, r25 is designated TP (thread pointer register).
    However so far kernel didn't do any special treatment, like setting up
    usermode r25, even for CLONE_SETTLS. We instead relied on libc runtime
    to do this, in say clone libc wrapper [1]. This was deliberate to keep
    kernel ABI agnostic (userspace could potentially change TP, specially
    for different ARC ISA say ARCompact vs. ARCv2 with different spare
    registers etc)
    
    However userspace setting up r25, after clone syscall opens a race, if
    child is not scheduled and gets a signal instead. It starts off in
    userspace not in clone but in a signal handler and anything TP sepcific
    there such as pthread_self() fails which showed up with uClibc
    testsuite nptl/tst-kill6 [2]
    
    Fix this by having kernel populate r25 to TP value. So this locks in
    ABI, but it was not going to change anyways, and fwiw is same for both
    ARCompact (arc700 core) and ARCvs (HS3x cores)
    
    [1] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/clone.S
    [2] https://github.com/wbx-github/uclibc-ng-test/blob/master/test/nptl/tst-kill6.c
    
    Fixes: ARC STAR 9001378481
    Cc: stable@vger.kernel.org
    Reported-by: Nikita Sobolev <sobolev@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4a856d4ca301b3ebd80abb13eae2f6ce64c03e0
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Mon Oct 1 12:21:10 2018 +0000

    powerpc/lib: fix book3s/32 boot failure due to code patching
    
    commit b45ba4a51cde29b2939365ef0c07ad34c8321789 upstream.
    
    Commit 51c3c62b58b3 ("powerpc: Avoid code patching freed init
    sections") accesses 'init_mem_is_free' flag too early, before the
    kernel is relocated. This provokes early boot failure (before the
    console is active).
    
    As it is not necessary to do this verification that early, this
    patch moves the test into patch_instruction() instead of
    __patch_instruction().
    
    This modification also has the advantage of avoiding unnecessary
    remappings.
    
    Fixes: 51c3c62b58b3 ("powerpc: Avoid code patching freed init sections")
    Cc: stable@vger.kernel.org # 4.13+
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2025ef74e8c4268569775adb54a6d1f49156af14
Author: Michael Neuling <mikey@neuling.org>
Date:   Fri Sep 14 11:14:11 2018 +1000

    powerpc: Avoid code patching freed init sections
    
    commit 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 upstream.
    
    This stops us from doing code patching in init sections after they've
    been freed.
    
    In this chain:
      kvm_guest_init() ->
        kvm_use_magic_page() ->
          fault_in_pages_readable() ->
             __get_user() ->
               __get_user_nocheck() ->
                 barrier_nospec();
    
    We have a code patching location at barrier_nospec() and
    kvm_guest_init() is an init function. This whole chain gets inlined,
    so when we free the init section (hence kvm_guest_init()), this code
    goes away and hence should no longer be patched.
    
    We seen this as userspace memory corruption when using a memory
    checker while doing partition migration testing on powervm (this
    starts the code patching post migration via
    /sys/kernel/mobility/migration). In theory, it could also happen when
    using /sys/kernel/debug/powerpc/barrier_nospec.
    
    Cc: stable@vger.kernel.org # 4.13+
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4f71e6ae0cbe60218d2773236428ecd848fa618
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Sep 25 21:06:24 2018 -0700

    of: unittest: Disable interrupt node tests for old world MAC systems
    
    commit 8894891446c9380709451b99ab45c5c53adfd2fc upstream.
    
    On systems with OF_IMAP_OLDWORLD_MAC set in of_irq_workarounds, the
    devicetree interrupt parsing code is different, causing unit tests of
    devicetree interrupt nodes to fail. Due to a bug in unittest code, which
    tries to dereference an uninitialized pointer, this results in a crash.
    
    OF: /testcase-data/phandle-tests/consumer-a: arguments longer than property
    Unable to handle kernel paging request for data at address 0x00bc616e
    Faulting instruction address: 0xc08e9468
    Oops: Kernel access of bad area, sig: 11 [#1]
    BE PREEMPT PowerMac
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.72-rc1-yocto-standard+ #1
    task: cf8e0000 task.stack: cf8da000
    NIP:  c08e9468 LR: c08ea5bc CTR: c08ea5ac
    REGS: cf8dbb50 TRAP: 0300   Not tainted  (4.14.72-rc1-yocto-standard+)
    MSR:  00001032 <ME,IR,DR,RI>  CR: 82004044  XER: 00000000
    DAR: 00bc616e DSISR: 40000000
    GPR00: c08ea5bc cf8dbc00 cf8e0000 c13ca517 c13ca517 c13ca8a0 00000066 00000002
    GPR08: 00000063 00bc614e c0b05865 000affff 82004048 00000000 c00047f0 00000000
    GPR16: c0a80000 c0a9cc34 c13ca517 c0ad1134 05ffffff 000affff c0b05860 c0abeef8
    GPR24: cecec278 cecec278 c0a8c4d0 c0a885e0 c13ca8a0 05ffffff c13ca8a0 c13ca517
    
    NIP [c08e9468] device_node_gen_full_name+0x30/0x15c
    LR [c08ea5bc] device_node_string+0x190/0x3c8
    Call Trace:
    [cf8dbc00] [c007f670] trace_hardirqs_on_caller+0x118/0x1fc (unreliable)
    [cf8dbc40] [c08ea5bc] device_node_string+0x190/0x3c8
    [cf8dbcb0] [c08eb794] pointer+0x25c/0x4d0
    [cf8dbd00] [c08ebcbc] vsnprintf+0x2b4/0x5ec
    [cf8dbd60] [c08ec00c] vscnprintf+0x18/0x48
    [cf8dbd70] [c008e268] vprintk_store+0x4c/0x22c
    [cf8dbda0] [c008ecac] vprintk_emit+0x94/0x130
    [cf8dbdd0] [c008ff54] printk+0x5c/0x6c
    [cf8dbe10] [c0b8ddd4] of_unittest+0x2220/0x26f8
    [cf8dbea0] [c0004434] do_one_initcall+0x4c/0x184
    [cf8dbf00] [c0b4534c] kernel_init_freeable+0x13c/0x1d8
    [cf8dbf30] [c0004814] kernel_init+0x24/0x118
    [cf8dbf40] [c0013398] ret_from_kernel_thread+0x5c/0x64
    
    The problem was observed when running a qemu test for the g3beige machine
    with devicetree unittests enabled.
    
    Disable interrupt node tests on affected systems to avoid both false
    unittest failures and the crash.
    
    With this patch in place, unittest on the affected system passes with
    the following message.
    
            dt-test ### end of unittest - 144 passed, 0 failed
    
    Fixes: 53a42093d96ef ("of: Add device tree selftests")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Frank Rowand <frank.rowand@sony.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a09a553b1693a93c7da51245601ee9771653ac4b
Author: Dmitry Safonov <dima@arista.com>
Date:   Tue Sep 18 00:52:52 2018 +0100

    tty: Drop tty->count on tty_reopen() failure
    
    commit fe32416790093b31364c08395727de17ec96ace1 upstream.
    
    In case of tty_ldisc_reinit() failure, tty->count should be decremented
    back, otherwise we will never release_tty().
    Tetsuo reported that it fixes noisy warnings on tty release like:
      pts pts4033: tty_release: tty->count(10529) != (#fd's(7) + #kopen's(0))
    
    Fixes: commit 892d1fa7eaae ("tty: Destroy ldisc instance on hangup")
    
    Cc: stable@vger.kernel.org # v4.6+
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jslaby@suse.com>
    Reviewed-by: Jiri Slaby <jslaby@suse.cz>
    Tested-by: Jiri Slaby <jslaby@suse.com>
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Signed-off-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 274a367121ae4b0db3d3b4bf15fcb091d005cfba
Author: Romain Izard <romain.izard.pro@gmail.com>
Date:   Thu Sep 20 16:49:04 2018 +0200

    usb: cdc_acm: Do not leak URB buffers
    
    commit f2924d4b16ae138c2de6a0e73f526fb638330858 upstream.
    
    When the ACM TTY port is disconnected, the URBs it uses must be killed, and
    then the buffers must be freed. Unfortunately a previous refactor removed
    the code freeing the buffers because it looked extremely similar to the
    code killing the URBs.
    
    As a result, there were many new leaks for each plug/unplug cycle of a
    CDC-ACM device, that were detected by kmemleak.
    
    Restore the missing code, and the memory leak is removed.
    
    Fixes: ba8c931ded8d ("cdc-acm: refactor killing urbs")
    Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f0a2f6649b7642283dd76101db0862dc62263ce
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Sep 13 11:21:50 2018 +0200

    USB: serial: option: add two-endpoints device-id flag
    
    commit 35aecc02b5b621782111f64cbb032c7f6a90bb32 upstream.
    
    Allow matching on interfaces having two endpoints by adding a new
    device-id flag.
    
    This allows for the handling of devices whose interface numbers can
    change (e.g. Quectel EP06) to be contained in the device-id table.
    
    Tested-by: Kristian Evensen <kristian.evensen@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fcb2fb9731aff88fe59ec649dbcb02c65b2445c
Author: Kristian Evensen <kristian.evensen@gmail.com>
Date:   Thu Sep 13 11:21:49 2018 +0200

    USB: serial: option: improve Quectel EP06 detection
    
    commit 36cae568404a298a19a6e8a3f18641075d4cab04 upstream.
    
    The Quectel EP06 (and EM06/EG06) LTE modem supports updating the USB
    configuration, without the VID/PID or configuration number changing.
    When the configuration is updated and interfaces are added/removed, the
    interface numbers are updated. This causes our current code for matching
    EP06 not to work as intended, as the assumption about reserved
    interfaces no longer holds. If for example the diagnostic (first)
    interface is removed, option will (try to) bind to the QMI interface.
    
    This patch improves EP06 detection by replacing the current match with
    two matches, and those matches check class, subclass and protocol as
    well as VID and PID. The diag interface exports class, subclass and
    protocol as 0xff. For the other serial interfaces, class is 0xff and
    subclass and protocol are both 0x0.
    
    The modem can export the following devices and always in this order:
    diag, nmea, at, ppp. qmi and adb. This means that diag can only ever be
    interface 0, and interface numbers 1-5 should be marked as reserved. The
    three other serial devices can have interface numbers 0-3, but I have
    not marked any interfaces as reserved. The reason is that the serial
    devices are the only interfaces exported by the device where subclass
    and protocol is 0x0.
    
    QMI exports the same class, subclass and protocol values as the diag
    interface. However, the two interfaces have different number of
    endpoints, QMI has three and diag two. I have added a check for number
    of interfaces if VID/PID matches the EP06, and we ignore the device if
    number of interfaces equals three (and subclass is set).
    
    Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
    Acked-by: Dan Williams <dcbw@redhat.com>
    [ johan: drop uneeded RSVD(5) for ADB ]
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 883f14f7302a1d0a185ff0aa2098664b3984d10f
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Sep 24 15:28:10 2018 +0200

    USB: serial: simple: add Motorola Tetra MTP6550 id
    
    commit f5fad711c06e652f90f581fc7c2caee327c33d31 upstream.
    
    Add device-id for the Motorola Tetra radio MTP6550.
    
    Bus 001 Device 004: ID 0cad:9012 Motorola CGISS
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      idVendor           0x0cad Motorola CGISS
      idProduct          0x9012
      bcdDevice           24.16
      iManufacturer           1 Motorola Solutions, Inc.
      iProduct                2 TETRA PEI interface
      iSerial                 0
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength           55
        bNumInterfaces          2
        bConfigurationValue     1
        iConfiguration          3 Generic Serial config
        bmAttributes         0x80
          (Bus Powered)
        MaxPower              500mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass      0
          bInterfaceProtocol      0
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass      0
          bInterfaceProtocol      0
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x02  EP 2 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0200  1x 512 bytes
            bInterval               0
    Device Qualifier (for other device speed):
      bLength                10
      bDescriptorType         6
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        64
      bNumConfigurations      1
    Device Status:     0x0000
      (Bus Powered)
    
    Reported-by: Hans Hult <hanshult35@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cea0a2e8c5935f81a333b86d2961e9232ece7a1
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Mon Oct 1 18:36:08 2018 +0300

    usb: xhci-mtk: resume USB3 roothub first
    
    commit 555df5820e733cded7eb8d0bf78b2a791be51d75 upstream.
    
    Give USB3 devices a better chance to enumerate at USB3 speeds if
    they are connected to a suspended host.
    Porting from "671ffdff5b13 xhci: resume USB 3 roothub first"
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67c8b9c6c59c3b734b0cf6479ee592539fa1ab64
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Oct 1 18:36:07 2018 +0300

    xhci: Add missing CAS workaround for Intel Sunrise Point xHCI
    
    commit ffe84e01bb1b38c7eb9c6b6da127a6c136d251df upstream.
    
    The workaround for missing CAS bit is also needed for xHC on Intel
    sunrisepoint PCH. For more details see:
    
    Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 226c5c8a540a32307c9173f2faba6650ce62ec02
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Tue Sep 25 20:56:02 2018 -0400

    dm cache: fix resize crash if user doesn't reload cache table
    
    commit 5d07384a666d4b2f781dc056bfeec2c27fbdf383 upstream.
    
    A reload of the cache's DM table is needed during resize because
    otherwise a crash will occur when attempting to access smq policy
    entries associated with the portion of the cache that was recently
    extended.
    
    The reason is cache-size based data structures in the policy will not be
    resized, the only way to safely extend the cache is to allow for a
    proper cache policy initialization that occurs when the cache table is
    loaded.  For example the smq policy's space_init(), init_allocator(),
    calc_hotspot_params() must be sized based on the extended cache size.
    
    The fix for this is to disallow cache resizes of this pattern:
    1) suspend "cache" target's device
    2) resize the fast device used for the cache
    3) resume "cache" target's device
    
    Instead, the last step must be a full reload of the cache's DM table.
    
    Fixes: 66a636356 ("dm cache: add stochastic-multi-queue (smq) policy")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f10b1cdb6190e439bab454066b96f96b628a7b7e
Author: Joe Thornber <ejt@redhat.com>
Date:   Mon Sep 24 16:19:30 2018 -0400

    dm cache metadata: ignore hints array being too small during resize
    
    commit 4561ffca88c546f96367f94b8f1e4715a9c62314 upstream.
    
    Commit fd2fa9541 ("dm cache metadata: save in-core policy_hint_size to
    on-disk superblock") enabled previously written policy hints to be
    used after a cache is reactivated.  But in doing so the cache
    metadata's hint array was left exposed to out of bounds access because
    on resize the metadata's on-disk hint array wasn't ever extended.
    
    Fix this by ignoring that there are no on-disk hints associated with the
    newly added cache blocks.  An expanded on-disk hint array is later
    rewritten upon the next clean shutdown of the cache.
    
    Fixes: fd2fa9541 ("dm cache metadata: save in-core policy_hint_size to on-disk superblock")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75e4e2fae0fe7858cb5500ff4a543cb0f2501f04
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Mon Sep 17 11:38:47 2018 -0400

    dm mpath: fix attached_handler_name leak and dangling hw_handler_name pointer
    
    commit b592211c33f745af67a3271ce77c10fc1e6d6241 upstream.
    
    Commit e8f74a0f0011 ("dm mpath: eliminate need to use
    scsi_device_from_queue") introduced 2 regressions:
    1) memory leak occurs if attached_handler_name is not assigned to
       m->hw_handler_name
    2) m->hw_handler_name can become a dangling pointer if the
       RETAIN_ATTACHED_HW_HANDLER flag is set and scsi_dh_attach() returns
       -EBUSY.
    
    Fix both of these by clearing 'attached_handler_name' pointer passed to
    setup_scsi_dh() after it is assigned to m->hw_handler_name.  And if
    setup_scsi_dh() doesn't consume 'attached_handler_name' parse_path()
    will kfree() it.
    
    Fixes: e8f74a0f0011 ("dm mpath: eliminate need to use scsi_device_from_queue")
    Cc: stable@vger.kernel.org # 4.16+
    Reported-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a92f4488357e3a5baa444d0b51ef240003805c06
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Oct 4 11:08:12 2018 +0200

    PM / core: Clear the direct_complete flag on errors
    
    commit 69e445ab8b66a9f30519842ef18be555d3ee9b51 upstream.
    
    If __device_suspend() runs asynchronously (in which case the device
    passed to it is in dpm_suspended_list at that point) and it returns
    early on an error or pending wakeup, and the power.direct_complete
    flag has been set for the device already, the subsequent
    device_resume() will be confused by that and it will call
    pm_runtime_enable() incorrectly, as runtime PM has not been
    disabled for the device by __device_suspend().
    
    To avoid that, clear power.direct_complete if __device_suspend()
    is not going to disable runtime PM for the device before returning.
    
    Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily)
    Reported-by: Al Cooper <alcooperx@gmail.com>
    Tested-by: Al Cooper <alcooperx@gmail.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3561037582ae99a0b73c5d08d52f8a8bd17687f7
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Sep 29 16:01:58 2018 +0200

    mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys
    
    commit 211710ca74adf790b46ab3867fcce8047b573cd1 upstream.
    
    key->sta is only valid after ieee80211_key_link, which is called later
    in this function. Because of that, the IEEE80211_KEY_FLAG_RX_MGMT is
    never set when management frame protection is enabled.
    
    Fixes: e548c49e6dc6b ("mac80211: add key flag for management keys")
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9d0ba506ea8661a7d91d67e04abe69a535b6048
Author: Daniel Drake <drake@endlessm.com>
Date:   Thu Sep 27 15:47:33 2018 -0500

    PCI: Reprogram bridge prefetch registers on resume
    
    commit 083874549fdfefa629dfa752785e20427dde1511 upstream.
    
    On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
    suspend/resume.  The affected products include multiple generations of
    NVIDIA GPUs and Intel SoCs.  After resume, nouveau logs many errors such
    as:
    
      fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
            [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
      DRM: failed to idle channel 0 [DRM]
    
    Similarly, the NVIDIA proprietary driver also fails after resume (black
    screen, 100% CPU usage in Xorg process).  We shipped a sample to NVIDIA for
    diagnosis, and their response indicated that it's a problem with the parent
    PCI bridge (on the Intel SoC), not the GPU.
    
    Runtime suspend/resume works fine, only S3 suspend is affected.
    
    We found a workaround: on resume, rewrite the Intel PCI bridge
    'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32).  In the
    cases that I checked, this register has value 0 and we just have to rewrite
    that value.
    
    Linux already saves and restores PCI config space during suspend/resume,
    but this register was being skipped because upon resume, it already has
    value 0 (the correct, pre-suspend value).
    
    Intel appear to have previously acknowledged this behaviour and the
    requirement to rewrite this register:
    https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
    
    Based on that, rewrite the prefetch register values even when that appears
    unnecessary.
    
    We have confirmed this solution on all the affected models we have in-hands
    (X542UQ, UX533FD, X530UN, V272UN).
    
    Additionally, this solves an issue where r8169 MSI-X interrupts were broken
    after S3 suspend/resume on ASUS X441UAR.  This issue was recently worked
    around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e").  It
    also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
    that we had not yet patched.  I suspect it will also fix the issue that was
    worked around in commit 7c53a722459c ("r8169: don't use MSI-X on
    RTL8168g").
    
    Thomas Martitz reports that this change also solves an issue where the AMD
    Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
    suspend/resume.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-By: Peter Wu <peter@lekensteyn.nl>
    CC: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db68b064bb738cfc9648e048f40d317f77d170ca
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Oct 3 16:23:49 2018 -0700

    x86/vdso: Fix vDSO syscall fallback asm constraint regression
    
    commit 02e425668f5c9deb42787d10001a3b605993ad15 upstream.
    
    When I added the missing memory outputs, I failed to update the
    index of the first argument (ebx) on 32-bit builds, which broke the
    fallbacks.  Somehow I must have screwed up my testing or gotten
    lucky.
    
    Add another test to cover gettimeofday() as well.
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Fixes: 715bd9d12f84 ("x86/vdso: Fix asm constraints on vDSO syscall fallbacks")
    Link: http://lkml.kernel.org/r/21bd45ab04b6d838278fa5bebfa9163eceffa13c.1538608971.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54f54a2b7fb3f6e8500b087d2694ef694bf95cd2
Author: Andy Lutomirski <luto@kernel.org>
Date:   Tue Oct 2 21:26:50 2018 -0700

    x86/vdso: Only enable vDSO retpolines when enabled and supported
    
    commit 4f166564014aba65ad6f15b612f6711fd0f117ee upstream.
    
    When I fixed the vDSO build to use inline retpolines, I messed up
    the Makefile logic and made it unconditional.  It should have
    depended on CONFIG_RETPOLINE and on the availability of compiler
    support.  This broke the build on some older compilers.
    
    Reported-by: nikola.ciprich@linuxbox.cz
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matt Rickard <matt@softrans.com.au>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: jason.vas.dias@gmail.com
    Cc: stable@vger.kernel.org
    Fixes: 2e549b2ee0e3 ("x86/vdso: Fix vDSO build if a retpoline is emitted")
    Link: http://lkml.kernel.org/r/08a1f29f2c238dd1f493945e702a521f8a5aa3ae.1538540801.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1af2998c34e186636588e97a7ae6bcd6bb7b8936
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Oct 1 12:52:16 2018 -0700

    selftests/x86: Add clock_gettime() tests to test_vdso
    
    commit 7c03e7035ac1cf2a6165754e4f3a49c2f1977838 upstream.
    
    Now that the vDSO implementation of clock_gettime() is getting
    reworked, add a selftest for it.  This tests that its output is
    consistent with the syscall version.
    
    This is marked for stable to serve as a test for commit
    
      715bd9d12f84 ("x86/vdso: Fix asm constraints on vDSO syscall fallbacks")
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/082399674de2619b2befd8c0dde49b260605b126.1538422295.git.luto@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7e1889390a4a2b1e32edf26d7119ee92ad375cc
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Oct 1 12:52:15 2018 -0700

    x86/vdso: Fix asm constraints on vDSO syscall fallbacks
    
    commit 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b upstream.
    
    The syscall fallbacks in the vDSO have incorrect asm constraints.
    They are not marked as writing to their outputs -- instead, they are
    marked as clobbering "memory", which is useless.  In particular, gcc
    is smart enough to know that the timespec parameter hasn't escaped,
    so a memory clobber doesn't clobber it.  And passing a pointer as an
    asm *input* does not tell gcc that the pointed-to value is changed.
    
    Add in the fact that the asm instructions weren't volatile, and gcc
    was free to omit them entirely unless their sole output (the return
    value) is used.  Which it is (phew!), but that stops happening with
    some upcoming patches.
    
    As a trivial example, the following code:
    
    void test_fallback(struct timespec *ts)
    {
            vdso_fallback_gettime(CLOCK_MONOTONIC, ts);
    }
    
    compiles to:
    
    00000000000000c0 <test_fallback>:
      c0:   c3                      retq
    
    To add insult to injury, the RCX and R11 clobbers on 64-bit
    builds were missing.
    
    The "memory" clobber is also unnecessary -- no ordering with respect to
    other memory operations is needed, but that's going to be fixed in a
    separate not-for-stable patch.
    
    Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/2c0231690551989d2fafa60ed0e7b5cc8b403908.1538422295.git.luto@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ac2c7dcc1a0c86439486c7ad53b5b363478688b
Author: Jann Horn <jannh@google.com>
Date:   Mon Oct 1 17:31:17 2018 +0200

    drm: fix use-after-free read in drm_mode_create_lease_ioctl()
    
    commit 12d43deb1ee639d01a2a8d2a7a4cc8ad31224475 upstream.
    
    fd_install() moves the reference given to it into the file descriptor table
    of the current process. If the current process is multithreaded, then
    immediately after fd_install(), another thread can close() the file
    descriptor and cause the file's resources to be cleaned up.
    
    Since the reference to "lessee" is held by the file, we must not access
    "lessee" after the fd_install() call.
    
    As far as I can tell, to reach this codepath, the caller must have an open
    file descriptor to a DRI device in master mode. I'm not sure what the
    requirements for that are.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Fixes: 62884cd386b8 ("drm: Add four ioctls for managing drm mode object leases [v7]")
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20181001153117.216923-1-jannh@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2cef7d049f07995406b403605119a54881daf15
Author: Jason Ekstrand <jason@jlekstrand.net>
Date:   Wed Sep 26 02:17:03 2018 -0500

    drm/syncobj: Don't leak fences when WAIT_FOR_SUBMIT is set
    
    commit 337fe9f5c1e7de1f391c6a692531379d2aa2ee11 upstream.
    
    We attempt to get fences earlier in the hopes that everything will
    already have fences and no callbacks will be needed.  If we do succeed
    in getting a fence, getting one a second time will result in a duplicate
    ref with no unref.  This is causing memory leaks in Vulkan applications
    that create a lot of fences; playing for a few hours can, apparently,
    bring down the system.
    
    Cc: stable@vger.kernel.org
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107899
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180926071703.15257-1-jason.ekstrand@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3361789e57ece9812e2707ad5139a218f9754a77
Author: Rex Zhu <Rex.Zhu@amd.com>
Date:   Thu Sep 27 20:48:39 2018 +0800

    drm/amdgpu: Fix vce work queue was not cancelled when suspend
    
    commit 61ea6f5831974ebd1a57baffd7cc30600a2e26fc upstream.
    
    The vce cancel_delayed_work_sync never be called.
    driver call the function in error path.
    
    This caused the A+A suspend hang when runtime pm enebled.
    As we will visit the smu in the idle queue. this will cause
    smu hang because the dgpu has been suspend, and the dgpu also
    will be waked up. As the smu has been hang, so the dgpu resume
    will failed.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
    Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b67f9b6ab232dadc466461cf7b8870e83c29824a
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Sep 22 18:35:31 2018 +0200

    mac80211: allocate TXQs for active monitor interfaces
    
    commit 8105f9b8a8879bff7f1d43d0720c993a99c9d135 upstream.
    
    Monitor mode interfaces with the active flag are passed down to the driver.
    Drivers using TXQ expect that all interfaces have allocated TXQs before
    they get added.
    
    Fixes: 79af1f866193d ("mac80211: avoid allocating TXQs that won't be used")
    Cc: stable@vger.kernel.org
    Reported-by: Catrinel Catrinescu <cc@80211.de>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b1adad3348a8865ba1dcf572e01d7e1a55d871c
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Fri Sep 28 14:20:40 2018 +0200

    mmc: slot-gpio: Fix debounce time to use miliseconds again
    
    commit 1b09d9c232cdaea59fb50ac437d3921ed1f1eafb upstream.
    
    The debounce value passed to mmc_gpiod_request_cd() function is in
    microseconds, but msecs_to_jiffies() requires the value to be in
    miliseconds to properly calculate the delay, so adjust the value stored
    in cd_debounce_delay_ms context entry.
    
    Fixes: 1d71926bbd59 ("mmc: core: Fix debounce time to use microseconds")
    Fixes: bfd694d5e21c ("mmc: core: Add tunable delay before detecting card
    after card is inserted")
    Cc: stable@vger.kernel.org # v4.18+
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cf3272144b965b07b6cc39ef5fe8e33d46c565b
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Sep 18 16:16:56 2018 -0700

    mmc: core: Fix debounce time to use microseconds
    
    commit 1d71926bbd59facc4bdb6f13117d3a1aee8b83ba upstream.
    
    The debounce value in device tree is in milliseconds but needs to be in
    microseconds for mmc_gpiod_request_cd().
    
    Fixes: bfd694d5e21c ("mmc: core: Add tunable delay before detecting card
    after card is inserted")
    Cc: Shawn Lin <shawn.lin@rock-chips.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Cc: stable@vger.kernel.org # v4.18+
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e62c2fbc1fe943ea487f88a26c100d024283ff3
Author: Jan Beulich <JBeulich@suse.com>
Date:   Tue Sep 25 02:12:30 2018 -0600

    xen-netback: fix input validation in xenvif_set_hash_mapping()
    
    commit 780e83c259fc33e8959fed8dfdad17e378d72b62 upstream.
    
    Both len and off are frontend specified values, so we need to make
    sure there's no overflow when adding the two for the bounds check. We
    also want to avoid undefined behavior and hence use off to index into
    ->hash.mapping[] only after bounds checking. This at the same time
    allows to take care of not applying off twice for the bounds checking
    against vif->num_queues.
    
    It is also insufficient to bounds check copy_op.len, as this is len
    truncated to 16 bits.
    
    This is XSA-270 / CVE-2018-15471.
    
    Reported-by: Felix Wilhelm <fwilhelm@google.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
    Tested-by: Paul Durrant <paul.durrant@citrix.com>
    Cc: stable@vger.kernel.org [4.7 onwards]
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b01f16ed9b9413510f7c155743e798b94a00043
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Wed Sep 26 18:11:22 2018 +0200

    fbdev/omapfb: fix omapfb_memory_read infoleak
    
    commit 1bafcbf59fed92af58955024452f45430d3898c5 upstream.
    
    OMAPFB_MEMORY_READ ioctl reads pixels from the LCD's memory and copies
    them to a userspace buffer. The code has two issues:
    
    - The user provided width and height could be large enough to overflow
      the calculations
    - The copy_to_user() can copy uninitialized memory to the userspace,
      which might contain sensitive kernel information.
    
    Fix these by limiting the width & height parameters, and only copying
    the amount of data that we actually received from the LCD.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Reported-by: Jann Horn <jannh@google.com>
    Cc: stable@vger.kernel.org
    Cc: security@kernel.org
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 771df4eea40241fac5ef5a8332e5353273255ff5
Author: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date:   Wed Apr 25 12:14:39 2018 +0200

    clocksource/drivers/timer-atmel-pit: Properly handle error cases
    
    commit 52bf4a900d9cede3eb14982d0f2c5e6db6d97cc3 upstream.
    
    The smatch utility reports a possible leak:
    
    smatch warnings:
    drivers/clocksource/timer-atmel-pit.c:183 at91sam926x_pit_dt_init() warn: possible memory leak of 'data'
    
    Ensure data is freed before exiting with an error.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45a156123ce492d577a51a6731b2f1e3445d7c4b
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Sep 28 15:17:50 2018 -0700

    pstore/ram: Fix failure-path memory leak in ramoops_init
    
    commit bac6f6cda206ad7cbe0c73c35e494377ce9c4749 upstream.
    
    As reported by nixiaoming, with some minor clarifications:
    
    1) memory leak in ramoops_register_dummy():
       dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL);
       but no kfree() if platform_device_register_data() fails.
    
    2) memory leak in ramoops_init():
       Missing platform_device_unregister(dummy) and kfree(dummy_data)
       if platform_driver_register(&ramoops_driver) fails.
    
    I've clarified the purpose of ramoops_register_dummy(), and added a
    common cleanup routine for all three failure paths to call.
    
    Reported-by: nixiaoming <nixiaoming@huawei.com>
    Cc: stable@vger.kernel.org
    Cc: Anton Vorontsov <anton@enomsg.org>
    Cc: Colin Cross <ccross@android.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Joel Fernandes <joelaf@google.com>
    Cc: Geliang Tang <geliangtang@gmail.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b82610b5bad9cc5a3ec82a1a9c349043a39135c0
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Sep 26 14:35:50 2018 +0200

    blk-mq: I/O and timer unplugs are inverted in blktrace
    
    commit 587562d0c7cd6861f4f90a2eb811cccb1a376f5f upstream.
    
    trace_block_unplug() takes true for explicit unplugs and false for
    implicit unplugs.  schedule() unplugs are implicit and should be
    reported as timer unplugs.  While correct in the legacy code, this has
    been inverted in blk-mq since 4.11.
    
    Cc: stable@vger.kernel.org
    Fixes: bd166ef183c2 ("blk-mq-sched: add framework for MQ capable IO schedulers")
    Reviewed-by: Omar Sandoval <osandov@fb.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe65bf7b541f78377214ab838e81c432e49d56b9
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Mon Oct 1 14:25:34 2018 -0700

    KVM: VMX: check for existence of secondary exec controls before accessing
    
    commit fd6b6d9b82f97a851fb0078201ddc38fe9728cda upstream.
    
    Return early from vmx_set_virtual_apic_mode() if the processor doesn't
    support VIRTUALIZE_APIC_ACCESSES or VIRTUALIZE_X2APIC_MODE, both of
    which reside in SECONDARY_VM_EXEC_CONTROL.  This eliminates warnings
    due to VMWRITEs to SECONDARY_VM_EXEC_CONTROL (VMCS field 401e) failing
    on processors without secondary exec controls.
    
    Remove the similar check for TPR shadowing as it is incorporated in the
    flexpriority_enabled check and the APIC-related code in
    vmx_update_msr_bitmap() is further gated by VIRTUALIZE_X2APIC_MODE.
    
    Reported-by: Gerhard Wiesinger <redhat@wiesinger.com>
    Fixes: 8d860bbeedef ("kvm: vmx: Basic APIC virtualization controls have three settings")
    Cc: Jim Mattson <jmattson@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe7790c37cf115d9cb4e7c11fee7751952ed3f1c
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Tue Sep 25 13:20:00 2018 -0700

    KVM: x86: fix L1TF's MMIO GFN calculation
    
    commit daa07cbc9ae3da2d61b7ce900c0b9107d134f2c1 upstream.
    
    One defense against L1TF in KVM is to always set the upper five bits
    of the *legal* physical address in the SPTEs for non-present and
    reserved SPTEs, e.g. MMIO SPTEs.  In the MMIO case, the GFN of the
    MMIO SPTE may overlap with the upper five bits that are being usurped
    to defend against L1TF.  To preserve the GFN, the bits of the GFN that
    overlap with the repurposed bits are shifted left into the reserved
    bits, i.e. the GFN in the SPTE will be split into high and low parts.
    When retrieving the GFN from the MMIO SPTE, e.g. to check for an MMIO
    access, get_mmio_spte_gfn() unshifts the affected bits and restores
    the original GFN for comparison.  Unfortunately, get_mmio_spte_gfn()
    neglects to mask off the reserved bits in the SPTE that were used to
    store the upper chunk of the GFN.  As a result, KVM fails to detect
    MMIO accesses whose GPA overlaps the repurprosed bits, which in turn
    causes guest panics and hangs.
    
    Fix the bug by generating a mask that covers the lower chunk of the
    GFN, i.e. the bits that aren't shifted by the L1TF mitigation.  The
    alternative approach would be to explicitly zero the five reserved
    bits that are used to store the upper chunk of the GFN, but that
    requires additional run-time computation and makes an already-ugly
    bit of code even more inscrutable.
    
    I considered adding a WARN_ON_ONCE(low_phys_bits-1 <= PAGE_SHIFT) to
    warn if GENMASK_ULL() generated a nonsensical value, but that seemed
    silly since that would mean a system that supports VMX has less than
    18 bits of physical address space...
    
    Reported-by: Sakari Ailus <sakari.ailus@iki.fi>
    Fixes: d9b47449c1a1 ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
    Cc: Junaid Shahid <junaids@google.com>
    Cc: Jim Mattson <jmattson@google.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Junaid Shahid <junaids@google.com>
    Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d7e3202b7ef899bba11c0ac9bd2b1009ea6b0de
Author: Jann Horn <jannh@google.com>
Date:   Fri Oct 5 15:52:07 2018 -0700

    mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly
    
    commit 58bc4c34d249bf1bc50730a9a209139347cfacfe upstream.
    
    5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even
    on UP") made the availability of the NR_TLB_REMOTE_FLUSH* counters inside
    the kernel unconditional to reduce #ifdef soup, but (either to avoid
    showing dummy zero counters to userspace, or because that code was missed)
    didn't update the vmstat_array, meaning that all following counters would
    be shown with incorrect values.
    
    This only affects kernel builds with
    CONFIG_VM_EVENT_COUNTERS=y && CONFIG_DEBUG_TLBFLUSH=y && CONFIG_SMP=n.
    
    Link: http://lkml.kernel.org/r/20181001143138.95119-2-jannh@google.com
    Fixes: 5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even on UP")
    Signed-off-by: Jann Horn <jannh@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Roman Gushchin <guro@fb.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Christoph Lameter <clameter@sgi.com>
    Cc: Kemi Wang <kemi.wang@intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b9c2cc710f58a1108a33bb1cf8a3526e2470266
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Fri Oct 5 15:51:41 2018 -0700

    mm, thp: fix mlocking THP page with migration enabled
    
    commit e125fe405abedc1dc8a5b2229b80ee91c1434015 upstream.
    
    A transparent huge page is represented by a single entry on an LRU list.
    Therefore, we can only make unevictable an entire compound page, not
    individual subpages.
    
    If a user tries to mlock() part of a huge page, we want the rest of the
    page to be reclaimable.
    
    We handle this by keeping PTE-mapped huge pages on normal LRU lists: the
    PMD on border of VM_LOCKED VMA will be split into PTE table.
    
    Introduction of THP migration breaks[1] the rules around mlocking THP
    pages.  If we had a single PMD mapping of the page in mlocked VMA, the
    page will get mlocked, regardless of PTE mappings of the page.
    
    For tmpfs/shmem it's easy to fix by checking PageDoubleMap() in
    remove_migration_pmd().
    
    Anon THP pages can only be shared between processes via fork().  Mlocked
    page can only be shared if parent mlocked it before forking, otherwise CoW
    will be triggered on mlock().
    
    For Anon-THP, we can fix the issue by munlocking the page on removing PTE
    migration entry for the page.  PTEs for the page will always come after
    mlocked PMD: rmap walks VMAs from oldest to newest.
    
    Test-case:
    
            #include <unistd.h>
            #include <sys/mman.h>
            #include <sys/wait.h>
            #include <linux/mempolicy.h>
            #include <numaif.h>
    
            int main(void)
            {
                    unsigned long nodemask = 4;
                    void *addr;
    
                    addr = mmap((void *)0x20000000UL, 2UL << 20, PROT_READ | PROT_WRITE,
                            MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, -1, 0);
    
                    if (fork()) {
                            wait(NULL);
                            return 0;
                    }
    
                    mlock(addr, 4UL << 10);
                    mbind(addr, 2UL << 20, MPOL_PREFERRED | MPOL_F_RELATIVE_NODES,
                            &nodemask, 4, MPOL_MF_MOVE);
    
                    return 0;
            }
    
    [1] https://lkml.kernel.org/r/CAOMGZ=G52R-30rZvhGxEbkTw7rLLwBGadVYeo--iizcD3upL3A@mail.gmail.com
    
    Link: http://lkml.kernel.org/r/20180917133816.43995-1-kirill.shutemov@linux.intel.com
    Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path")
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
    Reviewed-by: Zi Yan <zi.yan@cs.rutgers.edu>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: <stable@vger.kernel.org>    [4.14+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0af5b07d2e6224ad189dff1492da20e97c14818c
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Fri Oct 5 15:51:29 2018 -0700

    mm: migration: fix migration of huge PMD shared pages
    
    commit 017b1660df89f5fb4bfe66c34e35f7d2031100c7 upstream.
    
    The page migration code employs try_to_unmap() to try and unmap the source
    page.  This is accomplished by using rmap_walk to find all vmas where the
    page is mapped.  This search stops when page mapcount is zero.  For shared
    PMD huge pages, the page map count is always 1 no matter the number of
    mappings.  Shared mappings are tracked via the reference count of the PMD
    page.  Therefore, try_to_unmap stops prematurely and does not completely
    unmap all mappings of the source page.
    
    This problem can result is data corruption as writes to the original
    source page can happen after contents of the page are copied to the target
    page.  Hence, data is lost.
    
    This problem was originally seen as DB corruption of shared global areas
    after a huge page was soft offlined due to ECC memory errors.  DB
    developers noticed they could reproduce the issue by (hotplug) offlining
    memory used to back huge pages.  A simple testcase can reproduce the
    problem by creating a shared PMD mapping (note that this must be at least
    PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
    migrate_pages() to migrate process pages between nodes while continually
    writing to the huge pages being migrated.
    
    To fix, have the try_to_unmap_one routine check for huge PMD sharing by
    calling huge_pmd_unshare for hugetlbfs huge pages.  If it is a shared
    mapping it will be 'unshared' which removes the page table entry and drops
    the reference on the PMD page.  After this, flush caches and TLB.
    
    mmu notifiers are called before locking page tables, but we can not be
    sure of PMD sharing until page tables are locked.  Therefore, check for
    the possibility of PMD sharing before locking so that notifiers can
    prepare for the worst possible case.
    
    Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com
    [mike.kravetz@oracle.com: make _range_in_vma() a static inline]
      Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com
    Fixes: 39dde65c9940 ("shared page table for hugetlb page")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Jerome Glisse <jglisse@redhat.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.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 f5a6974616b46e235120df857e63f681beb4e2cf
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Wed Sep 19 10:29:06 2018 -0700

    perf/core: Add sanity check to deal with pinned event failure
    
    commit befb1b3c2703897c5b8ffb0044dc5d0e5f27c5d7 upstream.
    
    It is possible that a failure can occur during the scheduling of a
    pinned event. The initial portion of perf_event_read_local() contains
    the various error checks an event should pass before it can be
    considered valid. Ensure that the potential scheduling failure
    of a pinned event is checked for and have a credible error.
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: fenghua.yu@intel.com
    Cc: tony.luck@intel.com
    Cc: acme@kernel.org
    Cc: gavin.hindman@intel.com
    Cc: jithu.joseph@intel.com
    Cc: dave.hansen@intel.com
    Cc: hpa@zytor.com
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/6486385d1f30336e9973b24c8c65f5079543d3d3.1537377064.git.reinette.chatre@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>