commit 753be7e83bb80128b4a2aa24214c98466905827c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 26 11:02:22 2018 +0200

    Linux 4.14.37

commit f606893fbbc64d68510c5cc3e64e39971e5f26e0
Author: Benjamin Beichler <benjamin.beichler@uni-rostock.de>
Date:   Wed Mar 7 18:11:07 2018 +0100

    mac80211_hwsim: fix use-after-free bug in hwsim_exit_net
    
    commit 8cfd36a0b53aeb4ec21d81eb79706697b84dfc3d upstream.
    
    When destroying a net namespace, all hwsim interfaces, which are not
    created in default namespace are deleted. But the async deletion of the
    interfaces could last longer than the actual destruction of the
    namespace, which results to an use after free bug. Therefore use
    synchronous deletion in this case.
    
    Fixes: 100cb9ff40e0 ("mac80211_hwsim: Allow managing radios from non-initial namespaces")
    Reported-by: syzbot+70ce058e01259de7bb1d@syzkaller.appspotmail.com
    Signed-off-by: Benjamin Beichler <benjamin.beichler@uni-rostock.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 679833ea18221fe703ebf56213c1b1ca1731bad6
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Thu Mar 29 14:48:30 2018 -0700

    Revert "KVM: X86: Fix SMRAM accessing even if VM is shutdown"
    
    commit 2c151b25441ae5c2da66472abd165af785c9ecd2 upstream.
    
    The bug that led to commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5
    was a benign warning (no adverse affects other than the warning
    itself) that was detected by syzkaller.  Further inspection shows
    that the WARN_ON in question, in handle_ept_misconfig(), is
    unnecessary and flawed (this was also briefly discussed in the
    original patch: https://patchwork.kernel.org/patch/10204649).
    
      * The WARN_ON is unnecessary as kvm_mmu_page_fault() will WARN
        if reserved bits are set in the SPTEs, i.e. it covers the case
        where an EPT misconfig occurred because of a KVM bug.
    
      * The WARN_ON is flawed because it will fire on any system error
        code that is hit while handling the fault, e.g. -ENOMEM can be
        returned by mmu_topup_memory_caches() while handling a legitmate
        MMIO EPT misconfig.
    
    The original behavior of returning -EFAULT when userspace munmaps
    an HVA without first removing the memslot is correct and desirable,
    i.e. KVM is letting userspace know it has generated a bad address.
    Returning RET_PF_EMULATE masks the WARN_ON in the EPT misconfig path,
    but does not fix the underlying bug, i.e. the WARN_ON is bogus.
    
    Furthermore, returning RET_PF_EMULATE has the unwanted side effect of
    causing KVM to attempt to emulate an instruction on any page fault
    with an invalid HVA translation, e.g. a not-present EPT violation
    on a VM_PFNMAP VMA whose fault handler failed to insert a PFN.
    
      * There is no guarantee that the fault is directly related to the
        instruction, i.e. the fault could have been triggered by a side
        effect memory access in the guest, e.g. while vectoring a #DB or
        writing a tracing record.  This could cause KVM to effectively
        mask the fault if KVM doesn't model the behavior leading to the
        fault, i.e. emulation could succeed and resume the guest.
    
      * If emulation does fail, KVM will return EMULATION_FAILED instead
        of -EFAULT, which is a red herring as the user will either debug
        a bogus emulation attempt or scratch their head wondering why we
        were attempting emulation in the first place.
    
    TL;DR: revert to returning -EFAULT and remove the bogus WARN_ON in
    handle_ept_misconfig in a future patch.
    
    This reverts commit 95e057e25892eaa48cad1e2d637b80d0f1a4fac5.
    
    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 75dceb6872b3526a5269a28553f9a35972d03bba
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Sun Mar 11 13:51:32 2018 +0200

    RDMA/mlx5: Fix NULL dereference while accessing XRC_TGT QPs
    
    commit 75a4598209cbe45540baa316c3b51d9db222e96e upstream.
    
    mlx5 modify_qp() relies on FW that the error will be thrown if wrong
    state is supplied. The missing check in FW causes the following crash
    while using XRC_TGT QPs.
    
    [   14.769632] BUG: unable to handle kernel NULL pointer dereference at (null)
    [   14.771085] IP: mlx5_ib_modify_qp+0xf60/0x13f0
    [   14.771894] PGD 800000001472e067 P4D 800000001472e067 PUD 14529067 PMD 0
    [   14.773126] Oops: 0002 [#1] SMP PTI
    [   14.773763] CPU: 0 PID: 365 Comm: ubsan Not tainted 4.16.0-rc1-00038-g8151138c0793 #119
    [   14.775192] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
    [   14.777522] RIP: 0010:mlx5_ib_modify_qp+0xf60/0x13f0
    [   14.778417] RSP: 0018:ffffbf48001c7bd8 EFLAGS: 00010246
    [   14.779346] RAX: 0000000000000000 RBX: ffff9a8f9447d400 RCX: 0000000000000000
    [   14.780643] RDX: 0000000000000000 RSI: 000000000000000a RDI: 0000000000000000
    [   14.781930] RBP: 0000000000000000 R08: 00000000000217b0 R09: ffffffffbc9c1504
    [   14.783214] R10: fffff4a180519480 R11: ffff9a8f94523600 R12: ffff9a8f9493e240
    [   14.784507] R13: ffff9a8f9447d738 R14: 000000000000050a R15: 0000000000000000
    [   14.785800] FS:  00007f545b466700(0000) GS:ffff9a8f9fc00000(0000) knlGS:0000000000000000
    [   14.787073] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   14.787792] CR2: 0000000000000000 CR3: 00000000144be000 CR4: 00000000000006b0
    [   14.788689] Call Trace:
    [   14.789007]  _ib_modify_qp+0x71/0x120
    [   14.789475]  modify_qp.isra.20+0x207/0x2f0
    [   14.790010]  ib_uverbs_modify_qp+0x90/0xe0
    [   14.790532]  ib_uverbs_write+0x1d2/0x3c0
    [   14.791049]  ? __handle_mm_fault+0x93c/0xe40
    [   14.791644]  __vfs_write+0x36/0x180
    [   14.792096]  ? handle_mm_fault+0xc1/0x210
    [   14.792601]  vfs_write+0xad/0x1e0
    [   14.793018]  SyS_write+0x52/0xc0
    [   14.793422]  do_syscall_64+0x75/0x180
    [   14.793888]  entry_SYSCALL_64_after_hwframe+0x21/0x86
    [   14.794527] RIP: 0033:0x7f545ad76099
    [   14.794975] RSP: 002b:00007ffd78787468 EFLAGS: 00000287 ORIG_RAX: 0000000000000001
    [   14.795958] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f545ad76099
    [   14.797075] RDX: 0000000000000078 RSI: 0000000020009000 RDI: 0000000000000003
    [   14.798140] RBP: 00007ffd78787470 R08: 00007ffd78787480 R09: 00007ffd78787480
    [   14.799207] R10: 00007ffd78787480 R11: 0000000000000287 R12: 00005599ada98760
    [   14.800277] R13: 00007ffd78787560 R14: 0000000000000000 R15: 0000000000000000
    [   14.801341] Code: 4c 8b 1c 24 48 8b 83 70 02 00 00 48 c7 83 cc 02 00
    00 00 00 00 00 48 c7 83 24 03 00 00 00 00 00 00 c7 83 2c 03 00 00 00 00
    00 00 <c7> 00 00 00 00 00 48 8b 83 70 02 00 00 c7 40 04 00 00 00 00 4c
    [   14.804012] RIP: mlx5_ib_modify_qp+0xf60/0x13f0 RSP: ffffbf48001c7bd8
    [   14.804838] CR2: 0000000000000000
    [   14.805288] ---[ end trace 3f1da0df5c8b7c37 ]---
    
    Cc: syzkaller <syzkaller@googlegroups.com>
    Reported-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01e71c218219fe40c620a53b2d37beafd95c4e14
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Sun Apr 15 11:23:50 2018 +0200

    perf: Return proper values for user stack errors
    
    commit 78b562fbfa2cf0a9fcb23c3154756b690f4905c1 upstream.
    
    Return immediately when we find issue in the user stack checks. The
    error value could get overwritten by following check for
    PERF_SAMPLE_REGS_INTR.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: syzkaller-bugs@googlegroups.com
    Cc: x86@kernel.org
    Fixes: 60e2364e60e8 ("perf: Add ability to sample machine state on interrupt")
    Link: http://lkml.kernel.org/r/20180415092352.12403-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66038084560d12457f4dd9e5cfb1d7a7859f70a2
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Sun Apr 15 11:23:51 2018 +0200

    perf: Fix sample_max_stack maximum check
    
    commit 5af44ca53d019de47efe6dbc4003dd518e5197ed upstream.
    
    The syzbot hit KASAN bug in perf_callchain_store having the entry stored
    behind the allocated bounds [1].
    
    We miss the sample_max_stack check for the initial event that allocates
    callchain buffers. This missing check allows to create an event with
    sample_max_stack value bigger than the global sysctl maximum:
    
      # sysctl -a | grep perf_event_max_stack
      kernel.perf_event_max_stack = 127
    
      # perf record -vv -C 1 -e cycles/max-stack=256/ kill
      ...
      perf_event_attr:
        size                             112
        ...
        sample_max_stack                 256
      ------------------------------------------------------------
      sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8 = 4
    
    Note the '-C 1', which forces perf record to create just single event.
    Otherwise it opens event for every cpu, then the sample_max_stack check
    fails on the second event and all's fine.
    
    The fix is to run the sample_max_stack check also for the first event
    with callchains.
    
    [1] https://marc.info/?l=linux-kernel&m=152352732920874&w=2
    
    Reported-by: syzbot+7c449856228b63ac951e@syzkaller.appspotmail.com
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: syzkaller-bugs@googlegroups.com
    Cc: x86@kernel.org
    Fixes: 97c79a38cd45 ("perf core: Per event callchain limit")
    Link: http://lkml.kernel.org/r/20180415092352.12403-2-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bcf169444540cbb8646cb415087f5ec83f60432
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Feb 27 19:42:32 2018 +0100

    netfilter: x_tables: limit allocation requests for blob rule heads
    
    commit 9d5c12a7c08f67999772065afd50fb222072114e upstream.
    
    This is a very conservative limit (134217728 rules), but good
    enough to not trigger frequent oom from syzkaller.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 764f2162d97a498269c9b67607fe163692a79aa7
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Feb 27 19:42:35 2018 +0100

    netfilter: compat: reject huge allocation requests
    
    commit 7d7d7e02111e9a4dc9d0658597f528f815d820fd upstream.
    
    no need to bother even trying to allocating huge compat offset arrays,
    such ruleset is rejected later on anyway becaus we refuse to allocate
    overly large rule blobs.
    
    However, compat translation happens before blob allocation, so we should
    add a check there too.
    
    This is supposed to help with fuzzing by avoiding oom-killer.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d92d53365395c97cf819a10cda4693f792cd5b6
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Feb 27 19:42:34 2018 +0100

    netfilter: compat: prepare xt_compat_init_offsets to return errors
    
    commit 9782a11efc072faaf91d4aa60e9d23553f918029 upstream.
    
    should have no impact, function still always returns 0.
    This patch is only to ease review.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82b68ecde5d056588799f0d38e675bbb81fe3b46
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Feb 27 19:42:33 2018 +0100

    netfilter: x_tables: add counters allocation wrapper
    
    commit c84ca954ac9fa67a6ce27f91f01e4451c74fd8f6 upstream.
    
    allows to have size checks in a single spot.
    This is supposed to reduce oom situations when fuzz-testing xtables.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fab0b3ce67a54f45848ee5d6023ef9a42153a2c9
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Feb 27 19:42:31 2018 +0100

    netfilter: x_tables: cap allocations at 512 mbyte
    
    commit 19926968ea86a286aa6fbea16ee3f2e7442f10f0 upstream.
    
    Arbitrary limit, however, this still allows huge rulesets
    (> 1 million rules).  This helps with automated fuzzer as it prevents
    oom-killer invocation.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89f3232c394e8946905b3c3b57ed593872003d60
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Mar 26 15:29:57 2018 +0200

    alarmtimer: Init nanosleep alarm timer on stack
    
    commit bd03143007eb9b03a7f2316c677780561b68ba2a upstream.
    
    syszbot reported the following debugobjects splat:
    
     ODEBUG: object is on stack, but not annotated
     WARNING: CPU: 0 PID: 4185 at lib/debugobjects.c:328
    
     RIP: 0010:debug_object_is_on_stack lib/debugobjects.c:327 [inline]
     debug_object_init+0x17/0x20 lib/debugobjects.c:391
     debug_hrtimer_init kernel/time/hrtimer.c:410 [inline]
     debug_init kernel/time/hrtimer.c:458 [inline]
     hrtimer_init+0x8c/0x410 kernel/time/hrtimer.c:1259
     alarm_init kernel/time/alarmtimer.c:339 [inline]
     alarm_timer_nsleep+0x164/0x4d0 kernel/time/alarmtimer.c:787
     SYSC_clock_nanosleep kernel/time/posix-timers.c:1226 [inline]
     SyS_clock_nanosleep+0x235/0x330 kernel/time/posix-timers.c:1204
     do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    This happens because the hrtimer for the alarm nanosleep is on stack, but
    the code does not use the proper debug objects initialization.
    
    Split out the code for the allocated use cases and invoke
    hrtimer_init_on_stack() for the nanosleep related functions.
    
    Reported-by: syzbot+a3e0726462b2e346a31d@syzkaller.appspotmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: syzkaller-bugs@googlegroups.com
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1803261528270.1585@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76cd54fa70ce7c02e81bc4c3a06de32cdaa84b29
Author: Max Gurtovoy <maxg@mellanox.com>
Date:   Mon Mar 5 20:09:48 2018 +0200

    RDMA/core: Reduce poll batch for direct cq polling
    
    
    [ Upstream commit d3b9e8ad425cfd5b9116732e057f1b48e4d3bcb8 ]
    
    Fix warning limit for kernel stack consumption:
    
    drivers/infiniband/core/cq.c: In function 'ib_process_cq_direct':
    drivers/infiniband/core/cq.c:78:1: error: the frame size of 1032 bytes
    is larger than 1024 bytes [-Werror=frame-larger-than=]
    
    Using smaller ib_wc array on the stack brings us comfortably below that
    limit again.
    
    Fixes: 246d8b184c10 ("IB/cq: Don't force IB_POLL_DIRECT poll context for ib_process_cq_direct")
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Sergey Gorenko <sergeygo@mellanox.com>
    Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    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 de16dfcc510d8ec2981e4ed97e51d17c043cdaec
Author: Mark Salter <msalter@redhat.com>
Date:   Fri Feb 2 09:20:29 2018 -0500

    irqchip/gic-v3: Change pr_debug message to pr_devel
    
    
    [ Upstream commit b6dd4d83dc2f78cebc9a7e6e7e4bc2be4d29b94d ]
    
    The pr_debug() in gic-v3 gic_send_sgi() can trigger a circular locking
    warning:
    
     GICv3: CPU10: ICC_SGI1R_EL1 5000400
     ======================================================
     WARNING: possible circular locking dependency detected
     4.15.0+ #1 Tainted: G        W
     ------------------------------------------------------
     dynamic_debug01/1873 is trying to acquire lock:
      ((console_sem).lock){-...}, at: [<0000000099c891ec>] down_trylock+0x20/0x4c
    
     but task is already holding lock:
      (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #2 (&rq->lock){-.-.}:
            __lock_acquire+0x3b4/0x6e0
            lock_acquire+0xf4/0x2a8
            _raw_spin_lock+0x4c/0x60
            task_fork_fair+0x3c/0x148
            sched_fork+0x10c/0x214
            copy_process.isra.32.part.33+0x4e8/0x14f0
            _do_fork+0xe8/0x78c
            kernel_thread+0x48/0x54
            rest_init+0x34/0x2a4
            start_kernel+0x45c/0x488
    
     -> #1 (&p->pi_lock){-.-.}:
            __lock_acquire+0x3b4/0x6e0
            lock_acquire+0xf4/0x2a8
            _raw_spin_lock_irqsave+0x58/0x70
            try_to_wake_up+0x48/0x600
            wake_up_process+0x28/0x34
            __up.isra.0+0x60/0x6c
            up+0x60/0x68
            __up_console_sem+0x4c/0x7c
            console_unlock+0x328/0x634
            vprintk_emit+0x25c/0x390
            dev_vprintk_emit+0xc4/0x1fc
            dev_printk_emit+0x88/0xa8
            __dev_printk+0x58/0x9c
            _dev_info+0x84/0xa8
            usb_new_device+0x100/0x474
            hub_port_connect+0x280/0x92c
            hub_event+0x740/0xa84
            process_one_work+0x240/0x70c
            worker_thread+0x60/0x400
            kthread+0x110/0x13c
            ret_from_fork+0x10/0x18
    
     -> #0 ((console_sem).lock){-...}:
            validate_chain.isra.34+0x6e4/0xa20
            __lock_acquire+0x3b4/0x6e0
            lock_acquire+0xf4/0x2a8
            _raw_spin_lock_irqsave+0x58/0x70
            down_trylock+0x20/0x4c
            __down_trylock_console_sem+0x3c/0x9c
            console_trylock+0x20/0xb0
            vprintk_emit+0x254/0x390
            vprintk_default+0x58/0x90
            vprintk_func+0xbc/0x164
            printk+0x80/0xa0
            __dynamic_pr_debug+0x84/0xac
            gic_raise_softirq+0x184/0x18c
            smp_cross_call+0xac/0x218
            smp_send_reschedule+0x3c/0x48
            resched_curr+0x60/0x9c
            check_preempt_curr+0x70/0xdc
            wake_up_new_task+0x310/0x470
            _do_fork+0x188/0x78c
            SyS_clone+0x44/0x50
            __sys_trace_return+0x0/0x4
    
     other info that might help us debug this:
    
     Chain exists of:
       (console_sem).lock --> &p->pi_lock --> &rq->lock
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(&rq->lock);
                                    lock(&p->pi_lock);
                                    lock(&rq->lock);
       lock((console_sem).lock);
    
      *** DEADLOCK ***
    
     2 locks held by dynamic_debug01/1873:
      #0:  (&p->pi_lock){-.-.}, at: [<000000001366df53>] wake_up_new_task+0x40/0x470
      #1:  (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc
    
     stack backtrace:
     CPU: 10 PID: 1873 Comm: dynamic_debug01 Tainted: G        W        4.15.0+ #1
     Hardware name: GIGABYTE R120-T34-00/MT30-GS2-00, BIOS T48 10/02/2017
     Call trace:
      dump_backtrace+0x0/0x188
      show_stack+0x24/0x2c
      dump_stack+0xa4/0xe0
      print_circular_bug.isra.31+0x29c/0x2b8
      check_prev_add.constprop.39+0x6c8/0x6dc
      validate_chain.isra.34+0x6e4/0xa20
      __lock_acquire+0x3b4/0x6e0
      lock_acquire+0xf4/0x2a8
      _raw_spin_lock_irqsave+0x58/0x70
      down_trylock+0x20/0x4c
      __down_trylock_console_sem+0x3c/0x9c
      console_trylock+0x20/0xb0
      vprintk_emit+0x254/0x390
      vprintk_default+0x58/0x90
      vprintk_func+0xbc/0x164
      printk+0x80/0xa0
      __dynamic_pr_debug+0x84/0xac
      gic_raise_softirq+0x184/0x18c
      smp_cross_call+0xac/0x218
      smp_send_reschedule+0x3c/0x48
      resched_curr+0x60/0x9c
      check_preempt_curr+0x70/0xdc
      wake_up_new_task+0x310/0x470
      _do_fork+0x188/0x78c
      SyS_clone+0x44/0x50
      __sys_trace_return+0x0/0x4
     GICv3: CPU0: ICC_SGI1R_EL1 12000
    
    This could be fixed with printk_deferred() but that might lessen its
    usefulness for debugging. So change it to pr_devel to keep it out of
    production kernels. Developers working on gic-v3 can enable it as
    needed in their kernels.
    
    Signed-off-by: Mark Salter <msalter@redhat.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4032cd4fd3aec5d76d5ad9451f6d31ff6003c7cf
Author: Michael Kelley <mhkelley@outlook.com>
Date:   Wed Feb 14 02:54:03 2018 +0000

    cpumask: Make for_each_cpu_wrap() available on UP as well
    
    
    [ Upstream commit d207af2eab3f8668b95ad02b21930481c42806fd ]
    
    for_each_cpu_wrap() was originally added in the #else half of a
    large "#if NR_CPUS == 1" statement, but was omitted in the #if
    half.  This patch adds the missing #if half to prevent compile
    errors when NR_CPUS is 1.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Michael Kelley <mhkelley@outlook.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: kys@microsoft.com
    Cc: martin.petersen@oracle.com
    Cc: mikelley@microsoft.com
    Fixes: c743f0a5c50f ("sched/fair, cpumask: Export for_each_cpu_wrap()")
    Link: http://lkml.kernel.org/r/SN6PR1901MB2045F087F59450507D4FCC17CBF50@SN6PR1901MB2045.namprd19.prod.outlook.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 c834b955d3f00789b2c95a6e642a058f12ae9096
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Thu Feb 1 09:03:29 2018 -0800

    irqchip/gic-v3: Ignore disabled ITS nodes
    
    
    [ Upstream commit 95a2562590c2f64a0398183f978d5cf3db6d0284 ]
    
    On some platforms there's an ITS available but it's not enabled
    because reading or writing the registers is denied by the
    firmware. In fact, reading or writing them will cause the system
    to reset. We could remove the node from DT in such a case, but
    it's better to skip nodes that are marked as "disabled" in DT so
    that we can describe the hardware that exists and use the status
    property to indicate how the firmware has configured things.
    
    Cc: Stuart Yoder <stuyoder@gmail.com>
    Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Rajendra Nayak <rnayak@codeaurora.org>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d8d8d23c485d78b00c6a44629b711987ac1234b
Author: Thomas Richter <tmricht@linux.vnet.ibm.com>
Date:   Wed Jan 17 09:38:31 2018 +0100

    perf test: Fix test trace+probe_libc_inet_pton.sh for s390x
    
    
    [ Upstream commit 7a92453620d42c3a5fea94a864dc6aa04c262b93 ]
    
    On Intel test case trace+probe_libc_inet_pton.sh succeeds and the
    output is:
    
    [root@f27 perf]# ./perf trace --no-syscalls
                      -e probe_libc:inet_pton/max-stack=3/ ping -6 -c 1 ::1
    PING ::1(::1) 56 data bytes
    64 bytes from ::1: icmp_seq=1 ttl=64 time=0.037 ms
    
     --- ::1 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.037/0.037/0.037/0.000 ms
         0.000 probe_libc:inet_pton:(7fa40ac618a0))
                  __GI___inet_pton (/usr/lib64/libc-2.26.so)
                  getaddrinfo (/usr/lib64/libc-2.26.so)
                  main (/usr/bin/ping)
    
    The kernel stack unwinder is used, it is specified implicitly
    as call-graph=fp (frame pointer).
    
    On s390x only dwarf is available for stack unwinding. It is also
    done in user space. This requires different parameter setup
    and result checking for s390x and Intel.
    
    This patch adds separate perf trace setup and result checking
    for Intel and s390x. On s390x specify this command line to
    get a call-graph and handle the different call graph result
    checking:
    
    [root@s35lp76 perf]# ./perf trace --no-syscalls
            -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
    PING ::1(::1) 56 data bytes
    64 bytes from ::1: icmp_seq=1 ttl=64 time=0.041 ms
    
     --- ::1 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.041/0.041/0.041/0.000 ms
         0.000 probe_libc:inet_pton:(3ffb9942060))
                __GI___inet_pton (/usr/lib64/libc-2.26.so)
                gaih_inet (inlined)
                __GI_getaddrinfo (inlined)
                main (/usr/bin/ping)
                __libc_start_main (/usr/lib64/libc-2.26.so)
                _start (/usr/bin/ping)
    [root@s35lp76 perf]#
    
    Before:
    [root@s8360047 perf]# ./perf test -vv 58
    58: probe libc's inet_pton & backtrace it with ping       :
     --- start ---
    test child forked, pid 26349
    PING ::1(::1) 56 data bytes
    64 bytes from ::1: icmp_seq=1 ttl=64 time=0.079 ms
     --- ::1 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.079/0.079/0.079/0.000 ms
    0.000 probe_libc:inet_pton:(3ff925c2060))
    test child finished with -1
     ---- end ----
    probe libc's inet_pton & backtrace it with ping: FAILED!
    [root@s8360047 perf]#
    
    After:
    [root@s35lp76 perf]# ./perf test -vv 57
    57: probe libc's inet_pton & backtrace it with ping       :
     --- start ---
    test child forked, pid 38708
    PING ::1(::1) 56 data bytes
    64 bytes from ::1: icmp_seq=1 ttl=64 time=0.038 ms
     --- ::1 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.038/0.038/0.038/0.000 ms
    0.000 probe_libc:inet_pton:(3ff87342060))
    __GI___inet_pton (/usr/lib64/libc-2.26.so)
    gaih_inet (inlined)
    __GI_getaddrinfo (inlined)
    main (/usr/bin/ping)
    __libc_start_main (/usr/lib64/libc-2.26.so)
    _start (/usr/bin/ping)
    test child finished with 0
     ---- end ----
    probe libc's inet_pton & backtrace it with ping: Ok
    [root@s35lp76 perf]#
    
    On Intel the test case runs unchanged and succeeds.
    
    Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
    Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Link: http://lkml.kernel.org/r/20180117083831.101001-1-tmricht@linux.vnet.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 74cd9414788ca5de87b2df2103d39a7705f202f1
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue Feb 13 17:45:11 2018 +1000

    powerpc/powernv: IMC fix out of bounds memory access at shutdown
    
    
    [ Upstream commit e7bde88cdb4f0e432398a7d29ca2a15d2c18952a ]
    
    The OPAL IMC driver's shutdown handler disables nest PMU counters by
    walking nodes and taking the first CPU out of their cpumask, which is
    used to index into the paca (get_hard_smp_processor_id()). This does
    not always do the right thing, and in particular for CPU-less nodes it
    returns NR_CPUS and that overruns the paca and dereferences random
    memory.
    
    Fix it by being more careful about checking returned CPU, and only
    using online CPUs. It's not clear this shutdown code makes sense after
    commit 885dcd709b ("powerpc/perf: Add nest IMC PMU support"), but this
    should not make things worse
    
    Currently the bug causes us to call OPAL with a junk CPU number. A
    separate patch in development to change the way pacas are allocated
    escalates this bug into a crash:
    
      Unable to handle kernel paging request for data at address 0x2a21af1eeb000076
      Faulting instruction address: 0xc0000000000a5468
      Oops: Kernel access of bad area, sig: 11 [#1]
      ...
      NIP opal_imc_counters_shutdown+0x148/0x1d0
      LR  opal_imc_counters_shutdown+0x134/0x1d0
      Call Trace:
       opal_imc_counters_shutdown+0x134/0x1d0 (unreliable)
       platform_drv_shutdown+0x44/0x60
       device_shutdown+0x1f8/0x350
       kernel_restart_prepare+0x54/0x70
       kernel_restart+0x28/0xc0
       SyS_reboot+0x1d0/0x2c0
       system_call+0x58/0x6c
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c74e004c62739d6a6a002730d57fe851ff42f346
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Feb 13 13:22:57 2018 +0000

    locking/qspinlock: Ensure node->count is updated before initialising node
    
    
    [ Upstream commit 11dc13224c975efcec96647a4768a6f1bb7a19a8 ]
    
    When queuing on the qspinlock, the count field for the current CPU's head
    node is incremented. This needn't be atomic because locking in e.g. IRQ
    context is balanced and so an IRQ will return with node->count as it
    found it.
    
    However, the compiler could in theory reorder the initialisation of
    node[idx] before the increment of the head node->count, causing an
    IRQ to overwrite the initialised node and potentially corrupt the lock
    state.
    
    Avoid the potential for this harmful compiler reordering by placing a
    barrier() between the increment of the head node->count and the subsequent
    node initialisation.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1518528177-19169-3-git-send-email-will.deacon@arm.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 5350cb0111d23ff50b66bcdd9ee5fdf3d64a9f01
Author: mike.travis@hpe.com <mike.travis@hpe.com>
Date:   Mon Feb 5 16:15:04 2018 -0600

    x86/platform/UV: Fix GAM Range Table entries less than 1GB
    
    
    [ Upstream commit c25d99d20ba69824a1e2cc118e04b877cd427afc ]
    
    The latest UV platforms include the new ApachePass NVDIMMs into the
    UV address space.  This has introduced address ranges in the Global
    Address Map Table that are less than the previous lowest range, which
    was 2GB.  Fix the address calculation so it accommodates address ranges
    from bytes to exabytes.
    
    Signed-off-by: Mike Travis <mike.travis@hpe.com>
    Reviewed-by: Andrew Banman <andrew.banman@hpe.com>
    Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Russ Anderson <russ.anderson@hpe.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20180205221503.190219903@stormcage.americas.sgi.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 288b373264c51f490676a860c705ec70e4d83a67
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Tue Feb 13 16:39:33 2018 +0530

    powerpc/mm/hash64: Zero PGD pages on allocation
    
    
    [ Upstream commit fc5c2f4a55a2c258e12013cdf287cf266dbcd2a7 ]
    
    On powerpc we allocate page table pages from slab caches of different
    sizes. Currently we have a constructor that zeroes out the objects when
    we allocate them for the first time.
    
    We expect the objects to be zeroed out when we free the the object
    back to slab cache. This happens in the unmap path. For hugetlb pages
    we call huge_pte_get_and_clear() to do that.
    
    With the current configuration of page table size, both PUD and PGD
    level tables are allocated from the same slab cache. At the PUD level,
    we use the second half of the table to store the slot information. But
    we never clear that when unmapping.
    
    When such a freed object is then allocated for a PGD page, the second
    half of the page table page will not be zeroed as expected. This
    results in a kernel crash.
    
    Fix it by always clearing PGD pages when they're allocated.
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    [mpe: Change log wording and formatting, add whitespace]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4d6e4598a29f6f7df6937d943c01e1eeb9ee871
Author: Jia Zhang <zhang.jia@linux.alibaba.com>
Date:   Mon Feb 12 22:44:53 2018 +0800

    vfs/proc/kcore, x86/mm/kcore: Fix SMAP fault when dumping vsyscall user page
    
    
    [ Upstream commit 595dd46ebfc10be041a365d0a3fa99df50b6ba73 ]
    
    Commit:
    
      df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
    
    ... introduced a bounce buffer to work around CONFIG_HARDENED_USERCOPY=y.
    However, accessing the vsyscall user page will cause an SMAP fault.
    
    Replace memcpy() with copy_from_user() to fix this bug works, but adding
    a common way to handle this sort of user page may be useful for future.
    
    Currently, only vsyscall page requires KCORE_USER.
    
    Signed-off-by: Jia Zhang <zhang.jia@linux.alibaba.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: jolsa@redhat.com
    Link: http://lkml.kernel.org/r/1518446694-21124-2-git-send-email-zhang.jia@linux.alibaba.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 c064b7c1d203cd5d781c316ac9c8049ba772684f
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri Feb 9 08:11:26 2018 -0800

    PM / wakeirq: Fix unbalanced IRQ enable for wakeirq
    
    
    [ Upstream commit 69728051f5bf15efaf6edfbcfe1b5a49a2437918 ]
    
    If a device is runtime PM suspended when we enter suspend and has
    a dedicated wake IRQ, we can get the following warning:
    
    WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94
    [  102.087860] Unbalanced enable for IRQ 147
    ...
    (enable_irq) from [<c06117a8>] (dev_pm_arm_wake_irq+0x4c/0x60)
    (dev_pm_arm_wake_irq) from [<c0618360>]
     (device_wakeup_arm_wake_irqs+0x58/0x9c)
    (device_wakeup_arm_wake_irqs) from [<c0615948>]
    (dpm_suspend_noirq+0x10/0x48)
    (dpm_suspend_noirq) from [<c01ac7ac>]
    (suspend_devices_and_enter+0x30c/0xf14)
    (suspend_devices_and_enter) from [<c01adf20>]
    (enter_state+0xad4/0xbd8)
    (enter_state) from [<c01ad3ec>] (pm_suspend+0x38/0x98)
    (pm_suspend) from [<c01ab3e8>] (state_store+0x68/0xc8)
    
    This is because the dedicated wake IRQ for the device may have been
    already enabled earlier by dev_pm_enable_wake_irq_check().  Fix the
    issue by checking for runtime PM suspended status.
    
    This issue can be easily reproduced by setting serial console log level
    to zero, letting the serial console idle, and suspend the system from
    an ssh terminal.  On resume, dmesg will have the warning above.
    
    The reason why I have not run into this issue earlier has been that I
    typically run my PM test cases from on a serial console instead over ssh.
    
    Fixes: c84345597558 (PM / wakeirq: Enable dedicated wakeirq for suspend)
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afa0ce071488154e28d60b510dd0a3c3d86f7992
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Feb 9 22:55:28 2018 +0100

    ACPI / EC: Restore polling during noirq suspend/resume phases
    
    
    [ Upstream commit 3cd091a773936c54344a519f7ee1379ccb620bee ]
    
    Commit 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a
    regression) modified the ACPI EC driver so that it doesn't switch
    over to busy polling mode during noirq stages of system suspend and
    resume in an attempt to fix an issue resulting from that behavior.
    
    However, that modification introduced a system resume regression on
    Thinkpad X240, so make the EC driver switch over to the polling mode
    during noirq stages of system suspend and resume again, which
    effectively reverts the problematic commit.
    
    Fixes: 662591461c4b (ACPI / EC: Drop EC noirq hooks to fix a regression)
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=197863
    Reported-by: Markus Demleitner <m@tfiu.de>
    Tested-by: Markus Demleitner <m@tfiu.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85bd5c686fe9e60557b5d8610110c49381ed4a07
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Feb 9 14:49:44 2018 +0100

    bpf: fix rlimit in reuseport net selftest
    
    
    [ Upstream commit 941ff6f11c020913f5cddf543a9ec63475d7c082 ]
    
    Fix two issues in the reuseport_bpf selftests that were
    reported by Linaro CI:
    
      [...]
      + ./reuseport_bpf
      ---- IPv4 UDP ----
      Testing EBPF mod 10...
      Reprograming, testing mod 5...
      ./reuseport_bpf: ebpf error. log:
      0: (bf) r6 = r1
      1: (20) r0 = *(u32 *)skb[0]
      2: (97) r0 %= 10
      3: (95) exit
      processed 4 insns
      : Operation not permitted
      + echo FAIL
      [...]
      ---- IPv4 TCP ----
      Testing EBPF mod 10...
      ./reuseport_bpf: failed to bind send socket: Address already in use
      + echo FAIL
      [...]
    
    For the former adjust rlimit since this was the cause of
    failure for loading the BPF prog, and for the latter add
    SO_REUSEADDR.
    
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Link: https://bugs.linaro.org/show_bug.cgi?id=3502
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    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 ee5fe4bdcf2aea19ee238d6c3844dfe3c7c77e8b
Author: Niklas Cassel <niklas.cassel@axis.com>
Date:   Fri Feb 9 17:22:45 2018 +0100

    net: stmmac: discard disabled flags in interrupt status register
    
    
    [ Upstream commit 1b84ca187510f60f00f4e15255043ce19bb30410 ]
    
    The interrupt status register in both dwmac1000 and dwmac4 ignores
    interrupt enable (for dwmac4) / interrupt mask (for dwmac1000).
    Therefore, if we want to check only the bits that can actually trigger
    an irq, we have to filter the interrupt status register manually.
    
    Commit 0a764db10337 ("stmmac: Discard masked flags in interrupt status
    register") fixed this for dwmac1000. Fix the same issue for dwmac4.
    
    Just like commit 0a764db10337 ("stmmac: Discard masked flags in
    interrupt status register"), this makes sure that we do not get
    spurious link up/link down prints.
    
    Signed-off-by: Niklas Cassel <niklas.cassel@axis.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 26bebd5a7865376d5944b0206d7b271ab76f116b
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Fri Feb 9 09:39:42 2018 -0500

    SUNRPC: Don't call __UDPX_INC_STATS() from a preemptible context
    
    
    [ Upstream commit 0afa6b4412988019db14c6bfb8c6cbdf120ca9ad ]
    
    Calling __UDPX_INC_STATS() from a preemptible context leads to a
    warning of the form:
    
     BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u5:0/31
     caller is xs_udp_data_receive_workfn+0x194/0x270
     CPU: 1 PID: 31 Comm: kworker/u5:0 Not tainted 4.15.0-rc8-00076-g90ea9f1 #2
     Workqueue: xprtiod xs_udp_data_receive_workfn
     Call Trace:
      dump_stack+0x85/0xc1
      check_preemption_disabled+0xce/0xe0
      xs_udp_data_receive_workfn+0x194/0x270
      process_one_work+0x318/0x620
      worker_thread+0x20a/0x390
      ? process_one_work+0x620/0x620
      kthread+0x120/0x130
      ? __kthread_bind_mask+0x60/0x60
      ret_from_fork+0x24/0x30
    
    Since we're taking a spinlock in those functions anyway, let's fix the
    issue by moving the call so that it occurs under the spinlock.
    
    Reported-by: kernel test robot <fengguang.wu@intel.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f58e4ecb9b2e75b8a2a32b990241f16363fd3673
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Wed Feb 7 19:49:54 2018 +1100

    KVM: PPC: Book3S HV: Fix handling of secondary HPTEG in HPT resizing code
    
    
    [ Upstream commit 05f2bb0313a2855e491dadfc8319b7da261d7074 ]
    
    This fixes the computation of the HPTE index to use when the HPT
    resizing code encounters a bolted HPTE which is stored in its
    secondary HPTE group.  The code inverts the HPTE group number, which
    is correct, but doesn't then mask it with new_hash_mask.  As a result,
    new_pteg will be effectively negative, resulting in new_hptep
    pointing before the new HPT, which will corrupt memory.
    
    In addition, this removes two BUG_ON statements.  The condition that
    the BUG_ONs were testing -- that we have computed the hash value
    incorrectly -- has never been observed in testing, and if it did
    occur, would only affect the guest, not the host.  Given that
    BUG_ON should only be used in conditions where the kernel (i.e.
    the host kernel, in this case) can't possibly continue execution,
    it is not appropriate here.
    
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    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 d6b00490a04d2434088c87c3afe2e827bdaab61b
Author: Jesper Dangaard Brouer <brouer@redhat.com>
Date:   Thu Feb 8 12:48:32 2018 +0100

    tools/libbpf: handle issues with bpf ELF objects containing .eh_frames
    
    
    [ Upstream commit e3d91b0ca523d53158f435a3e13df7f0cb360ea2 ]
    
    V3: More generic skipping of relo-section (suggested by Daniel)
    
    If clang >= 4.0.1 is missing the option '-target bpf', it will cause
    llc/llvm to create two ELF sections for "Exception Frames", with
    section names '.eh_frame' and '.rel.eh_frame'.
    
    The BPF ELF loader library libbpf fails when loading files with these
    sections.  The other in-kernel BPF ELF loader in samples/bpf/bpf_load.c,
    handle this gracefully. And iproute2 loader also seems to work with these
    "eh" sections.
    
    The issue in libbpf is caused by bpf_object__elf_collect() skipping
    some sections, and later when performing relocation it will be
    pointing to a skipped section, as these sections cannot be found by
    bpf_object__find_prog_by_idx() in bpf_object__collect_reloc().
    
    This is a general issue that also occurs for other sections, like
    debug sections which are also skipped and can have relo section.
    
    As suggested by Daniel.  To avoid keeping state about all skipped
    sections, instead perform a direct qlookup in the ELF object.  Lookup
    the section that the relo-section points to and check if it contains
    executable machine instructions (denoted by the sh_flags
    SHF_EXECINSTR).  Use this check to also skip irrelevant relo-sections.
    
    Note, for samples/bpf/ the '-target bpf' parameter to clang cannot be used
    due to incompatibility with asm embedded headers, that some of the samples
    include. This is explained in more details by Yonghong Song in bpf_devel_QA.
    
    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 327aac8ccbc54a0a320428664385b1d8bd8fd033
Author: Mathieu Malaterre <malat@debian.org>
Date:   Wed Feb 7 20:35:00 2018 +0100

    net: Extra '_get' in declaration of arch_get_platform_mac_address
    
    
    [ Upstream commit e728789c52afccc1275cba1dd812f03abe16ea3c ]
    
    In commit c7f5d105495a ("net: Add eth_platform_get_mac_address() helper."),
    two declarations were added:
    
      int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr);
      unsigned char *arch_get_platform_get_mac_address(void);
    
    An extra '_get' was introduced in arch_get_platform_get_mac_address, remove
    it. Fix compile warning using W=1:
    
      CC      net/ethernet/eth.o
    net/ethernet/eth.c:523:24: warning: no previous prototype for ‘arch_get_platform_mac_address’ [-Wmissing-prototypes]
     unsigned char * __weak arch_get_platform_mac_address(void)
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      AR      net/ethernet/built-in.o
    
    Signed-off-by: Mathieu Malaterre <malat@debian.org>
    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 0b1fa241dd86820659cb477caa73e3c232d344e2
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Feb 2 14:28:59 2018 -0500

    svcrdma: Fix Read chunk round-up
    
    
    [ Upstream commit 175e03101d36c3034f3c80038d4c28838351a7f2 ]
    
    A single NFSv4 WRITE compound can often have three operations:
    PUTFH, WRITE, then GETATTR.
    
    When the WRITE payload is sent in a Read chunk, the client places
    the GETATTR in the inline part of the RPC/RDMA message, just after
    the WRITE operation (sans payload). The position value in the Read
    chunk enables the receiver to insert the Read chunk at the correct
    place in the received XDR stream; that is between the WRITE and
    GETATTR.
    
    According to RFC 8166, an NFS/RDMA client does not have to add XDR
    round-up to the Read chunk that carries the WRITE payload. The
    receiver adds XDR round-up padding if it is absent and the
    receiver's XDR decoder requires it to be present.
    
    Commit 193bcb7b3719 ("svcrdma: Populate tail iovec when receiving")
    attempted to add support for receiving such a compound so that just
    the WRITE payload appears in rq_arg's page list, and the trailing
    GETATTR is placed in rq_arg's tail iovec. (TCP just strings the
    whole compound into the head iovec and page list, without regard
    to the alignment of the WRITE payload).
    
    The server transport logic also had to accommodate the optional XDR
    round-up of the Read chunk, which it did simply by lengthening the
    tail iovec when round-up was needed. This approach is adequate for
    the NFSv2 and NFSv3 WRITE decoders.
    
    Unfortunately it is not sufficient for nfsd4_decode_write. When the
    Read chunk length is a couple of bytes less than PAGE_SIZE, the
    computation at the end of nfsd4_decode_write allows argp->pagelen to
    go negative, which breaks the logic in read_buf that looks for the
    tail iovec.
    
    The result is that a WRITE operation whose payload length is just
    less than a multiple of a page succeeds, but the subsequent GETATTR
    in the same compound fails with NFS4ERR_OP_ILLEGAL because the XDR
    decoder can't find it. Clients ignore the error, but they must
    update their attribute cache via a separate round trip.
    
    As nfsd4_decode_write appears to expect the payload itself to always
    have appropriate XDR round-up, have svc_rdma_build_normal_read_chunk
    add the Read chunk XDR round-up to the page_len rather than
    lengthening the tail iovec.
    
    Reported-by: Olga Kornievskaia <kolga@netapp.com>
    Fixes: 193bcb7b3719 ("svcrdma: Populate tail iovec when receiving")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Tested-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e781fff7b78ffd1ae7149e8f5ac7512dab32cfa5
Author: David Howells <dhowells@redhat.com>
Date:   Thu Feb 8 15:59:07 2018 +0000

    rxrpc: Don't put crypto buffers on the stack
    
    
    [ Upstream commit 8c2f826dc36314059ac146c78d3bf8056b626446 ]
    
    Don't put buffers of data to be handed to crypto on the stack as this may
    cause an assertion failure in the kernel (see below).  Fix this by using an
    kmalloc'd buffer instead.
    
    kernel BUG at ./include/linux/scatterlist.h:147!
    ...
    RIP: 0010:rxkad_encrypt_response.isra.6+0x191/0x1b0 [rxrpc]
    RSP: 0018:ffffbe2fc06cfca8 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff989277d59900 RCX: 0000000000000028
    RDX: 0000259dc06cfd88 RSI: 0000000000000025 RDI: ffffbe30406cfd88
    RBP: ffffbe2fc06cfd60 R08: ffffbe2fc06cfd08 R09: ffffbe2fc06cfd08
    R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff7c5f80d9f95
    R13: ffffbe2fc06cfd88 R14: ffff98927a3f7aa0 R15: ffffbe2fc06cfd08
    FS:  0000000000000000(0000) GS:ffff98927fc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055b1ff28f0f8 CR3: 000000001b412003 CR4: 00000000003606f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     rxkad_respond_to_challenge+0x297/0x330 [rxrpc]
     rxrpc_process_connection+0xd1/0x690 [rxrpc]
     ? process_one_work+0x1c3/0x680
     ? __lock_is_held+0x59/0xa0
     process_one_work+0x249/0x680
     worker_thread+0x3a/0x390
     ? process_one_work+0x680/0x680
     kthread+0x121/0x140
     ? kthread_create_worker_on_cpu+0x70/0x70
     ret_from_fork+0x3a/0x50
    
    Reported-by: Jonathan Billings <jsbillings@jsbillings.org>
    Reported-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Jonathan Billings <jsbillings@jsbillings.org>
    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 c5ce9e5b57cc24142e38b6441c23e0e8bac4ef54
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Feb 6 17:19:03 2018 -0500

    selftests/ftrace: Add some missing glob checks
    
    
    [ Upstream commit 97fe22adf33f06519bfdf7dad33bcd562e366c8f ]
    
    Al Viro discovered a bug in the glob ftrace filtering code where "*a*b" is
    treated the same as "a*b", and functions that would be selected by "*a*b"
    but not "a*b" are not selected with "*a*b".
    
    Add tests for patterns "*a*b" and "a*b*" to the glob selftest.
    
    Link: http://lkml.kernel.org/r/20180127170748.GF13338@ZenIV.linux.org.uk
    
    Cc: Shuah Khan <shuah@kernel.org>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae9c78af577f3741357851e6e98223d67f07d4a6
Author: Chen Yu <yu.c.chen@intel.com>
Date:   Mon Jan 29 10:27:57 2018 +0800

    cpufreq: intel_pstate: Enable HWP during system resume on CPU0
    
    
    [ Upstream commit 70f6bf2a3b7e40c3f802b0ea837762a8bc6c1430 ]
    
    When maxcpus=1 is in the kernel command line, the BP is responsible
    for re-enabling the HWP - because currently only the APs invoke
    intel_pstate_hwp_enable() during their online process - which might
    put the system into unstable state after resume.
    
    Fix this by enabling the HWP explicitly on BP during resume.
    
    Reported-by: Doug Smythies <dsmythies@telus.net>
    Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Yu Chen <yu.c.chen@intel.com>
    [ rjw: Subject/changelog, minor modifications ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4c9fd55899fd780ee010eda172fe574c65bf56e
Author: Tang Junhui <tang.junhui@zte.com.cn>
Date:   Wed Feb 7 11:41:45 2018 -0800

    bcache: return attach error when no cache set exist
    
    
    [ Upstream commit 7f4fc93d4713394ee8f1cd44c238e046e11b4f15 ]
    
    I attach a back-end device to a cache set, and the cache set is not
    registered yet, this back-end device did not attach successfully, and no
    error returned:
    [root]# echo 87859280-fec6-4bcc-20df7ca8f86b > /sys/block/sde/bcache/attach
    [root]#
    
    In sysfs_attach(), the return value "v" is initialized to "size" in
    the beginning, and if no cache set exist in bch_cache_sets, the "v" value
    would not change any more, and return to sysfs, sysfs regard it as success
    since the "size" is a positive number.
    
    This patch fixes this issue by assigning "v" with "-ENOENT" in the
    initialization.
    
    Signed-off-by: Tang Junhui <tang.junhui@zte.com.cn>
    Reviewed-by: Michael Lyle <mlyle@lyle.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c8e0270dc7afb10d4e06be4adfd177db5cb3cb8
Author: Tang Junhui <tang.junhui@zte.com.cn>
Date:   Wed Feb 7 11:41:46 2018 -0800

    bcache: fix for data collapse after re-attaching an attached device
    
    
    [ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]
    
    back-end device sdm has already attached a cache_set with ID
    f67ebe1f-f8bc-4d73-bfe5-9dc88607f119, then try to attach with
    another cache set, and it returns with an error:
    [root]# cd /sys/block/sdm/bcache
    [root]# echo 5ccd0a63-148e-48b8-afa2-aca9cbd6279f > attach
    -bash: echo: write error: Invalid argument
    
    After that, execute a command to modify the label of bcache
    device:
    [root]# echo data_disk1 > label
    
    Then we reboot the system, when the system power on, the back-end
    device can not attach to cache_set, a messages show in the log:
    Feb  5 12:05:52 ceph152 kernel: [922385.508498] bcache:
    bch_cached_dev_attach() couldn't find uuid for sdm in set
    
    In sysfs_attach(), dc->sb.set_uuid was assigned to the value
    which input through sysfs, no matter whether it is success
    or not in bch_cached_dev_attach(). For example, If the back-end
    device has already attached to an cache set, bch_cached_dev_attach()
    would fail, but dc->sb.set_uuid was changed. Then modify the
    label of bcache device, it will call bch_write_bdev_super(),
    which would write the dc->sb.set_uuid to the super block, so we
    record a wrong cache set ID in the super block, after the system
    reboot, the cache set couldn't find the uuid of the back-end
    device, so the bcache device couldn't exist and use any more.
    
    In this patch, we don't assigned cache set ID to dc->sb.set_uuid
    in sysfs_attach() directly, but input it into bch_cached_dev_attach(),
    and assigned dc->sb.set_uuid to the cache set ID after the back-end
    device attached to the cache set successful.
    
    Signed-off-by: Tang Junhui <tang.junhui@zte.com.cn>
    Reviewed-by: Michael Lyle <mlyle@lyle.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 311e31419b7240151de0cf7aa3f2d972ee103a5c
Author: Tang Junhui <tang.junhui@zte.com.cn>
Date:   Wed Feb 7 11:41:43 2018 -0800

    bcache: fix for allocator and register thread race
    
    
    [ Upstream commit 682811b3ce1a5a4e20d700939a9042f01dbc66c4 ]
    
    After long time running of random small IO writing,
    I reboot the machine, and after the machine power on,
    I found bcache got stuck, the stack is:
    [root@ceph153 ~]# cat /proc/2510/task/*/stack
    [<ffffffffa06b2455>] closure_sync+0x25/0x90 [bcache]
    [<ffffffffa06b6be8>] bch_journal+0x118/0x2b0 [bcache]
    [<ffffffffa06b6dc7>] bch_journal_meta+0x47/0x70 [bcache]
    [<ffffffffa06be8f7>] bch_prio_write+0x237/0x340 [bcache]
    [<ffffffffa06a8018>] bch_allocator_thread+0x3c8/0x3d0 [bcache]
    [<ffffffff810a631f>] kthread+0xcf/0xe0
    [<ffffffff8164c318>] ret_from_fork+0x58/0x90
    [<ffffffffffffffff>] 0xffffffffffffffff
    [root@ceph153 ~]# cat /proc/2038/task/*/stack
    [<ffffffffa06b1abd>] __bch_btree_map_nodes+0x12d/0x150 [bcache]
    [<ffffffffa06b1bd1>] bch_btree_insert+0xf1/0x170 [bcache]
    [<ffffffffa06b637f>] bch_journal_replay+0x13f/0x230 [bcache]
    [<ffffffffa06c75fe>] run_cache_set+0x79a/0x7c2 [bcache]
    [<ffffffffa06c0cf8>] register_bcache+0xd48/0x1310 [bcache]
    [<ffffffff812f702f>] kobj_attr_store+0xf/0x20
    [<ffffffff8125b216>] sysfs_write_file+0xc6/0x140
    [<ffffffff811dfbfd>] vfs_write+0xbd/0x1e0
    [<ffffffff811e069f>] SyS_write+0x7f/0xe0
    [<ffffffff8164c3c9>] system_call_fastpath+0x16/0x1
    The stack shows the register thread and allocator thread
    were getting stuck when registering cache device.
    
    I reboot the machine several times, the issue always
    exsit in this machine.
    
    I debug the code, and found the call trace as bellow:
    register_bcache()
       ==>run_cache_set()
          ==>bch_journal_replay()
             ==>bch_btree_insert()
                ==>__bch_btree_map_nodes()
                   ==>btree_insert_fn()
                      ==>btree_split() //node need split
                         ==>btree_check_reserve()
    In btree_check_reserve(), It will check if there is enough buckets
    of RESERVE_BTREE type, since allocator thread did not work yet, so
    no buckets of RESERVE_BTREE type allocated, so the register thread
    waits on c->btree_cache_wait, and goes to sleep.
    
    Then the allocator thread initialized, the call trace is bellow:
    bch_allocator_thread()
    ==>bch_prio_write()
       ==>bch_journal_meta()
          ==>bch_journal()
             ==>journal_wait_for_write()
    In journal_wait_for_write(), It will check if journal is full by
    journal_full(), but the long time random small IO writing
    causes the exhaustion of journal buckets(journal.blocks_free=0),
    In order to release the journal buckets,
    the allocator calls btree_flush_write() to flush keys to
    btree nodes, and waits on c->journal.wait until btree nodes writing
    over or there has already some journal buckets space, then the
    allocator thread goes to sleep. but in btree_flush_write(), since
    bch_journal_replay() is not finished, so no btree nodes have journal
    (condition "if (btree_current_write(b)->journal)" never satisfied),
    so we got no btree node to flush, no journal bucket released,
    and allocator sleep all the times.
    
    Through the above analysis, we can see that:
    1) Register thread wait for allocator thread to allocate buckets of
       RESERVE_BTREE type;
    2) Alloctor thread wait for register thread to replay journal, so it
       can flush btree nodes and get journal bucket.
       then they are all got stuck by waiting for each other.
    
    Hua Rui provided a patch for me, by allocating some buckets of
    RESERVE_BTREE type in advance, so the register thread can get bucket
    when btree node splitting and no need to waiting for the allocator
    thread. I tested it, it has effect, and register thread run a step
    forward, but finally are still got stuck, the reason is only 8 bucket
    of RESERVE_BTREE type were allocated, and in bch_journal_replay(),
    after 2 btree nodes splitting, only 4 bucket of RESERVE_BTREE type left,
    then btree_check_reserve() is not satisfied anymore, so it goes to sleep
    again, and in the same time, alloctor thread did not flush enough btree
    nodes to release a journal bucket, so they all got stuck again.
    
    So we need to allocate more buckets of RESERVE_BTREE type in advance,
    but how much is enough?  By experience and test, I think it should be
    as much as journal buckets. Then I modify the code as this patch,
    and test in the machine, and it works.
    
    This patch modified base on Hua Rui’s patch, and allocate more buckets
    of RESERVE_BTREE type in advance to avoid register thread and allocate
    thread going to wait for each other.
    
    [patch v2] ca->sb.njournal_buckets would be 0 in the first time after
    cache creation, and no journal exists, so just 8 btree buckets is OK.
    
    Signed-off-by: Hua Rui <huarui.dev@gmail.com>
    Signed-off-by: Tang Junhui <tang.junhui@zte.com.cn>
    Reviewed-by: Michael Lyle <mlyle@lyle.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f89edd17aff46a3970f302add6949700198dfd92
Author: Coly Li <colyli@suse.de>
Date:   Wed Feb 7 11:41:41 2018 -0800

    bcache: properly set task state in bch_writeback_thread()
    
    
    [ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ]
    
    Kernel thread routine bch_writeback_thread() has the following code block,
    
    447         down_write(&dc->writeback_lock);
    448~450     if (check conditions) {
    451                 up_write(&dc->writeback_lock);
    452                 set_current_state(TASK_INTERRUPTIBLE);
    453
    454                 if (kthread_should_stop())
    455                         return 0;
    456
    457                 schedule();
    458                 continue;
    459         }
    
    If condition check is true, its task state is set to TASK_INTERRUPTIBLE
    and call schedule() to wait for others to wake up it.
    
    There are 2 issues in current code,
    1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if
       another process changes the condition and call wake_up_process(dc->
       writeback_thread), then at line 452 task state is set back to
       TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be
       waken up.
    2, At line 454 if kthread_should_stop() is true, writeback kernel thread
       will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and
       call do_exit(). It is not good to enter do_exit() with task state
       TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a
       warning message is reported by __might_sleep(): "WARNING: do not call
       blocking ops when !TASK_RUNNING; state=1 set at [xxxx]".
    
    For the first issue, task state should be set before condition checks.
    Ineed because dc->writeback_lock is required when modifying all the
    conditions, calling set_current_state() inside code block where dc->
    writeback_lock is hold is safe. But this is quite implicit, so I still move
    set_current_state() before all the condition checks.
    
    For the second issue, frankley speaking it does not hurt when kernel thread
    exits with TASK_INTERRUPTIBLE state, but this warning message scares users,
    makes them feel there might be something risky with bcache and hurt their
    data.  Setting task state to TASK_RUNNING before returning fixes this
    problem.
    
    In alloc.c:allocator_wait(), there is also a similar issue, and is also
    fixed in this patch.
    
    Changelog:
    v3: merge two similar fixes into one patch
    v2: fix the race issue in v1 patch.
    v1: initial buggy fix.
    
    Signed-off-by: Coly Li <colyli@suse.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Michael Lyle <mlyle@lyle.org>
    Cc: Michael Lyle <mlyle@lyle.org>
    Cc: Junhui Tang <tang.junhui@zte.com.cn>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05921c492fdb6046e5a91a83dba3320701421902
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 2 16:48:47 2018 +0100

    cifs: silence compiler warnings showing up with gcc-8.0.0
    
    
    [ Upstream commit ade7db991b47ab3016a414468164f4966bd08202 ]
    
    This bug was fixed before, but came up again with the latest
    compiler in another function:
    
    fs/cifs/cifssmb.c: In function 'CIFSSMBSetEA':
    fs/cifs/cifssmb.c:6362:3: error: 'strncpy' offset 8 is out of the bounds [0, 4] [-Werror=array-bounds]
       strncpy(parm_data->list[0].name, ea_name, name_len);
    
    Let's apply the same fix that was used for the other instances.
    
    Fixes: b2a3ad9ca502 ("cifs: silence compiler warnings showing up with gcc-4.7.0")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b95781cb6f37398e424e70e089e380f297693f5
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Jan 23 21:43:08 2018 +0100

    PM / domains: Fix up domain-idle-states OF parsing
    
    
    [ Upstream commit a3381e3a65cbaf612c8f584906c4dba27e84267c ]
    
    Commit b539cc82d493 (PM / Domains: Ignore domain-idle-states that are
    not compatible), made it possible to ignore non-compatible
    domain-idle-states OF nodes. However, in case that happens while doing
    the OF parsing, the number of elements in the allocated array would
    exceed the numbers actually needed, thus wasting memory.
    
    Fix this by pre-iterating the genpd OF node and counting the number of
    compatible domain-idle-states nodes, before doing the allocation. While
    doing this, it makes sense to rework the code a bit to avoid open coding,
    of parts responsible for the OF node iteration.
    
    Let's also take the opportunity to clarify the function header for
    of_genpd_parse_idle_states(), about what is being returned in case of
    errors.
    
    Fixes: b539cc82d493 (PM / Domains: Ignore domain-idle-states that are not compatible)
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Lina Iyer <ilina@codeaurora.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05e52e5bd103a335288415d5399cdb120a05a5e4
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Tue Feb 6 15:36:59 2018 -0800

    proc: fix /proc/*/map_files lookup
    
    
    [ Upstream commit ac7f1061c2c11bb8936b1b6a94cdb48de732f7a4 ]
    
    Current code does:
    
            if (sscanf(dentry->d_name.name, "%lx-%lx", start, end) != 2)
    
    However sscanf() is broken garbage.
    
    It silently accepts whitespace between format specifiers
    (did you know that?).
    
    It silently accepts valid strings which result in integer overflow.
    
    Do not use sscanf() for any even remotely reliable parsing code.
    
            OK
            # readlink '/proc/1/map_files/55a23af39000-55a23b05b000'
            /lib/systemd/systemd
    
            broken
            # readlink '/proc/1/map_files/               55a23af39000-55a23b05b000'
            /lib/systemd/systemd
    
            broken
            # readlink '/proc/1/map_files/55a23af39000-55a23b05b000    '
            /lib/systemd/systemd
    
            very broken
            # readlink '/proc/1/map_files/1000000000000000055a23af39000-55a23b05b000'
            /lib/systemd/systemd
    
    Andrei said:
    
    : This patch breaks criu.  It was a bug in criu.  And this bug is on a minor
    : path, which works when memfd_create() isn't available.  It is a reason why
    : I ask to not backport this patch to stable kernels.
    :
    : In CRIU this bug can be triggered, only if this patch will be backported
    : to a kernel which version is lower than v3.16.
    
    Link: http://lkml.kernel.org/r/20171120212706.GA14325@avx2
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Pavel Emelyanov <xemul@openvz.org>
    Cc: Andrei Vagin <avagin@virtuozzo.com>
    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 4ec317a41d80145de90bd320928da6916572b6f0
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Jan 31 12:12:20 2018 +0000

    arm64: spinlock: Fix theoretical trylock() A-B-A with LSE atomics
    
    
    [ Upstream commit 202fb4ef81e3ec765c23bd1e6746a5c25b797d0e ]
    
    If the spinlock "next" ticket wraps around between the initial LDR
    and the cmpxchg in the LSE version of spin_trylock, then we can erroneously
    think that we have successfuly acquired the lock because we only check
    whether the next ticket return by the cmpxchg is equal to the owner ticket
    in our updated lock word.
    
    This patch fixes the issue by performing a full 32-bit check of the lock
    word when trying to determine whether or not the CASA instruction updated
    memory.
    
    Reported-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 693b9589c297e0b05359f62a6b8dc73289c0e3e4
Author: Guanglei Li <guanglei.li@oracle.com>
Date:   Tue Feb 6 10:43:21 2018 +0800

    RDS: IB: Fix null pointer issue
    
    
    [ Upstream commit 2c0aa08631b86a4678dbc93b9caa5248014b4458 ]
    
    Scenario:
    1. Port down and do fail over
    2. Ap do rds_bind syscall
    
    PID: 47039  TASK: ffff89887e2fe640  CPU: 47  COMMAND: "kworker/u:6"
     #0 [ffff898e35f159f0] machine_kexec at ffffffff8103abf9
     #1 [ffff898e35f15a60] crash_kexec at ffffffff810b96e3
     #2 [ffff898e35f15b30] oops_end at ffffffff8150f518
     #3 [ffff898e35f15b60] no_context at ffffffff8104854c
     #4 [ffff898e35f15ba0] __bad_area_nosemaphore at ffffffff81048675
     #5 [ffff898e35f15bf0] bad_area_nosemaphore at ffffffff810487d3
     #6 [ffff898e35f15c00] do_page_fault at ffffffff815120b8
     #7 [ffff898e35f15d10] page_fault at ffffffff8150ea95
        [exception RIP: unknown or invalid address]
        RIP: 0000000000000000  RSP: ffff898e35f15dc8  RFLAGS: 00010282
        RAX: 00000000fffffffe  RBX: ffff889b77f6fc00  RCX:ffffffff81c99d88
        RDX: 0000000000000000  RSI: ffff896019ee08e8  RDI:ffff889b77f6fc00
        RBP: ffff898e35f15df0   R8: ffff896019ee08c8  R9:0000000000000000
        R10: 0000000000000400  R11: 0000000000000000  R12:ffff896019ee08c0
        R13: ffff889b77f6fe68  R14: ffffffff81c99d80  R15: ffffffffa022a1e0
        ORIG_RAX: ffffffffffffffff  CS: 0010 SS: 0018
     #8 [ffff898e35f15dc8] cma_ndev_work_handler at ffffffffa022a228 [rdma_cm]
     #9 [ffff898e35f15df8] process_one_work at ffffffff8108a7c6
     #10 [ffff898e35f15e58] worker_thread at ffffffff8108bda0
     #11 [ffff898e35f15ee8] kthread at ffffffff81090fe6
    
    PID: 45659  TASK: ffff880d313d2500  CPU: 31  COMMAND: "oracle_45659_ap"
     #0 [ffff881024ccfc98] __schedule at ffffffff8150bac4
     #1 [ffff881024ccfd40] schedule at ffffffff8150c2cf
     #2 [ffff881024ccfd50] __mutex_lock_slowpath at ffffffff8150cee7
     #3 [ffff881024ccfdc0] mutex_lock at ffffffff8150cdeb
     #4 [ffff881024ccfde0] rdma_destroy_id at ffffffffa022a027 [rdma_cm]
     #5 [ffff881024ccfe10] rds_ib_laddr_check at ffffffffa0357857 [rds_rdma]
     #6 [ffff881024ccfe50] rds_trans_get_preferred at ffffffffa0324c2a [rds]
     #7 [ffff881024ccfe80] rds_bind at ffffffffa031d690 [rds]
     #8 [ffff881024ccfeb0] sys_bind at ffffffff8142a670
    
    PID: 45659                          PID: 47039
    rds_ib_laddr_check
      /* create id_priv with a null event_handler */
      rdma_create_id
      rdma_bind_addr
        cma_acquire_dev
          /* add id_priv to cma_dev->id_list */
          cma_attach_to_dev
                                        cma_ndev_work_handler
                                          /* event_hanlder is null */
                                          id_priv->id.event_handler
    
    Signed-off-by: Guanglei Li <guanglei.li@oracle.com>
    Signed-off-by: Honglei Wang <honglei.wang@oracle.com>
    Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Yanjun Zhu <yanjun.zhu@oracle.com>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Acked-by: Doug Ledford <dledford@redhat.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 a8e7a4e243747fdf64a459e0eb2e5091ffee9fe1
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Mon Feb 5 10:17:54 2018 -0800

    bpf: sockmap, fix leaking maps with attached but not detached progs
    
    
    [ Upstream commit 3d9e952697de89b53227f06d4241f275eb99cfc4 ]
    
    When a program is attached to a map we increment the program refcnt
    to ensure that the program is not removed while it is potentially
    being referenced from sockmap side. However, if this same program
    also references the map (this is a reasonably common pattern in
    my programs) then the verifier will also increment the maps refcnt
    from the verifier. This is to ensure the map doesn't get garbage
    collected while the program has a reference to it.
    
    So we are left in a state where the map holds the refcnt on the
    program stopping it from being removed and releasing the map refcnt.
    And vice versa the program holds a refcnt on the map stopping it
    from releasing the refcnt on the prog.
    
    All this is fine as long as users detach the program while the
    map fd is still around. But, if the user omits this detach command
    we are left with a dangling map we can no longer release.
    
    To resolve this when the map fd is released decrement the program
    references and remove any reference from the map to the program.
    This fixes the issue with possibly dangling map and creates a
    user side API constraint. That is, the map fd must be held open
    for programs to be attached to a map.
    
    Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05c062c3685e227a22c96c93e1149fcad383ecbf
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Thu Jan 11 09:36:37 2018 +0000

    xen/grant-table: Use put_page instead of free_page
    
    
    [ Upstream commit 3ac7292a25db1c607a50752055a18aba32ac2176 ]
    
    The page given to gnttab_end_foreign_access() to free could be a
    compound page so use put_page() instead of free_page() since it can
    handle both compound and single pages correctly.
    
    This bug was discovered when migrating a Xen VM with several VIFs and
    CONFIG_DEBUG_VM enabled. It hits a BUG usually after fewer than 10
    iterations. All netfront devices disconnect from the backend during a
    suspend/resume and this will call gnttab_end_foreign_access() if a
    netfront queue has an outstanding skb. The mismatch between calling
    get_page() and free_page() on a compound page causes a reference
    counting error which is detected when DEBUG_VM is enabled.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70f3461c23ffb394676cb53c2eb1095208a52327
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Thu Jan 11 09:36:38 2018 +0000

    xen-netfront: Fix race between device setup and open
    
    
    [ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]
    
    When a netfront device is set up it registers a netdev fairly early on,
    before it has set up the queues and is actually usable. A userspace tool
    like NetworkManager will immediately try to open it and access its state
    as soon as it appears. The bug can be reproduced by hotplugging VIFs
    until the VM runs out of grant refs. It registers the netdev but fails
    to set up any queues (since there are no more grant refs). In the
    meantime, NetworkManager opens the device and the kernel crashes trying
    to access the queues (of which there are none).
    
    Fix this in two ways:
    * For initial setup, register the netdev much later, after the queues
    are setup. This avoids the race entirely.
    * During a suspend/resume cycle, the frontend reconnects to the backend
    and the queues are recreated. It is possible (though highly unlikely) to
    race with something opening the device and accessing the queues after
    they have been destroyed but before they have been recreated. Extend the
    region covered by the rtnl semaphore to protect against this race. There
    is a possibility that we fail to recreate the queues so check for this
    in the open function.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f79b5e52d46db124ad04c994ce0c2d43244de85
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu Feb 1 09:38:10 2018 +0100

    perf evsel: Fix period/freq terms setup
    
    
    [ Upstream commit 49c0ae80eb32426fa133246200628e529067c595 ]
    
    Stephane reported that we don't set properly PERIOD sample type for
    events with period term defined.
    
    Before:
      $ perf record -e cpu/cpu-cycles,period=1000/u ls
      $ perf evlist -v
      cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME|PERIOD, ...
    
    After:
      $ perf record -e cpu/cpu-cycles,period=1000/u ls
      $ perf evlist -v
      cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME, ...
    
    Setting PERIOD sample type based on period term setup.
    
    Committer note:
    
    When we use -c or a period=N term in the event definition, then we don't
    need to ask the kernel, for this event, via perf_event_attr.sample_type
    |= PERF_SAMPLE_PERIOD, to put the event period in each sample for this
    event, as we know it already, it is in perf_event_attr.sample_period.
    
    Reported-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Stephane Eranian <eranian@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20180201083812.11359-2-jolsa@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 b1f9f9fb3f99d8942991aa5976de73fd865937ec
Author: Matt Redfearn <matt.redfearn@mips.com>
Date:   Fri Jan 5 10:31:07 2018 +0000

    MIPS: Generic: Support GIC in EIC mode
    
    
    [ Upstream commit 7bf8b16d1b60419c865e423b907a05f413745b3e ]
    
    The GIC supports running in External Interrupt Controller (EIC) mode,
    and will signal this via cpu_has_veic if enabled in hardware. Currently
    the generic kernel will panic if cpu_has_veic is set - but the GIC can
    legitimately set this flag if either configured to boot in EIC mode, or
    if the GIC driver enables this mode. Make the kernel not panic in this
    case, and instead just check if the GIC is present. If so, use it's CPU
    local interrupt routing functions. If an EIC is present, but it is not
    the GIC, then the kernel does not know how to get the VIRQ for the CPU
    local interrupts and should panic. Support for alternative EICs being
    present is needed here for the generic kernel to support them.
    
    Suggested-by: Paul Burton <paul.burton@mips.com>
    Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/18191/
    Signed-off-by: James Hogan <jhogan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76e3ea2f95632d23aa12e954940c69e32544330b
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu Feb 1 09:38:11 2018 +0100

    perf record: Fix period option handling
    
    
    [ Upstream commit f290aa1ffa45ed7e37599840878b4dae68269ee1 ]
    
    Stephan reported we don't unset PERIOD sample type when --no-period is
    specified. Adding the unset check and reset PERIOD if --no-period is
    specified.
    
    Committer notes:
    
    Check the sample_type, it shouldn't have PERF_SAMPLE_PERIOD there when
    --no-period is used.
    
    Before:
    
      # perf record --no-period sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.018 MB perf.data (7 samples) ]
      # perf evlist -v
      cycles:ppp: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1
      #
    
    After:
    
    [root@jouet ~]# perf record --no-period sleep 1
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.019 MB perf.data (17 samples) ]
    [root@jouet ~]# perf evlist -v
    cycles:ppp: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1
    [root@jouet ~]#
    
    Reported-by: Stephane Eranian <eranian@google.com>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Stephane Eranian <eranian@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20180201083812.11359-3-jolsa@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 f938c2acc829689a29f3b1b2aa123285c31b2c67
Author: Matt Redfearn <matt.redfearn@mips.com>
Date:   Mon Jan 29 11:26:45 2018 +0000

    MIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASS
    
    
    [ Upstream commit 0cde5b44a30f1daaef1c34e08191239dc63271c4 ]
    
    When commit b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
    added board support for the RBTX4939, it added a call to
    led_classdev_register even if the LED class is built as a module.
    Built-in arch code cannot call module code directly like this. Commit
    b33b44073734 ("MIPS: TXX9: use IS_ENABLED() macro") subsequently
    changed the inclusion of this code to a single check that
    CONFIG_LEDS_CLASS is either builtin or a module, but the same issue
    remains.
    
    This leads to MIPS allmodconfig builds failing when CONFIG_MACH_TX49XX=y
    is set:
    
    arch/mips/txx9/rbtx4939/setup.o: In function `rbtx4939_led_probe':
    setup.c:(.init.text+0xc0): undefined reference to `of_led_classdev_register'
    make: *** [Makefile:999: vmlinux] Error 1
    
    Fix this by using the IS_BUILTIN() macro instead.
    
    Fixes: b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
    Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
    Reviewed-by: James Hogan <jhogan@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/18544/
    Signed-off-by: James Hogan <jhogan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e01c16d87511071679d3d3d14c0f8d37b856b52
Author: Yonghong Song <yhs@fb.com>
Date:   Fri Feb 2 22:37:15 2018 -0800

    bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y
    
    
    [ Upstream commit 09584b406742413ac4c8d7e030374d4daa045b69 ]
    
    With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file,
    tools/testing/selftests/bpf/test_kmod.sh failed like below:
      [root@localhost bpf]# ./test_kmod.sh
      sysctl: setting key "net.core.bpf_jit_enable": Invalid argument
      [ JIT enabled:0 hardened:0 ]
      [  132.175681] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
      [  132.458834] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
      [ JIT enabled:1 hardened:0 ]
      [  133.456025] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
      [  133.730935] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
      [ JIT enabled:1 hardened:1 ]
      [  134.769730] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
      [  135.050864] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
      [ JIT enabled:1 hardened:2 ]
      [  136.442882] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
      [  136.821810] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
      [root@localhost bpf]#
    
    The test_kmod.sh load/remove test_bpf.ko multiple times with different
    settings for sysctl net.core.bpf_jit_{enable,harden}. The failed test #297
    of test_bpf.ko is designed such that JIT always fails.
    
    Commit 290af86629b2 (bpf: introduce BPF_JIT_ALWAYS_ON config)
    introduced the following tightening logic:
        ...
            if (!bpf_prog_is_dev_bound(fp->aux)) {
                    fp = bpf_int_jit_compile(fp);
        #ifdef CONFIG_BPF_JIT_ALWAYS_ON
                    if (!fp->jited) {
                            *err = -ENOTSUPP;
                            return fp;
                    }
        #endif
        ...
    With this logic, Test #297 always gets return value -ENOTSUPP
    when CONFIG_BPF_JIT_ALWAYS_ON is defined, causing the test failure.
    
    This patch fixed the failure by marking Test #297 as expected failure
    when CONFIG_BPF_JIT_ALWAYS_ON is defined.
    
    Fixes: 290af86629b2 (bpf: introduce BPF_JIT_ALWAYS_ON config)
    Signed-off-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74abca65f1e43f747ee429441792be9394667944
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Jan 26 16:02:59 2018 +0100

    ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs
    
    
    [ Upstream commit 63347db0affadcbccd5613116ea8431c70139b3e ]
    
    The acpi_get_bus_status wrapper for acpi_bus_get_status_handle has some
    code to handle certain device quirks, in some cases we also need this
    quirk handling for the initial _STA call.
    
    Specifically on some devices calling _STA before all _DEP dependencies
    are met results in errors like these:
    
    [    0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c)
                   [GenericSerialBus] (20170831/evregion-166)
    [    0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler
                   (20170831/exfldio-299)
    [    0.123618] ACPI Error: Method parse/execution failed
                   \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)
    
    acpi_get_bus_status already has code to avoid this, so by using it we
    also silence these errors from the initial _STA call.
    
    Note that in order for the acpi_get_bus_status handling for this to work,
    we initialize dep_unmet to 1 until acpi_device_dep_initialize gets called,
    this means that battery devices will be instantiated with an initial
    status of 0. This is not a problem, acpi_bus_attach will get called soon
    after the instantiation anyways and it will update the status as first
    point of order.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f920e914801c57f6853a62bba081fd6f3b11aede
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Jan 26 16:02:58 2018 +0100

    ACPI / bus: Do not call _STA on battery devices with unmet dependencies
    
    
    [ Upstream commit 54ddce7062242036402242242c07c60c0b505f84 ]
    
    The battery code uses acpi_device->dep_unmet to check for unmet deps and
    if there are unmet deps it does not bind to the device to avoid errors
    about missing OpRegions when calling ACPI methods on the device.
    
    The missing OpRegions when there are unmet deps problem also applies to
    the _STA method of some battery devices and calling it too early results
    in errors like these:
    
    [    0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c)
                   [GenericSerialBus] (20170831/evregion-166)
    [    0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler
                   (20170831/exfldio-299)
    [    0.123618] ACPI Error: Method parse/execution failed
                   \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)
    
    This commit fixes these errors happening when acpi_get_bus_status gets
    called by checking dep_unmet for battery devices and reporting a status
    of 0 until all dependencies are met.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51939996acde4bce855f70a32544aaf44f8e3f0a
Author: Chen Yu <yu.c.chen@intel.com>
Date:   Mon Jan 29 10:26:46 2018 +0800

    ACPI: processor_perflib: Do not send _PPC change notification if not ready
    
    
    [ Upstream commit ba1edb9a5125a617d612f98eead14b9b84e75c3a ]
    
    The following warning was triggered after resumed from S3 -
    if all the nonboot CPUs were put offline before suspend:
    
    [ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 0xffffffff86061e3a (native_read_msr+0xa/0x30)
    [ 1840.329516] Call Trace:
    [ 1840.329521]  __rdmsr_on_cpu+0x33/0x50
    [ 1840.329525]  generic_exec_single+0x81/0xb0
    [ 1840.329527]  smp_call_function_single+0xd2/0x100
    [ 1840.329530]  ? acpi_ds_result_pop+0xdd/0xf2
    [ 1840.329532]  ? acpi_ds_create_operand+0x215/0x23c
    [ 1840.329534]  rdmsrl_on_cpu+0x57/0x80
    [ 1840.329536]  ? cpumask_next+0x1b/0x20
    [ 1840.329538]  ? rdmsrl_on_cpu+0x57/0x80
    [ 1840.329541]  intel_pstate_update_perf_limits+0xf3/0x220
    [ 1840.329544]  ? notifier_call_chain+0x4a/0x70
    [ 1840.329546]  intel_pstate_set_policy+0x4e/0x150
    [ 1840.329548]  cpufreq_set_policy+0xcd/0x2f0
    [ 1840.329550]  cpufreq_update_policy+0xb2/0x130
    [ 1840.329552]  ? cpufreq_update_policy+0x130/0x130
    [ 1840.329556]  acpi_processor_ppc_has_changed+0x65/0x80
    [ 1840.329558]  acpi_processor_notify+0x80/0x100
    [ 1840.329561]  acpi_ev_notify_dispatch+0x44/0x5c
    [ 1840.329563]  acpi_os_execute_deferred+0x14/0x20
    [ 1840.329565]  process_one_work+0x193/0x3c0
    [ 1840.329567]  worker_thread+0x35/0x3b0
    [ 1840.329569]  kthread+0x125/0x140
    [ 1840.329571]  ? process_one_work+0x3c0/0x3c0
    [ 1840.329572]  ? kthread_park+0x60/0x60
    [ 1840.329575]  ? do_syscall_64+0x67/0x180
    [ 1840.329577]  ret_from_fork+0x25/0x30
    [ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 0x0000000000000000) at rIP: 0xffffffff86061f78 (native_write_msr+0x8/0x30)
    [ 1840.329586] Call Trace:
    [ 1840.329587]  __wrmsr_on_cpu+0x37/0x40
    [ 1840.329589]  generic_exec_single+0x81/0xb0
    [ 1840.329592]  smp_call_function_single+0xd2/0x100
    [ 1840.329594]  ? acpi_ds_create_operand+0x215/0x23c
    [ 1840.329595]  ? cpumask_next+0x1b/0x20
    [ 1840.329597]  wrmsrl_on_cpu+0x57/0x70
    [ 1840.329598]  ? rdmsrl_on_cpu+0x57/0x80
    [ 1840.329599]  ? wrmsrl_on_cpu+0x57/0x70
    [ 1840.329602]  intel_pstate_hwp_set+0xd3/0x150
    [ 1840.329604]  intel_pstate_set_policy+0x119/0x150
    [ 1840.329606]  cpufreq_set_policy+0xcd/0x2f0
    [ 1840.329607]  cpufreq_update_policy+0xb2/0x130
    [ 1840.329610]  ? cpufreq_update_policy+0x130/0x130
    [ 1840.329613]  acpi_processor_ppc_has_changed+0x65/0x80
    [ 1840.329615]  acpi_processor_notify+0x80/0x100
    [ 1840.329617]  acpi_ev_notify_dispatch+0x44/0x5c
    [ 1840.329619]  acpi_os_execute_deferred+0x14/0x20
    [ 1840.329620]  process_one_work+0x193/0x3c0
    [ 1840.329622]  worker_thread+0x35/0x3b0
    [ 1840.329624]  kthread+0x125/0x140
    [ 1840.329625]  ? process_one_work+0x3c0/0x3c0
    [ 1840.329626]  ? kthread_park+0x60/0x60
    [ 1840.329628]  ? do_syscall_64+0x67/0x180
    [ 1840.329631]  ret_from_fork+0x25/0x30
    
    This is because if there's only one online CPU, the MSR_PM_ENABLE
    (package wide)can not be enabled after resumed, due to
    intel_pstate_hwp_enable() will only be invoked on AP's online
    process after resumed - if there's no AP online, the HWP remains
    disabled after resumed (BIOS has disabled it in S3). Then if
    there comes a _PPC change notification which touches HWP register
    during this stage, the warning is triggered.
    
    Since we don't call acpi_processor_register_performance() when
    HWP is enabled, the pr->performance will be NULL. When this is
    NULL we don't need to do _PPC change notification.
    
    Reported-by: Doug Smythies <dsmythies@telus.net>
    Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Yu Chen <yu.c.chen@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 573cb560b4edd71a6b9dd41cdc39d27abb8dda30
Author: Jean Delvare <jdelvare@suse.de>
Date:   Sat Feb 3 11:25:20 2018 +0100

    firmware: dmi_scan: Fix handling of empty DMI strings
    
    
    [ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ]
    
    The handling of empty DMI strings looks quite broken to me:
    * Strings from 1 to 7 spaces are not considered empty.
    * True empty DMI strings (string index set to 0) are not considered
      empty, and result in allocating a 0-char string.
    * Strings with invalid index also result in allocating a 0-char
      string.
    * Strings starting with 8 spaces are all considered empty, even if
      non-space characters follow (sounds like a weird thing to do, but
      I have actually seen occurrences of this in DMI tables before.)
    * Strings which are considered empty are reported as 8 spaces,
      instead of being actually empty.
    
    Some of these issues are the result of an off-by-one error in memcmp,
    the rest is incorrect by design.
    
    So let's get it square: missing strings and strings made of only
    spaces, regardless of their length, should be treated as empty and
    no memory should be allocated for them. All other strings are
    non-empty and should be allocated.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
    Cc: Parag Warudkar <parag.warudkar@gmail.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee06ed9ba5182bfdbc829f150b594c7f14a9d62f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 2 15:56:17 2018 +0100

    x86/dumpstack: Avoid uninitlized variable
    
    
    [ Upstream commit ebfc15019cfa72496c674ffcb0b8ef10790dcddc ]
    
    In some configurations, 'partial' does not get initialized, as shown by
    this gcc-8 warning:
    
    arch/x86/kernel/dumpstack.c: In function 'show_trace_log_lvl':
    arch/x86/kernel/dumpstack.c:156:4: error: 'partial' may be used uninitialized in this function [-Werror=maybe-uninitialized]
        show_regs_if_on_stack(&stack_info, regs, partial);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    This initializes it to false, to get the previous behavior in this case.
    
    Fixes: a9cdbe72c4e8 ("x86/dumpstack: Fix partial register dumps")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Nicolas Pitre <nico@linaro.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Link: https://lkml.kernel.org/r/20180202145634.200291-1-arnd@arndb.de
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 423505471f5ed18ed88afe66592931f91245fce2
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 2 15:56:18 2018 +0100

    x86/power: Fix swsusp_arch_resume prototype
    
    
    [ Upstream commit 328008a72d38b5bde6491e463405c34a81a65d3e ]
    
    The declaration for swsusp_arch_resume marks it as 'asmlinkage', but the
    definition in x86-32 does not, and it fails to include the header with the
    declaration. This leads to a warning when building with
    link-time-optimizations:
    
    kernel/power/power.h:108:23: error: type of 'swsusp_arch_resume' does not match original declaration [-Werror=lto-type-mismatch]
     extern asmlinkage int swsusp_arch_resume(void);
                           ^
    arch/x86/power/hibernate_32.c:148:0: note: 'swsusp_arch_resume' was previously declared here
     int swsusp_arch_resume(void)
    
    This moves the declaration into a globally visible header file and fixes up
    both x86 definitions to match it.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Len Brown <len.brown@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Nicolas Pitre <nico@linaro.org>
    Cc: linux-pm@vger.kernel.org
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Bart Van Assche <bart.vanassche@wdc.com>
    Link: https://lkml.kernel.org/r/20180202145634.200291-2-arnd@arndb.de
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 074372c8124cbd62a8edf8b979fa814b4e223ece
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Wed Jan 31 04:50:01 2018 -0700

    netfilter: ipv6: nf_defrag: Kill frag queue on RFC2460 failure
    
    
    [ Upstream commit ea23d5e3bf340e413b8e05c13da233c99c64142b ]
    
    Failures were seen in ICMPv6 fragmentation timeout tests if they were
    run after the RFC2460 failure tests. Kernel was not sending out the
    ICMPv6 fragment reassembly time exceeded packet after the fragmentation
    reassembly timeout of 1 minute had elapsed.
    
    This happened because the frag queue was not released if an error in
    IPv6 fragmentation header was detected by RFC2460.
    
    Fixes: 83f1999caeb1 ("netfilter: ipv6: nf_defrag: Pass on packets to stack per RFC2460")
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    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 2cd5100363b794cdd26d878cbde0c12c33687e7d
Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
Date:   Tue Jan 23 13:58:05 2018 +0100

    s390/eadm: fix CONFIG_BLOCK include dependency
    
    
    [ Upstream commit 366b77ae43c5a3bf1a367f15ec8bc16e05035f14 ]
    
    Commit 2a842acab109 ("block: introduce new block status code type")
    added blk_status_t usage to the eadm subchannel driver. However
    blk_status_t is unknown when included via <linux/blkdev.h> for CONFIG_BLOCK=n.
    
    Only include <linux/blk_types.h> since this is the only dependency eadm has.
    
    This fixes build failures like below:
    In file included from drivers/s390/cio/eadm_sch.c:24:0:
    ./arch/s390/include/asm/eadm.h:111:4: error: unknown type name 'blk_status_t'; did you mean 'si_status'?
        blk_status_t error);
    
    Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb41efa1386582c00865a3dec5758cfbda6dbda8
Author: Karol Herbst <kherbst@redhat.com>
Date:   Mon Nov 6 16:32:41 2017 +0100

    drm/nouveau/pmu/fuc: don't use movw directly anymore
    
    
    [ Upstream commit fe9748b7b41cee11f8db57fb8b20bc540a33102a ]
    
    Fixes failure to compile with recent envyas as a result of the 'movw'
    alias being removed for v5.
    
    A bit of history:
    
    v3 only has a 16-bit sign-extended immediate mov op. In order to set
    the high bits, there's a separate 'sethi' op. envyas validates that
    the value passed to mov(imm) is between -0x8000 and 0x7fff. In order
    to simplify macros that load both the low and high word, a 'movw'
    alias was added which takes an unsigned 16-bit immediate. However the
    actual hardware op still sign extends.
    
    v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op
    is gone (loads 0 into the dst reg). However due to a bug in envyas,
    the movw alias still existed, and selected the no-longer-present v3
    16-bit immediate mov op. As a result usage of movw on v5 is the same
    as mov with a 0x0 argument.
    
    The proper fix throughout is to only ever use the 'movw' alias in
    combination with 'sethi'. Anything else should get the sign-extended
    validation to ensure that the intended value ends up in the
    destination register.
    
    Changes in fuc3 binaries is the result of a different encoding being
    selected for a mov with an 8-bit value.
    
    v2: added commit message written by Ilia, thanks for that!
    v3: messed up rebasing, now it should apply
    
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    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 fd370b8e65e3364a8a4411656506ccfaf13b4599
Author: Don Hiatt <don.hiatt@intel.com>
Date:   Thu Feb 1 10:57:03 2018 -0800

    IB/core: Map iWarp AH type to undefined in rdma_ah_find_type
    
    
    [ Upstream commit 87daac68f77a3e21a1113f816e6a7be0b38bdde8 ]
    
    iWarp devices do not support the creation of address handles
    so return AH_ATTR_TYPE_UNDEFINED for all iWarp devices.
    
    While we are here reduce the size of port_num to u8 and add
    a comment.
    
    Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
    Reported-by: Parav Pandit <parav@mellanox.com>
    CC: Sean Hefty <sean.hefty@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Don Hiatt <don.hiatt@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.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 f63bb02694f08e94a50ae334d16b9908426655f7
Author: Alex Estrin <alex.estrin@intel.com>
Date:   Thu Feb 1 10:55:41 2018 -0800

    IB/ipoib: Fix for potential no-carrier state
    
    
    [ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]
    
    On reboot SM can program port pkey table before ipoib registered its
    event handler, which could result in missing pkey event and leave root
    interface with initial pkey value from index 0.
    
    Since OPA port starts with invalid pkey in index 0, root interface will
    fail to initialize and stay down with no-carrier flag.
    
    For IB ipoib interface may end up with pkey different from value
    opensm put in pkey table idx 0, resulting in connectivity issues
    (different mcast groups, for example).
    
    Close the window by calling event handler after registration
    to make sure ipoib pkey is in sync with port pkey table.
    
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Alex Estrin <alex.estrin@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.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 8f96d408a9547e2a814562796c6f7fac3e839332
Author: Alex Estrin <alex.estrin@intel.com>
Date:   Thu Feb 1 10:43:58 2018 -0800

    IB/hfi1: Fix for potential refcount leak in hfi1_open_file()
    
    
    [ Upstream commit 2b1e7fe16124e86ee9242aeeee859c79a843e3a2 ]
    
    The dd refcount is speculatively incremented prior to allocating
    the fd memory with kzalloc(). If that kzalloc() failed the dd
    refcount leaks.
    Increment refcount on kzalloc success.
    
    Fixes: e11ffbd57520 ("IB/hfi1: Do not free hfi1 cdev parent structure early")
    Reviewed-by: Michael J Ruhl <michael.j.ruhl@intel.com>
    Signed-off-by: Alex Estrin <alex.estrin@intel.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 5ceae7690f0d0575c730663ffd67493c9fa4e992
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>
Date:   Thu Feb 1 10:43:42 2018 -0800

    IB/hfi1: Re-order IRQ cleanup to address driver cleanup race
    
    
    [ Upstream commit 82a979265638c505e12fbe7ba40980dc0901436d ]
    
    The pci_request_irq() interfaces always adds the IRQF_SHARED bit to
    all IRQ requests.
    
    When the kernel is built with CONFIG_DEBUG_SHIRQ config flag, if the
    IRQF_SHARED bit is set, a call to the IRQ handler is made from the
    __free_irq() function. This is testing a race condition between the
    IRQ cleanup and an IRQ racing the cleanup.  The HFI driver should be
    able to handle this race, but does not.
    
    This race can cause traces that start with this footprint:
    
    BUG: unable to handle kernel NULL pointer dereference at   (null)
    Call Trace:
     <hfi1 irq handler>
     ...
     __free_irq+0x1b3/0x2d0
     free_irq+0x35/0x70
     pci_free_irq+0x1c/0x30
     clean_up_interrupts+0x53/0xf0 [hfi1]
     hfi1_start_cleanup+0x122/0x190 [hfi1]
     postinit_cleanup+0x1d/0x280 [hfi1]
     remove_one+0x233/0x250 [hfi1]
     pci_device_remove+0x39/0xc0
    
    Export IRQ cleanup function so it can be called from other modules.
    
    Using the exported cleanup function:
    
      Re-order the driver cleanup code to clean up IRQ resources before
      other resources, eliminating the race.
    
      Re-order error path for init so that the race does not occur.
    
    Reduce severity on spurious error message for SDMA IRQs to info.
    
    Reviewed-by: Alex Estrin <alex.estrin@intel.com>
    Reviewed-by: Patel Jay P <jay.p.patel@intel.com>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.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 73027d80d67e151787603e65bf62bdbc4125877c
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Feb 1 14:01:02 2018 -0700

    blk-mq: fix discard merge with scheduler attached
    
    
    [ Upstream commit 445251d0f4d329aa061f323546cd6388a3bb7ab5 ]
    
    I ran into an issue on my laptop that triggered a bug on the
    discard path:
    
    WARNING: CPU: 2 PID: 207 at drivers/nvme/host/core.c:527 nvme_setup_cmd+0x3d3/0x430
     Modules linked in: rfcomm fuse ctr ccm bnep arc4 binfmt_misc snd_hda_codec_hdmi nls_iso8859_1 nls_cp437 vfat snd_hda_codec_conexant fat snd_hda_codec_generic iwlmvm snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq x86_pkg_temp_thermal intel_powerclamp kvm_intel uvcvideo iwlwifi btusb snd_seq_device videobuf2_vmalloc btintel videobuf2_memops kvm snd_timer videobuf2_v4l2 bluetooth irqbypass videobuf2_core aesni_intel aes_x86_64 crypto_simd cryptd snd glue_helper videodev cfg80211 ecdh_generic soundcore hid_generic usbhid hid i915 psmouse e1000e ptp pps_core xhci_pci xhci_hcd intel_gtt
     CPU: 2 PID: 207 Comm: jbd2/nvme0n1p7- Tainted: G     U           4.15.0+ #176
     Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET59W (1.33 ) 12/19/2017
     RIP: 0010:nvme_setup_cmd+0x3d3/0x430
     RSP: 0018:ffff880423e9f838 EFLAGS: 00010217
     RAX: 0000000000000000 RBX: ffff880423e9f8c8 RCX: 0000000000010000
     RDX: ffff88022b200010 RSI: 0000000000000002 RDI: 00000000327f0000
     RBP: ffff880421251400 R08: ffff88022b200000 R09: 0000000000000009
     R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000ffff
     R13: ffff88042341e280 R14: 000000000000ffff R15: ffff880421251440
     FS:  0000000000000000(0000) GS:ffff880441500000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 000055b684795030 CR3: 0000000002e09006 CR4: 00000000001606e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     Call Trace:
      nvme_queue_rq+0x40/0xa00
      ? __sbitmap_queue_get+0x24/0x90
      ? blk_mq_get_tag+0xa3/0x250
      ? wait_woken+0x80/0x80
      ? blk_mq_get_driver_tag+0x97/0xf0
      blk_mq_dispatch_rq_list+0x7b/0x4a0
      ? deadline_remove_request+0x49/0xb0
      blk_mq_do_dispatch_sched+0x4f/0xc0
      blk_mq_sched_dispatch_requests+0x106/0x170
      __blk_mq_run_hw_queue+0x53/0xa0
      __blk_mq_delay_run_hw_queue+0x83/0xa0
      blk_mq_run_hw_queue+0x6c/0xd0
      blk_mq_sched_insert_request+0x96/0x140
      __blk_mq_try_issue_directly+0x3d/0x190
      blk_mq_try_issue_directly+0x30/0x70
      blk_mq_make_request+0x1a4/0x6a0
      generic_make_request+0xfd/0x2f0
      ? submit_bio+0x5c/0x110
      submit_bio+0x5c/0x110
      ? __blkdev_issue_discard+0x152/0x200
      submit_bio_wait+0x43/0x60
      ext4_process_freed_data+0x1cd/0x440
      ? account_page_dirtied+0xe2/0x1a0
      ext4_journal_commit_callback+0x4a/0xc0
      jbd2_journal_commit_transaction+0x17e2/0x19e0
      ? kjournald2+0xb0/0x250
      kjournald2+0xb0/0x250
      ? wait_woken+0x80/0x80
      ? commit_timeout+0x10/0x10
      kthread+0x111/0x130
      ? kthread_create_worker_on_cpu+0x50/0x50
      ? do_group_exit+0x3a/0xa0
      ret_from_fork+0x1f/0x30
     Code: 73 89 c1 83 ce 10 c1 e1 10 09 ca 83 f8 04 0f 87 0f ff ff ff 8b 4d 20 48 8b 7d 00 c1 e9 09 48 01 8c c7 00 08 00 00 e9 f8 fe ff ff <0f> ff 4c 89 c7 41 bc 0a 00 00 00 e8 0d 78 d6 ff e9 a1 fc ff ff
     ---[ end trace 50d361cc444506c8 ]---
     print_req_error: I/O error, dev nvme0n1, sector 847167488
    
    Decoding the assembly, the request claims to have 0xffff segments,
    while nvme counts two. This turns out to be because we don't check
    for a data carrying request on the mq scheduler path, and since
    blk_phys_contig_segment() returns true for a non-data request,
    we decrement the initial segment count of 0 and end up with
    0xffff in the unsigned short.
    
    There are a few issues here:
    
    1) We should initialize the segment count for a discard to 1.
    2) The discard merging is currently using the data limits for
       segments and sectors.
    
    Fix this up by having attempt_merge() correctly identify the
    request, and by initializing the segment count correctly
    for discards.
    
    This can only be triggered with mq-deadline on discard capable
    devices right now, which isn't a common configuration.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6eddea4ba5ccd00875d6f07ea042f16335a854ba
Author: Ed Swierk <eswierk@skyportsystems.com>
Date:   Wed Jan 31 18:48:02 2018 -0800

    openvswitch: Remove padding from packet before L3+ conntrack processing
    
    
    [ Upstream commit 9382fe71c0058465e942a633869629929102843d ]
    
    IPv4 and IPv6 packets may arrive with lower-layer padding that is not
    included in the L3 length. For example, a short IPv4 packet may have
    up to 6 bytes of padding following the IP payload when received on an
    Ethernet device with a minimum packet length of 64 bytes.
    
    Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(),
    and help() in nf_conntrack_ftp) assume skb->len reflects the length of
    the L3 header and payload, rather than referring back to
    ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by
    lower-layer padding.
    
    In the normal IPv4 receive path, ip_rcv() trims the packet to
    ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive
    path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly
    in the br_netfilter receive path, br_validate_ipv4() and
    br_validate_ipv6() trim the packet to the L3 length before invoking
    netfilter hooks.
    
    Currently in the OVS conntrack receive path, ovs_ct_execute() pulls
    the skb to the L3 header but does not trim it to the L3 length before
    calling nf_conntrack_in(NF_INET_PRE_ROUTING). When
    nf_conntrack_proto_tcp encounters a packet with lower-layer padding,
    nf_ip_checksum() fails causing a "nf_ct_tcp: bad TCP checksum" log
    message. While extra zero bytes don't affect the checksum, the length
    in the IP pseudoheader does. That length is based on skb->len, and
    without trimming, it doesn't match the length the sender used when
    computing the checksum.
    
    In ovs_ct_execute(), trim the skb to the L3 length before higher-layer
    processing.
    
    Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
    Acked-by: Pravin B Shelar <pshelar@ovn.org>
    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 3b1d9626fc58c133ae434368495a3b33c1b18ccd
Author: shidao.ytt <shidao.ytt@alibaba-inc.com>
Date:   Wed Jan 31 16:19:55 2018 -0800

    mm/fadvise: discard partial page if endbyte is also EOF
    
    
    [ Upstream commit a7ab400d6fe73d0119fdc234e9982a6f80faea9f ]
    
    During our recent testing with fadvise(FADV_DONTNEED), we find that if
    given offset/length is not page-aligned, the last page will not be
    discarded.  The tool we use is vmtouch (https://hoytech.com/vmtouch/),
    we map a 10KB-sized file into memory and then try to run this tool to
    evict the whole file mapping, but the last single page always remains
    staying in the memory:
    
    $./vmtouch -e test_10K
               Files: 1
         Directories: 0
       Evicted Pages: 3 (12K)
             Elapsed: 2.1e-05 seconds
    
    $./vmtouch test_10K
               Files: 1
         Directories: 0
      Resident Pages: 1/3  4K/12K  33.3%
             Elapsed: 5.5e-05 seconds
    
    However when we test with an older kernel, say 3.10, this problem is
    gone.  So we wonder if this is a regression:
    
    $./vmtouch -e test_10K
               Files: 1
         Directories: 0
       Evicted Pages: 3 (12K)
             Elapsed: 8.2e-05 seconds
    
    $./vmtouch test_10K
               Files: 1
         Directories: 0
      Resident Pages: 0/3  0/12K  0%  <-- partial page also discarded
             Elapsed: 5e-05 seconds
    
    After digging a little bit into this problem, we find it seems not a
    regression.  Not discarding partial page is likely to be on purpose
    according to commit 441c228f817f ("mm: fadvise: document the
    fadvise(FADV_DONTNEED) behaviour for partial pages") written by Mel
    Gorman.  He explained why partial pages should be preserved instead of
    being discarded when using fadvise(FADV_DONTNEED).
    
    However, the interesting part is that the actual code did NOT work as
    the same as it was described, the partial page was still discarded
    anyway, due to a calculation mistake of `end_index' passed to
    invalidate_mapping_pages().  This mistake has not been fixed until
    recently, that's why we fail to reproduce our problem in old kernels.
    The fix is done in commit 18aba41cbf ("mm/fadvise.c: do not discard
    partial pages with POSIX_FADV_DONTNEED") by Oleg Drokin.
    
    Back to the original testing, our problem becomes that there is a
    special case that, if the page-unaligned `endbyte' is also the end of
    file, it is not necessary at all to preserve the last partial page, as
    we all know no one else will use the rest of it.  It should be safe
    enough if we just discard the whole page.  So we add an EOF check in
    this patch.
    
    We also find a poosbile real world issue in mainline kernel.  Assume
    such scenario: A userspace backup application want to backup a huge
    amount of small files (<4k) at once, the developer might (I guess) want
    to use fadvise(FADV_DONTNEED) to save memory.  However, FADV_DONTNEED
    won't really happen since the only page mapped is a partial page, and
    kernel will preserve it.  Our patch also fixes this problem, since we
    know the endbyte is EOF, so we discard it.
    
    Here is a simple reproducer to reproduce and verify each scenario we
    described above:
    
      test_fadvise.c
      ==============================
      #include <sys/mman.h>
      #include <sys/stat.h>
      #include <fcntl.h>
      #include <stdlib.h>
      #include <string.h>
      #include <stdio.h>
      #include <unistd.h>
    
      int main(int argc, char **argv)
      {
            int i, fd, ret, len;
            struct stat buf;
            void *addr;
            unsigned char *vec;
            char *strbuf;
            ssize_t pagesize = getpagesize();
            ssize_t filesize;
    
            fd = open(argv[1], O_RDWR|O_CREAT, S_IRUSR|S_IWUSR);
            if (fd < 0)
                    return -1;
            filesize = strtoul(argv[2], NULL, 10);
    
            strbuf = malloc(filesize);
            memset(strbuf, 42, filesize);
            write(fd, strbuf, filesize);
            free(strbuf);
            fsync(fd);
    
            len = (filesize + pagesize - 1) / pagesize;
            printf("length of pages: %d\n", len);
    
            addr = mmap(NULL, filesize, PROT_READ, MAP_SHARED, fd, 0);
            if (addr == MAP_FAILED)
                    return -1;
    
            ret = posix_fadvise(fd, 0, filesize, POSIX_FADV_DONTNEED);
            if (ret < 0)
                    return -1;
    
            vec = malloc(len);
            ret = mincore(addr, filesize, (void *)vec);
            if (ret < 0)
                    return -1;
    
            for (i = 0; i < len; i++)
                    printf("pages[%d]: %x\n", i, vec[i] & 0x1);
    
            free(vec);
            close(fd);
    
            return 0;
      }
      ==============================
    
    Test 1: running on kernel with commit 18aba41cbf reverted:
    
      [root@caspar ~]# uname -r
      4.15.0-rc6.revert+
      [root@caspar ~]# ./test_fadvise file1 1024
      length of pages: 1
      pages[0]: 0    # <-- partial page discarded
      [root@caspar ~]# ./test_fadvise file2 8192
      length of pages: 2
      pages[0]: 0
      pages[1]: 0
      [root@caspar ~]# ./test_fadvise file3 10240
      length of pages: 3
      pages[0]: 0
      pages[1]: 0
      pages[2]: 0    # <-- partial page discarded
    
    Test 2: running on mainline kernel:
    
      [root@caspar ~]# uname -r
      4.15.0-rc6+
      [root@caspar ~]# ./test_fadvise test1 1024
      length of pages: 1
      pages[0]: 1    # <-- partial and the only page not discarded
      [root@caspar ~]# ./test_fadvise test2 8192
      length of pages: 2
      pages[0]: 0
      pages[1]: 0
      [root@caspar ~]# ./test_fadvise test3 10240
      length of pages: 3
      pages[0]: 0
      pages[1]: 0
      pages[2]: 1    # <-- partial page not discarded
    
    Test 3: running on kernel with this patch:
    
      [root@caspar ~]# uname -r
      4.15.0-rc6.patched+
      [root@caspar ~]# ./test_fadvise test1 1024
      length of pages: 1
      pages[0]: 0    # <-- partial page and EOF, discarded
      [root@caspar ~]# ./test_fadvise test2 8192
      length of pages: 2
      pages[0]: 0
      pages[1]: 0
      [root@caspar ~]# ./test_fadvise test3 10240
      length of pages: 3
      pages[0]: 0
      pages[1]: 0
      pages[2]: 0    # <-- partial page and EOF, discarded
    
    [akpm@linux-foundation.org: tweak code comment]
    Link: http://lkml.kernel.org/r/5222da9ee20e1695eaabb69f631f200d6e6b8876.1515132470.git.jinli.zjl@alibaba-inc.com
    Signed-off-by: shidao.ytt <shidao.ytt@alibaba-inc.com>
    Signed-off-by: Caspar Zhang <jinli.zjl@alibaba-inc.com>
    Reviewed-by: Oliver Yang <zhiche.yy@alibaba-inc.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    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 1f9c87e251583942991c482d99c1797f1454be2a
Author: Mel Gorman <mgorman@techsingularity.net>
Date:   Wed Jan 31 16:19:52 2018 -0800

    mm: pin address_space before dereferencing it while isolating an LRU page
    
    
    [ Upstream commit 69d763fc6d3aee787a3e8c8c35092b4f4960fa5d ]
    
    Minchan Kim asked the following question -- what locks protects
    address_space destroying when race happens between inode trauncation and
    __isolate_lru_page? Jan Kara clarified by describing the race as follows
    
    CPU1                                            CPU2
    
    truncate(inode)                                 __isolate_lru_page()
      ...
      truncate_inode_page(mapping, page);
        delete_from_page_cache(page)
          spin_lock_irqsave(&mapping->tree_lock, flags);
            __delete_from_page_cache(page, NULL)
              page_cache_tree_delete(..)
                ...                                   mapping = page_mapping(page);
                page->mapping = NULL;
                ...
          spin_unlock_irqrestore(&mapping->tree_lock, flags);
          page_cache_free_page(mapping, page)
            put_page(page)
              if (put_page_testzero(page)) -> false
    - inode now has no pages and can be freed including embedded address_space
    
                                                      if (mapping && !mapping->a_ops->migratepage)
    - we've dereferenced mapping which is potentially already free.
    
    The race is theoretically possible but unlikely.  Before the
    delete_from_page_cache, truncate_cleanup_page is called so the page is
    likely to be !PageDirty or PageWriteback which gets skipped by the only
    caller that checks the mappping in __isolate_lru_page.  Even if the race
    occurs, a substantial amount of work has to happen during a tiny window
    with no preemption but it could potentially be done using a virtual
    machine to artifically slow one CPU or halt it during the critical
    window.
    
    This patch should eliminate the race with truncation by try-locking the
    page before derefencing mapping and aborting if the lock was not
    acquired.  There was a suggestion from Huang Ying to use RCU as a
    side-effect to prevent mapping being freed.  However, I do not like the
    solution as it's an unconventional means of preserving a mapping and
    it's not a context where rcu_read_lock is obviously protecting rcu data.
    
    Link: http://lkml.kernel.org/r/20180104102512.2qos3h5vqzeisrek@techsingularity.net
    Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware again")
    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Cc: "Huang, Ying" <ying.huang@intel.com>
    Cc: Jan Kara <jack@suse.cz>
    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 8054b87fccd4fe9c67bfc164462d81b38ea56af4
Author: Yang Shi <yang.s@alibaba-inc.com>
Date:   Wed Jan 31 16:18:28 2018 -0800

    mm: thp: use down_read_trylock() in khugepaged to avoid long block
    
    
    [ Upstream commit 3b454ad35043dfbd3b5d2bb92b0991d6342afb44 ]
    
    In the current design, khugepaged needs to acquire mmap_sem before
    scanning an mm.  But in some corner cases, khugepaged may scan a process
    which is modifying its memory mapping, so khugepaged blocks in
    uninterruptible state.  But the process might hold the mmap_sem for a
    long time when modifying a huge memory space and it may trigger the
    below khugepaged hung issue:
    
      INFO: task khugepaged:270 blocked for more than 120 seconds.
      Tainted: G E 4.9.65-006.ali3000.alios7.x86_64 #1
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      khugepaged D 0 270 2 0x00000000 
      ffff883f3deae4c0 0000000000000000 ffff883f610596c0 ffff883f7d359440
      ffff883f63818000 ffffc90019adfc78 ffffffff817079a5 d67e5aa8c1860a64
      0000000000000246 ffff883f7d359440 ffffc90019adfc88 ffff883f610596c0
      Call Trace:
        schedule+0x36/0x80
        rwsem_down_read_failed+0xf0/0x150
        call_rwsem_down_read_failed+0x18/0x30
        down_read+0x20/0x40
        khugepaged+0x476/0x11d0
        kthread+0xe6/0x100
        ret_from_fork+0x25/0x30
    
    So it sounds pointless to just block khugepaged waiting for the
    semaphore so replace down_read() with down_read_trylock() to move to
    scan the next mm quickly instead of just blocking on the semaphore so
    that other processes can get more chances to install THP.  Then
    khugepaged can come back to scan the skipped mm when it has finished the
    current round full_scan.
    
    And it appears that the change can improve khugepaged efficiency a
    little bit.
    
    Below is the test result when running LTP on a 24 cores 4GB memory 2
    nodes NUMA VM:
    
                                        pristine          w/ trylock
      full_scan                         197               187
      pages_collapsed                   21                26
      thp_fault_alloc                   40818             44466
      thp_fault_fallback                18413             16679
      thp_collapse_alloc                21                150
      thp_collapse_alloc_failed         14                16
      thp_file_alloc                    369               369
    
    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: tweak comment]
    [arnd@arndb.de: avoid uninitialized variable use]
      Link: http://lkml.kernel.org/r/20171215125129.2948634-1-arnd@arndb.de
    Link: http://lkml.kernel.org/r/1513281203-54878-1-git-send-email-yang.s@alibaba-inc.com
    Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    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 6acb8818eff43638b691acadb048bce32d0c89a3
Author: Nitin Gupta <nitin.m.gupta@oracle.com>
Date:   Wed Jan 31 16:18:09 2018 -0800

    sparc64: update pmdp_invalidate() to return old pmd value
    
    
    [ Upstream commit a8e654f01cb725d0bfd741ebca1bf4c9337969cc ]
    
    It's required to avoid losing dirty and accessed bits.
    
    [akpm@linux-foundation.org: add a `do' to the do-while loop]
    Link: http://lkml.kernel.org/r/20171213105756.69879-9-kirill.shutemov@linux.intel.com
    Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: David Miller <davem@davemloft.net>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Michal Hocko <mhocko@kernel.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 78185a93d42ddb9595df13b3394312d07a34e832
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Wed Jan 31 16:17:43 2018 -0800

    asm-generic: provide generic_pmdp_establish()
    
    
    [ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]
    
    Patch series "Do not lose dirty bit on THP pages", v4.
    
    Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
    dirty and access bits if CPU sets them after pmdp dereference, but
    before set_pmd_at().
    
    The bug can lead to data loss, but the race window is tiny and I haven't
    seen any reports that suggested that it happens in reality.  So I don't
    think it worth sending it to stable.
    
    Unfortunately, there's no way to address the issue in a generic way.  We
    need to fix all architectures that support THP one-by-one.
    
    All architectures that have THP supported have to provide atomic
    pmdp_invalidate() that returns previous value.
    
    If generic implementation of pmdp_invalidate() is used, architecture
    needs to provide atomic pmdp_estabish().
    
    pmdp_estabish() is not used out-side generic implementation of
    pmdp_invalidate() so far, but I think this can change in the future.
    
    This patch (of 12):
    
    This is an implementation of pmdp_establish() that is only suitable for
    an architecture that doesn't have hardware dirty/accessed bits.  In this
    case we can't race with CPU which sets these bits and non-atomic
    approach is fine.
    
    Link: http://lkml.kernel.org/r/20171213105756.69879-2-kirill.shutemov@linux.intel.com
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David Daney <david.daney@cavium.com>
    Cc: David Miller <davem@davemloft.net>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Nitin Gupta <nitin.m.gupta@oracle.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vineet Gupta <vgupta@synopsys.com>
    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 305e56756da71e0ef7cc8d91b8e66fafbb6e5d5a
Author: Yisheng Xie <xieyisheng1@huawei.com>
Date:   Wed Jan 31 16:16:15 2018 -0800

    mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
    
    
    [ Upstream commit 0486a38bcc4749808edbc848f1bcf232042770fc ]
    
    As in manpage of migrate_pages, the errno should be set to EINVAL when
    none of the node IDs specified by new_nodes are on-line and allowed by
    the process's current cpuset context, or none of the specified nodes
    contain memory.  However, when test by following case:
    
            new_nodes = 0;
            old_nodes = 0xf;
            ret = migrate_pages(pid, old_nodes, new_nodes, MAX);
    
    The ret will be 0 and no errno is set.  As the new_nodes is empty, we
    should expect EINVAL as documented.
    
    To fix the case like above, this patch check whether target nodes AND
    current task_nodes is empty, and then check whether AND
    node_states[N_MEMORY] is empty.
    
    Link: http://lkml.kernel.org/r/1510882624-44342-4-git-send-email-xieyisheng1@huawei.com
    Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Chris Salls <salls@cs.ucsb.edu>
    Cc: Christopher Lameter <cl@linux.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Tan Xiaojun <tanxiaojun@huawei.com>
    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 6cab60ac6a0a978ac58e27f79012122f90e75a1d
Author: Yisheng Xie <xieyisheng1@huawei.com>
Date:   Wed Jan 31 16:16:11 2018 -0800

    mm/mempolicy: fix the check of nodemask from user
    
    
    [ Upstream commit 56521e7a02b7b84a5e72691a1fb15570e6055545 ]
    
    As Xiaojun reported the ltp of migrate_pages01 will fail on arm64 system
    which has 4 nodes[0...3], all have memory and CONFIG_NODES_SHIFT=2:
    
      migrate_pages01    0  TINFO  :  test_invalid_nodes
      migrate_pages01   14  TFAIL  :  migrate_pages_common.c:45: unexpected failure - returned value = 0, expected: -1
      migrate_pages01   15  TFAIL  :  migrate_pages_common.c:55: call succeeded unexpectedly
    
    In this case the test_invalid_nodes of migrate_pages01 will call:
    SYSC_migrate_pages as:
    
      migrate_pages(0, , {0x0000000000000001}, 64, , {0x0000000000000010}, 64) = 0
    
    The new nodes specifies one or more node IDs that are greater than the
    maximum supported node ID, however, the errno is not set to EINVAL as
    expected.
    
    As man pages of set_mempolicy[1], mbind[2], and migrate_pages[3]
    mentioned, when nodemask specifies one or more node IDs that are greater
    than the maximum supported node ID, the errno should set to EINVAL.
    However, get_nodes only check whether the part of bits
    [BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES), maxnode) is zero or not, and
    remain [MAX_NUMNODES, BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES)
    unchecked.
    
    This patch is to check the bits of [MAX_NUMNODES, maxnode) in get_nodes
    to let migrate_pages set the errno to EINVAL when nodemask specifies one
    or more node IDs that are greater than the maximum supported node ID,
    which follows the manpage's guide.
    
    [1] http://man7.org/linux/man-pages/man2/set_mempolicy.2.html
    [2] http://man7.org/linux/man-pages/man2/mbind.2.html
    [3] http://man7.org/linux/man-pages/man2/migrate_pages.2.html
    
    Link: http://lkml.kernel.org/r/1510882624-44342-3-git-send-email-xieyisheng1@huawei.com
    Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
    Reported-by: Tan Xiaojun <tanxiaojun@huawei.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Chris Salls <salls@cs.ucsb.edu>
    Cc: Christopher Lameter <cl@linux.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    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 a7fbc7f3134ab4848898383a0852a8e768311498
Author: piaojun <piaojun@huawei.com>
Date:   Wed Jan 31 16:15:32 2018 -0800

    ocfs2: return error when we attempt to access a dirty bh in jbd2
    
    
    [ Upstream commit d984187e3a1ad7d12447a7ab2c43ce3717a2b5b3 ]
    
    We should not reuse the dirty bh in jbd2 directly due to the following
    situation:
    
    1. When removing extent rec, we will dirty the bhs of extent rec and
       truncate log at the same time, and hand them over to jbd2.
    
    2. The bhs are submitted to jbd2 area successfully.
    
    3. The write-back thread of device help flush the bhs to disk but
       encounter write error due to abnormal storage link.
    
    4. After a while the storage link become normal. Truncate log flush
       worker triggered by the next space reclaiming found the dirty bh of
       truncate log and clear its 'BH_Write_EIO' and then set it uptodate in
       __ocfs2_journal_access():
    
       ocfs2_truncate_log_worker
         ocfs2_flush_truncate_log
           __ocfs2_flush_truncate_log
             ocfs2_replay_truncate_records
               ocfs2_journal_access_di
                 __ocfs2_journal_access // here we clear io_error and set 'tl_bh' uptodata.
    
    5. Then jbd2 will flush the bh of truncate log to disk, but the bh of
       extent rec is still in error state, and unfortunately nobody will
       take care of it.
    
    6. At last the space of extent rec was not reduced, but truncate log
       flush worker have given it back to globalalloc. That will cause
       duplicate cluster problem which could be identified by fsck.ocfs2.
    
    Sadly we can hardly revert this but set fs read-only in case of ruining
    atomicity and consistency of space reclaim.
    
    Link: http://lkml.kernel.org/r/5A6E8092.8090701@huawei.com
    Fixes: acf8fdbe6afb ("ocfs2: do not BUG if buffer not uptodate in __ocfs2_journal_access")
    Signed-off-by: Jun Piao <piaojun@huawei.com>
    Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com>
    Reviewed-by: Changwei Ge <ge.changwei@h3c.com>
    Cc: Mark Fasheh <mfasheh@versity.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Joseph Qi <jiangqi903@gmail.com>
    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 a66174eb4a149b7919d174d9a7ce6ad9909c5ee2
Author: piaojun <piaojun@huawei.com>
Date:   Wed Jan 31 16:14:59 2018 -0800

    ocfs2/acl: use 'ip_xattr_sem' to protect getting extended attribute
    
    
    [ Upstream commit 16c8d569f5704a84164f30ff01b29879f3438065 ]
    
    The race between *set_acl and *get_acl will cause getting incomplete
    xattr data as below:
    
      processA                                    processB
    
      ocfs2_set_acl
        ocfs2_xattr_set
          __ocfs2_xattr_set_handle
    
                                                  ocfs2_get_acl_nolock
                                                    ocfs2_xattr_get_nolock:
    
    processB may get incomplete xattr data if processA hasn't set_acl done.
    
    So we should use 'ip_xattr_sem' to protect getting extended attribute in
    ocfs2_get_acl_nolock(), as other processes could be changing it
    concurrently.
    
    Link: http://lkml.kernel.org/r/5A5DDCFF.7030001@huawei.com
    Signed-off-by: Jun Piao <piaojun@huawei.com>
    Reviewed-by: Alex Chen <alex.chen@huawei.com>
    Cc: Mark Fasheh <mfasheh@versity.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Joseph Qi <jiangqi903@gmail.com>
    Cc: Changwei Ge <ge.changwei@h3c.com>
    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 66aaeed2796ef50af8775cad209e62c173463d05
Author: piaojun <piaojun@huawei.com>
Date:   Wed Jan 31 16:14:44 2018 -0800

    ocfs2: return -EROFS to mount.ocfs2 if inode block is invalid
    
    
    [ Upstream commit 025bcbde3634b2c9b316f227fed13ad6ad6817fb ]
    
    If metadata is corrupted such as 'invalid inode block', we will get
    failed by calling 'mount()' and then set filesystem readonly as below:
    
      ocfs2_mount
        ocfs2_initialize_super
          ocfs2_init_global_system_inodes
            ocfs2_iget
              ocfs2_read_locked_inode
                ocfs2_validate_inode_block
                  ocfs2_error
                    ocfs2_handle_error
                      ocfs2_set_ro_flag(osb, 0);  // set readonly
    
    In this situation we need return -EROFS to 'mount.ocfs2', so that user
    can fix it by fsck.  And then mount again.  In addition, 'mount.ocfs2'
    should be updated correspondingly as it only return 1 for all errno.
    And I will post a patch for 'mount.ocfs2' too.
    
    Link: http://lkml.kernel.org/r/5A4302FA.2010606@huawei.com
    Signed-off-by: Jun Piao <piaojun@huawei.com>
    Reviewed-by: Alex Chen <alex.chen@huawei.com>
    Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
    Reviewed-by: Changwei Ge <ge.changwei@h3c.com>
    Reviewed-by: Gang He <ghe@suse.com>
    Cc: Mark Fasheh <mfasheh@versity.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    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 710b5124aac67c4a48d29e32c2d9525278db405b
Author: Jan H. Schönherr <jschoenh@amazon.de>
Date:   Wed Jan 31 16:14:04 2018 -0800

    fs/dax.c: release PMD lock even when there is no PMD support in DAX
    
    
    [ Upstream commit ee190ca6516bc8257e3d36187ca6f0f71a9ec477 ]
    
    follow_pte_pmd() can theoretically return after having acquired a PMD
    lock, even when DAX was not compiled with CONFIG_FS_DAX_PMD.
    
    Release the PMD lock unconditionally.
    
    Link: http://lkml.kernel.org/r/20180118133839.20587-1-jschoenh@amazon.de
    Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
    Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
    Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    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 cc0600dae30fe2ca2f3783599420a1b9bb88715d
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Thu Jan 25 16:37:07 2018 +0100

    x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when running nested
    
    
    [ Upstream commit d391f1207067268261add0485f0f34503539c5b0 ]
    
    I was investigating an issue with seabios >= 1.10 which stopped working
    for nested KVM on Hyper-V. The problem appears to be in
    handle_ept_violation() function: when we do fast mmio we need to skip
    the instruction so we do kvm_skip_emulated_instruction(). This, however,
    depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS.
    However, this is not the case.
    
    Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when
    EPT MISCONFIG occurs. While on real hardware it was observed to be set,
    some hypervisors follow the spec and don't set it; we end up advancing
    IP with some random value.
    
    I checked with Microsoft and they confirmed they don't fill
    VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG.
    
    Fix the issue by doing instruction skip through emulator when running
    nested.
    
    Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae
    Suggested-by: Radim Krčmář <rkrcmar@redhat.com>
    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.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 d757c3a9cf4a8af26d085054731ebd9b5bc9983c
Author: KarimAllah Ahmed <karahmed@amazon.de>
Date:   Wed Jan 17 19:18:56 2018 +0100

    kvm: Map PFN-type memory regions as writable (if possible)
    
    
    [ Upstream commit a340b3e229b24a56f1c7f5826b15a3af0f4b13e5 ]
    
    For EPT-violations that are triggered by a read, the pages are also mapped with
    write permissions (if their memory region is also writable). That would avoid
    getting yet another fault on the same page when a write occurs.
    
    This optimization only happens when you have a "struct page" backing the memory
    region. So also enable it for memory regions that do not have a "struct page".
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: kvm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.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 a6a25002e6d83c4b66297a0fd192927c8fa0988d
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Jan 30 22:21:48 2018 -0600

    tcp_nv: fix potential integer overflow in tcpnv_acked
    
    
    [ Upstream commit e4823fbd229bfbba368b40cdadb8f4eeb20604cc ]
    
    Add suffix ULL to constant 80000 in order to avoid a potential integer
    overflow and give the compiler complete information about the proper
    arithmetic to use. Notice that this constant is used in a context that
    expects an expression of type u64.
    
    The current cast to u64 effectively applies to the whole expression
    as an argument of type u64 to be passed to div64_u64, but it does
    not prevent it from being evaluated using 32-bit arithmetic instead
    of 64-bit arithmetic.
    
    Also, once the expression is properly evaluated using 64-bit arithmentic,
    there is no need for the parentheses and the external cast to u64.
    
    Addresses-Coverity-ID: 1357588 ("Unintentional integer overflow")
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.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 ad10785a706e63ff155fc97860cdcc5e3bc5992d
Author: Dmitry Vyukov <dvyukov@google.com>
Date:   Mon Jan 29 13:21:20 2018 +0100

    netfilter: x_tables: fix pointer leaks to userspace
    
    
    [ Upstream commit 1e98ffea5a8935ec040ab72299e349cb44b8defd ]
    
    Several netfilter matches and targets put kernel pointers into
    info objects, but don't set usersize in descriptors.
    This leads to kernel pointer leaks if a match/target is set
    and then read back to userspace.
    
    Properly set usersize for these matches/targets.
    
    Found with manual code inspection.
    
    Fixes: ec2318904965 ("xtables: extend matches and targets with .usersize")
    Signed-off-by: Dmitry Vyukov <dvyukov@google.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 2b7cc93682acf720f6b2e1a690ccdae71129e6fc
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Wed Jan 24 14:23:31 2018 +0100

    x86/hyperv: Check for required priviliges in hyperv_init()
    
    
    [ Upstream commit 89a8f6d4904c8cf3ff8fee9fdaff392a6bbb8bf6 ]
    
    In hyperv_init() its presumed that it always has access to VP index and
    hypercall MSRs while according to the specification it should be checked if
    it's allowed to access the corresponding MSRs before accessing them.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: kvm@vger.kernel.org
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Cc: "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>
    Cc: Roman Kagan <rkagan@virtuozzo.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: devel@linuxdriverproject.org
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
    Cc: Cathy Avery <cavery@redhat.com>
    Cc: Mohammed Gamal <mmorsy@redhat.com>
    Link: https://lkml.kernel.org/r/20180124132337.30138-2-vkuznets@redhat.com
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdf635a66c5ba80fa03275265d6191fb3adf33c8
Author: Andy Spencer <aspencer@spacex.com>
Date:   Thu Jan 25 19:37:50 2018 -0800

    gianfar: prevent integer wrapping in the rx handler
    
    
    [ Upstream commit 202a0a70e445caee1d0ec7aae814e64b1189fa4d ]
    
    When the frame check sequence (FCS) is split across the last two frames
    of a fragmented packet, part of the FCS gets counted twice, once when
    subtracting the FCS, and again when subtracting the previously received
    data.
    
    For example, if 1602 bytes are received, and the first fragment contains
    the first 1600 bytes (including the first two bytes of the FCS), and the
    second fragment contains the last two bytes of the FCS:
    
      'skb->len == 1600' from the first fragment
    
      size  = lstatus & BD_LENGTH_MASK; # 1602
      size -= ETH_FCS_LEN;              # 1598
      size -= skb->len;                 # -2
    
    Since the size is unsigned, it wraps around and causes a BUG later in
    the packet handling, as shown below:
    
      kernel BUG at ./include/linux/skbuff.h:2068!
      Oops: Exception in kernel mode, sig: 5 [#1]
      ...
      NIP [c021ec60] skb_pull+0x24/0x44
      LR [c01e2fbc] gfar_clean_rx_ring+0x498/0x690
      Call Trace:
      [df7edeb0] [c01e2c1c] gfar_clean_rx_ring+0xf8/0x690 (unreliable)
      [df7edf20] [c01e33a8] gfar_poll_rx_sq+0x3c/0x9c
      [df7edf40] [c023352c] net_rx_action+0x21c/0x274
      [df7edf90] [c0329000] __do_softirq+0xd8/0x240
      [df7edff0] [c000c108] call_do_irq+0x24/0x3c
      [c0597e90] [c00041dc] do_IRQ+0x64/0xc4
      [c0597eb0] [c000d920] ret_from_except+0x0/0x18
      --- interrupt: 501 at arch_cpu_idle+0x24/0x5c
    
    Change the size to a signed integer and then trim off any part of the
    FCS that was received prior to the last fragment.
    
    Fixes: 6c389fc931bc ("gianfar: fix size of scatter-gathered frames")
    Signed-off-by: Andy Spencer <aspencer@spacex.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 67fa8bfff771973a6867ca4be8b6c29e6e2e312f
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Mon Dec 18 11:25:05 2017 -0700

    ntb_transport: Fix bug with max_mw_size parameter
    
    
    [ Upstream commit cbd27448faff4843ac4b66cc71445a10623ff48d ]
    
    When using the max_mw_size parameter of ntb_transport to limit the size of
    the Memory windows, communication cannot be established and the queues
    freeze.
    
    This is because the mw_size that's reported to the peer is correctly
    limited but the size used locally is not. So the MW is initialized
    with a buffer smaller than the window but the TX side is using the
    full window. This means the TX side will be writing to a region of the
    window that points nowhere.
    
    This is easily fixed by applying the same limit to tx_size in
    ntb_transport_init_queue().
    
    Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d810c548157f9f2533864bfb220787eaa9e36e3e
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Sun Jan 28 11:25:30 2018 +0200

    RDMA/mlx5: Avoid memory leak in case of XRCD dealloc failure
    
    
    [ Upstream commit b081808a66345ba725b77ecd8d759bee874cd937 ]
    
    Failure in XRCD FW deallocation command leaves memory leaked and
    returns error to the user which he can't do anything about it.
    
    This patch changes behavior to always free memory and always return
    success to the user.
    
    Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
    Reviewed-by: Majd Dibbiny <majd@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Yuval Shaia <yuval.shaia@oracle.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 0bddd43ac2001d87471117ff29e789aa3bcfd18b
Author: Michael Bringmann <mwb@linux.vnet.ibm.com>
Date:   Tue Nov 28 16:58:40 2017 -0600

    powerpc/numa: Ensure nodes initialized for hotplug
    
    
    [ Upstream commit ea05ba7c559c8e5a5946c3a94a2a266e9a6680a6 ]
    
    This patch fixes some problems encountered at runtime with
    configurations that support memory-less nodes, or that hot-add CPUs
    into nodes that are memoryless during system execution after boot. The
    problems of interest include:
    
    * Nodes known to powerpc to be memoryless at boot, but to have CPUs in
      them are allowed to be 'possible' and 'online'. Memory allocations
      for those nodes are taken from another node that does have memory
      until and if memory is hot-added to the node.
    
    * Nodes which have no resources assigned at boot, but which may still
      be referenced subsequently by affinity or associativity attributes,
      are kept in the list of 'possible' nodes for powerpc. Hot-add of
      memory or CPUs to the system can reference these nodes and bring
      them online instead of redirecting the references to one of the set
      of nodes known to have memory at boot.
    
    Note that this software operates under the context of CPU hotplug. We
    are not doing memory hotplug in this code, but rather updating the
    kernel's CPU topology (i.e. arch_update_cpu_topology /
    numa_update_cpu_topology). We are initializing a node that may be used
    by CPUs or memory before it can be referenced as invalid by a CPU
    hotplug operation. CPU hotplug operations are protected by a range of
    APIs including cpu_maps_update_begin/cpu_maps_update_done,
    cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
    Memory hotplug operations, including try_online_node, are protected by
    mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
    case of CPUs being hot-added to a previously memoryless node, the
    try_online_node operation occurs wholly within the CPU locks with no
    overlap. Using HMC hot-add/hot-remove operations, we have been able to
    add and remove CPUs to any possible node without failures. HMC
    operations involve a degree self-serialization, though.
    
    Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
    Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0caebc3810328467cc67dadee612603d24087a9f
Author: Michael Bringmann <mwb@linux.vnet.ibm.com>
Date:   Tue Nov 28 16:58:36 2017 -0600

    powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
    
    
    [ Upstream commit a346137e9142b039fd13af2e59696e3d40c487ef ]
    
    On powerpc systems which allow 'hot-add' of CPU or memory resources,
    it may occur that the new resources are to be inserted into nodes that
    were not used for these resources at bootup. In the kernel, any node
    that is used must be defined and initialized. These empty nodes may
    occur when,
    
    * Dedicated vs. shared resources. Shared resources require information
      such as the VPHN hcall for CPU assignment to nodes. Associativity
      decisions made based on dedicated resource rules, such as
      associativity properties in the device tree, may vary from decisions
      made using the values returned by the VPHN hcall.
    
    * memoryless nodes at boot. Nodes need to be defined as 'possible' at
      boot for operation with other code modules. Previously, the powerpc
      code would limit the set of possible nodes to those which have
      memory assigned at boot, and were thus online. Subsequent add/remove
      of CPUs or memory would only work with this subset of possible
      nodes.
    
    * memoryless nodes with CPUs at boot. Due to the previous restriction
      on nodes, nodes that had CPUs but no memory were being collapsed
      into other nodes that did have memory at boot. In practice this
      meant that the node assignment presented by the runtime kernel
      differed from the affinity and associativity attributes presented by
      the device tree or VPHN hcalls. Nodes that might be known to the
      pHyp were not 'possible' in the runtime kernel because they did not
      have memory at boot.
    
    This patch ensures that sufficient nodes are defined to support
    configuration requirements after boot, as well as at boot. This patch
    set fixes a couple of problems.
    
    * Nodes known to powerpc to be memoryless at boot, but to have CPUs in
      them are allowed to be 'possible' and 'online'. Memory allocations
      for those nodes are taken from another node that does have memory
      until and if memory is hot-added to the node. * Nodes which have no
      resources assigned at boot, but which may still be referenced
      subsequently by affinity or associativity attributes, are kept in
      the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
      to the system can reference these nodes and bring them online
      instead of redirecting to one of the set of nodes that were known to
      have memory at boot.
    
    This patch extracts the value of the lowest domain level (number of
    allocable resources) from the device tree property
    "ibm,max-associativity-domains" to use as the maximum number of nodes
    to setup as possibly available in the system. This new setting will
    override the instruction:
    
        nodes_and(node_possible_map, node_possible_map, node_online_map);
    
    presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
    
    If the "ibm,max-associativity-domains" property is not present at
    boot, no operation will be performed to define or enable additional
    nodes, or enable the above 'nodes_and()'.
    
    Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
    Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b086dd2d79d911abbc6001ef2d59dc6a042ae5d9
Author: Mickaël Salaün <mic@digikod.net>
Date:   Fri Jan 26 01:39:30 2018 +0100

    samples/bpf: Partially fixes the bpf.o build
    
    
    [ Upstream commit c25ef6a5e62fa212d298ce24995ce239f29b5f96 ]
    
    Do not build lib/bpf/bpf.o with this Makefile but use the one from the
    library directory.  This avoid making a buggy bpf.o file (e.g. missing
    symbols).
    
    This patch is useful if some code (e.g. Landlock tests) needs both the
    bpf.o (from tools/lib/bpf) and the bpf_load.o (from samples/bpf).
    
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64e5e46cdd8b3fcfed016dc89f057087346ad742
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Dec 27 08:26:33 2017 -0500

    i40e: fix reported mask for ntuple filters
    
    
    [ Upstream commit 40339af33c703bacb336493157d43c86a8bf2fed ]
    
    In commit 36777d9fa24c ("i40e: check current configured input set when
    adding ntuple filters") some code was added to report the input set
    mask for a given filter when reporting it to the user.
    
    This code is necessary so that the reported filter correctly displays
    that it is or is not masking certain fields.
    
    Unfortunately the code was incorrect. Development error accidentally
    swapped the mask values for the IPv4 addresses with the L4 port numbers.
    The port numbers are only 16bits wide while IPv4 addresses are 32 bits.
    Unfortunately we assigned only 16 bits to the IPv4 address masks.
    Additionally we assigned 32bit value 0xFFFFFFF to the TCP port numbers.
    This second part does not matter as the value would be truncated to
    16bits regardless, but it is unnecessary.
    
    Fix the reported masks to properly report that the entire field is
    masked.
    
    Fixes: 36777d9fa24c ("i40e: check current configured input set when adding ntuple filters")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ec85fe4e259a25e69c7d73fa5efe47074fcff46
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Dec 27 08:24:12 2017 -0500

    i40e: program fragmented IPv4 filter input set
    
    
    [ Upstream commit 02b4016bfe43d2d5ed043be7ffa56cda6a4d1100 ]
    
    When implementing support for IP_USER_FLOW filters, we correctly
    programmed a filter for both the non fragmented IPv4/Other filter, as
    well as the fragmented IPv4 filters. However, we did not properly
    program the input set for fragmented IPv4 PCTYPE. This meant that the
    filters would almost certainly not match, unless the user specified all
    of the flow types.
    
    Add support to program the fragmented IPv4 filter input set. Since we
    always program these filters together, we'll assume that the two input
    sets must match, and will thus always program the input sets to the same
    value.
    
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7addb3e4ad3db6a95a953c59884921b5883dcdec
Author: Emil Tantilov <emil.s.tantilov@intel.com>
Date:   Fri Jan 12 14:02:56 2018 -0800

    ixgbe: don't set RXDCTL.RLPML for 82599
    
    
    [ Upstream commit 2bafa8fac19a31ca72ae1a3e48df35f73661dbed ]
    
    commit 2de6aa3a666e ("ixgbe: Add support for padding packet")
    
    Uses RXDCTL.RLPML to limit the maximum frame size on Rx when using
    build_skb. Unfortunately that register does not work on 82599.
    
    Added an explicit check to avoid setting this register on 82599 MAC.
    
    Extended the comment related to the setting of RXDCTL.RLPML to better
    explain its purpose.
    
    Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27eb641f236843b34819ed05d6288dd54053827b
Author: Jake Daryll Obina <jake.obina@gmail.com>
Date:   Fri Sep 22 00:00:14 2017 +0800

    jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path
    
    
    [ Upstream commit 5bdd0c6f89fba430e18d636493398389dadc3b17 ]
    
    If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode()
    can get called twice in the error handling path, the first call in
    jffs2_iget() itself and the second through iget_failed(). This can result
    to a use-after-free error in the second jffs2_do_clear_inode() call, such
    as shown by the oops below wherein the second jffs2_do_clear_inode() call
    was trying to free node fragments that were already freed in the first
    jffs2_do_clear_inode() call.
    
    [   78.178860] jffs2: error: (1904) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 24 at physical location 0x1fc00c
    [   78.178914] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
    [   78.185871] pgd = ffffffc03a567000
    [   78.188794] [6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
    [   78.194968] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    ...
    [   78.513147] PC is at rb_first_postorder+0xc/0x28
    [   78.516503] LR is at jffs2_kill_fragtree+0x28/0x90 [jffs2]
    [   78.520672] pc : [<ffffff8008323d28>] lr : [<ffffff8000eb1cc8>] pstate: 60000105
    [   78.526757] sp : ffffff800cea38f0
    [   78.528753] x29: ffffff800cea38f0 x28: ffffffc01f3f8e80
    [   78.532754] x27: 0000000000000000 x26: ffffff800cea3c70
    [   78.536756] x25: 00000000dc67c8ae x24: ffffffc033d6945d
    [   78.540759] x23: ffffffc036811740 x22: ffffff800891a5b8
    [   78.544760] x21: 0000000000000000 x20: 0000000000000000
    [   78.548762] x19: ffffffc037d48910 x18: ffffff800891a588
    [   78.552764] x17: 0000000000000800 x16: 0000000000000c00
    [   78.556766] x15: 0000000000000010 x14: 6f2065646f6e695f
    [   78.560767] x13: 6461657220726f66 x12: 2064656c69616620
    [   78.564769] x11: 435243203a6c616e x10: 7265746e695f6564
    [   78.568771] x9 : 6f6e695f64616572 x8 : ffffffc037974038
    [   78.572774] x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000008
    [   78.576775] x5 : 002f91d85bd44a2f x4 : 0000000000000000
    [   78.580777] x3 : 0000000000000000 x2 : 000000403755e000
    [   78.584779] x1 : 6b6b6b6b6b6b6b6b x0 : 6b6b6b6b6b6b6b6b
    ...
    [   79.038551] [<ffffff8008323d28>] rb_first_postorder+0xc/0x28
    [   79.042962] [<ffffff8000eb5578>] jffs2_do_clear_inode+0x88/0x100 [jffs2]
    [   79.048395] [<ffffff8000eb9ddc>] jffs2_evict_inode+0x3c/0x48 [jffs2]
    [   79.053443] [<ffffff8008201ca8>] evict+0xb0/0x168
    [   79.056835] [<ffffff8008202650>] iput+0x1c0/0x200
    [   79.060228] [<ffffff800820408c>] iget_failed+0x30/0x3c
    [   79.064097] [<ffffff8000eba0c0>] jffs2_iget+0x2d8/0x360 [jffs2]
    [   79.068740] [<ffffff8000eb0a60>] jffs2_lookup+0xe8/0x130 [jffs2]
    [   79.073434] [<ffffff80081f1a28>] lookup_slow+0x118/0x190
    [   79.077435] [<ffffff80081f4708>] walk_component+0xfc/0x28c
    [   79.081610] [<ffffff80081f4dd0>] path_lookupat+0x84/0x108
    [   79.085699] [<ffffff80081f5578>] filename_lookup+0x88/0x100
    [   79.089960] [<ffffff80081f572c>] user_path_at_empty+0x58/0x6c
    [   79.094396] [<ffffff80081ebe14>] vfs_statx+0xa4/0x114
    [   79.098138] [<ffffff80081ec44c>] SyS_newfstatat+0x58/0x98
    [   79.102227] [<ffffff800808354c>] __sys_trace_return+0x0/0x4
    [   79.106489] Code: d65f03c0 f9400001 b40000e1 aa0103e0 (f9400821)
    
    The jffs2_do_clear_inode() call in jffs2_iget() is unnecessary since
    iget_failed() will eventually call jffs2_do_clear_inode() if needed, so
    just remove it.
    
    Fixes: 5451f79f5f81 ("iget: stop JFFS2 from using iget() and read_inode()")
    Reviewed-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Jake Daryll Obina <jake.obina@gmail.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19b3638ce46065936c2092c983227ae7f2161220
Author: Jason Gunthorpe <jgg@mellanox.com>
Date:   Wed Jan 24 19:58:34 2018 -0700

    RDMA/uverbs: Use an unambiguous errno for method not supported
    
    
    [ Upstream commit 3624a8f02568f08aef299d3b117f2226f621177d ]
    
    Returning EOPNOTSUPP is problematic because it can also be
    returned by the method function, and we use it in quite a few
    places in drivers these days.
    
    Instead, dedicate EPROTONOSUPPORT to indicate that the ioctl framework
    is enabled but the requested object and method are not supported by
    the kernel. No other case will return this code, and it lets userspace
    know to fall back to write().
    
    grep says we do not use it today in drivers/infiniband subsystem.
    
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Reviewed-by: Matan Barak <matanb@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 827aab45cb16862083415abdb3e56313d59c347e
Author: Corentin LABBE <clabbe.montjoie@gmail.com>
Date:   Wed Jan 17 19:50:56 2018 +0100

    crypto: artpec6 - remove select on non-existing CRYPTO_SHA384
    
    
    [ Upstream commit 980b4c95e78e4113cb7b9f430f121dab1c814b6c ]
    
    Since CRYPTO_SHA384 does not exists, Kconfig should not select it.
    Anyway, all SHA384 stuff is in CRYPTO_SHA512 which is already selected.
    
    Fixes: a21eb94fc4d3i ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver")
    Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 592ea370bf1ce685bdb5bdf71eaf7e65190c551f
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Jan 22 18:01:42 2018 +0200

    device property: Define type of PROPERTY_ENRTY_*() macros
    
    
    [ Upstream commit c505cbd45f6e9c539d57dd171d95ec7e5e9f9cd0 ]
    
    Some of the drivers may use the macro at runtime flow, like
    
      struct property_entry p[10];
    ...
      p[index++] = PROPERTY_ENTRY_U8("u8 property", u8_data);
    
    In that case and absence of the data type compiler fails the build:
    
    drivers/char/ipmi/ipmi_dmi.c:79:29: error: Expected ; at end of statement
    drivers/char/ipmi/ipmi_dmi.c:79:29: error: got {
    
    Acked-by: Corey Minyard <cminyard@mvista.com>
    Cc: Corey Minyard <minyard@acm.org>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    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 c5fda2b8610b96f0035210952fb1dedcd73bf2ee
Author: Aaron Sierra <asierra@xes-inc.com>
Date:   Wed Jan 24 18:19:23 2018 -0600

    tty: serial: exar: Relocate sleep wake-up handling
    
    
    [ Upstream commit c7e1b4059075c9e8eed101d7cc5da43e95eb5e18 ]
    
    Exar sleep wake-up handling has been done on a per-channel basis by
    virtue of INT0 being accessible from each channel's address space. I
    believe this was initially done out of necessity, but now that Exar
    devices have their own driver, we can do things more efficiently by
    registering a dedicated INT0 handler at the PCI device level.
    
    I see this change providing the following benefits:
    
        1. If more than one port is active, eliminates the redundant bus
           cycles for reading INT0 on every interrupt.
        2. This note associated with hooking in the per-channel handler in
           8250_port.c is resolved:
            /* Fixme: probably not the best place for this */
    
    Cc: Matt Schulte <matts@commtech-fastcom.com>
    Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
    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 519a7119527c26984e6804abc422808681d1a117
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Wed Jan 24 11:36:29 2018 +0100

    x86/hyperv: Stop suppressing X86_FEATURE_PCID
    
    
    [ Upstream commit 617ab45c9a8900e64a78b43696c02598b8cad68b ]
    
    When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature
    was deliberately suppressed as a precaution: back then PCID was never
    exposed to Hyper-V guests and it wasn't clear what will happen if some day
    it becomes available. The day came and PCID/INVPCID features are already
    exposed on certain Hyper-V hosts.
    
    >From TLFS (as of 5.0b) it is unclear how TLB flush hypercalls combine with
    PCID. In particular the usage of PCID is per-cpu based: the same mm gets
    different CR3 values on different CPUs. If the hypercall does exact
    matching this will fail. However, this is not the case. David Zhang
    explains:
    
     "In practice, the AddressSpace argument is ignored on any VM that supports
      PCIDs.
    
      Architecturally, the AddressSpace argument must match the CR3 with PCID
      bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in
      long mode). The flush hypercalls flush all PCIDs for the specified
      AddressSpace."
    
    With this, PCID can be enabled.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: David Zhang <dazhan@microsoft.com>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: Haiyang Zhang <haiyangz@microsoft.com>
    Cc: "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: devel@linuxdriverproject.org
    Cc: "K. Y. Srinivasan" <kys@microsoft.com>
    Cc: Aditya Bhandari <adityabh@microsoft.com>
    Link: https://lkml.kernel.org/r/20180124103629.29980-1-vkuznets@redhat.com
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a1dda252663c930822c933232736cd05a8cb800
Author: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
Date:   Wed Jan 24 14:18:22 2018 -0800

    fm10k: fix "failed to kill vid" message for VF
    
    
    [ Upstream commit cf315ea596ec26d7aa542a9ce354990875a920c0 ]
    
    When a VF is under PF VLAN assignment:
    
    ip link set <pf> vf <#> vlan <vid>
    
    This will remove all previous entries in the VLAN table including those
    generated by VLAN interfaces created on the VF. The issue arises when
    the VF is under PF VLAN assignment and one or more of these VLAN
    interfaces of the VF are deleted. When deleting these VLAN interfaces,
    the following message will be generated in "dmesg":
    
    failed to kill vid 0081/<vid> for device <vf>
    
    This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error.
    The handler for this ndo is "fm10k_update_vid". Any calls to this
    function while under PF VLAN management will exit prematurely and, thus,
    it will generate the failure message.
    
    Additionally, since "fm10k_update_vid" exits prematurely, none of the
    VLAN update is performed. So, even though the actual VLAN interfaces of
    the VF will be deleted, the active_vlans bitmask is not cleared. When
    the VF is no longer under PF VLAN assignment, the driver mistakenly
    restores the previous entries of the VLAN table based on an
    unsynchronized list of active VLANs.
    
    The solution to this issue involves checking the VLAN update action type
    before exiting "fm10k_update_vid". If the VLAN update action type is to
    "add", this action will not be permitted while the VF is under PF VLAN
    assignment and the VLAN update is abandoned like before.
    
    However, if the VLAN update action type is to "kill", then we need to
    also clear the active_vlans bitmask. However, we don't need to actually
    queue any messages to the PF, because the MAC and VLAN tables have
    already been cleared, and the PF would silently ignore these requests
    anyways.
    
    Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan@intel.com>
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e7a0c139cbf09d602eabb935ad5a080c99cdd46
Author: Daniel Hua <daniel.hua@ni.com>
Date:   Tue Jan 2 08:33:18 2018 +0800

    igb: Clear TXSTMP when ptp_tx_work() is timeout
    
    
    [ Upstream commit 3a53285228165225a7f76c7d5ff1ddc0213ce0e4 ]
    
    Problem description:
    After ethernet cable connect and disconnect for several iterations on a
    device with i210, tx timestamp will stop being put into the socket.
    
    Steps to reproduce:
    1. Setup a device with i210 and wire it to a 802.1AS capable switch (
    Extreme Networks Summit x440 is used in our case)
    2. Have the gptp daemon running on the device and make sure it is synced
    with the switch
    3. Have the switch disable and enable the port, wait for the device gets
    resynced with the switch
    4. Iterates step 3 until the device is not albe to get resynced
    5. Review the log in dmesg and you will see warning message "igb : clearing
    Tx timestamp hang"
    
    Root cause:
    If ptp_tx_work() gets scheduled just before the port gets disabled, a LINK
    DOWN event will be processed before ptp_tx_work(), which may cause timeout
    in ptp_tx_work(). In the timeout logic, the TSYNCTXCTL's TXTT bit (Transmit
    timestamp valid bit) is not cleared, causing no new timestamp loaded to
    TXSTMP register. Consequently therefore, no new interrupt is triggerred by
    TSICR.TXTS bit and no more Tx timestamp send to the socket.
    
    Signed-off-by: Daniel Hua <daniel.hua@ni.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 187bf28199d85d12c68c836e1ba3fe903ba7fec3
Author: Corinna Vinschen <vinschen@redhat.com>
Date:   Mon Apr 10 10:58:14 2017 +0200

    igb: Allow to remove administratively set MAC on VFs
    
    
    [ Upstream commit 177132df5e45b134c147f419f567a3b56aafaf2b ]
    
    Before libvirt modifies the MAC address and vlan tag for an SRIOV VF
    for use by a virtual machine (either using vfio device assignment or
    macvtap passthru mode), it saves the current MAC address and vlan tag
    so that it can reset them to their original value when the guest is
    done.  Libvirt can't leave the VF MAC set to the value used by the
    now-defunct guest since it may be started again later using a
    different VF, but it certainly shouldn't just pick any random value,
    either. So it saves the state of everything prior to using the VF, and
    resets it to that.
    
    The igb driver initializes the MAC addresses of all VFs to
    00:00:00:00:00:00, and reports that when asked (via an RTM_GETLINK
    netlink message, also visible in the list of VFs in the output of "ip
    link show"). But when libvirt attempts to restore the MAC address back
    to 00:00:00:00:00:00 (using an RTM_SETLINK netlink message) the kernel
    responds with "Invalid argument".
    
    Forbidding a reset back to the original value leaves the VF MAC at the
    value set for the now-defunct virtual machine. Especially on a system
    with NetworkManager enabled, this has very bad consequences, since
    NetworkManager forces all interfacess to be IFF_UP all the time - if
    the same virtual machine is restarted using a different VF (or even on
    a different host), there will be multiple interfaces watching for
    traffic with the same MAC address.
    
    To allow libvirt to revert to the original state, we need a way to
    remove the administrative set MAC on a VF, to allow normal host
    operation again, and to reset/overwrite the VF MAC via VF netdev.
    
    This patch implements the outlined scenario by allowing to set the
    VF MAC to 00:00:00:00:00:00 via RTM_SETLINK on the PF.
    igb_ndo_set_vf_mac resets the IGB_VF_FLAG_PF_SET_MAC flag to 0,
    so it's possible to reset the VF MAC back to the original value via
    the VF netdev.
    
    Note: Recent patches to libvirt allow for a workaround if the NIC
    isn't capable of resetting the administrative MAC back to all 0, but
    in theory the NIC should allow resetting the MAC in the first place.
    
    Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
    Tested-by: Aaron Brown <arron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 048af64fd48f639bb97773c33e87ee6cf250ac99
Author: Jeffy Chen <jeffy.chen@rock-chips.com>
Date:   Tue Nov 21 16:25:17 2017 +0800

    ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink
    
    
    [ Upstream commit fde7f9dbc71365230eeb8c8ea97ce9b552c8e5bd ]
    
    The rt5514 dsp captures pcm data through spi directly, so we should not
    use rockchip-i2s as it's cpu dai like other codecs.
    
    Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again.
    
    Reported-by: Jimmy Cheng-Yi Chiang <cychiang@google.com>
    Fixes: (72cfb0f20c75 ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp)
    Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
    Tested-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f25ba4f6be4aa368a4ce22d225d4c09257b3667a
Author: Eryu Guan <eguan@redhat.com>
Date:   Wed Jan 24 01:20:00 2018 +0800

    blk-mq-debugfs: don't allow write on attributes with seq_operations set
    
    
    [ Upstream commit 6b136a24b05c81a24e0b648a4bd938bcd0c4f69e ]
    
    Attributes that only implement .seq_ops are read-only, any write to
    them should be rejected. But currently kernel would crash when
    writing to such debugfs entries, e.g.
    
    chmod +w /sys/kernel/debug/block/<dev>/requeue_list
    echo 0 > /sys/kernel/debug/block/<dev>/requeue_list
    chmod -w /sys/kernel/debug/block/<dev>/requeue_list
    
    Fix it by returning -EPERM in blk_mq_debugfs_write() when writing to
    such attributes.
    
    Cc: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Eryu Guan <eguan@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a42ebbdae0a58e62906a47fc36b89822c82f627a
Author: David Hildenbrand <david@redhat.com>
Date:   Tue Jan 16 18:15:25 2018 +0100

    KVM: s390: vsie: use READ_ONCE to access some SCB fields
    
    
    [ Upstream commit b3ecd4aa8632a86428605ab73393d14779019d82 ]
    
    Another VCPU might try to modify the SCB while we are creating the
    shadow SCB. In general this is no problem - unless the compiler decides
    to not load values once, but e.g. twice.
    
    For us, this is only relevant when checking/working with such values.
    E.g. the prefix value, the mso, state of transactional execution and
    addresses of satellite blocks.
    
    E.g. if we blindly forward values (e.g. general purpose registers or
    execution controls after masking), we don't care.
    
    Leaving unpin_blocks() untouched for now, will handle it separately.
    
    The worst thing right now that I can see would be a missed prefix
    un/remap (mso, prefix, tx) or using wrong guest addresses. Nothing
    critical, but let's try to avoid unpredictable behavior.
    
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Message-Id: <20180116171526.12343-2-david@redhat.com>
    Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Acked-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48d441324a58460e201f15309edf2e082392170d
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Fri Jan 12 12:04:45 2018 +0100

    platform/x86: thinkpad_acpi: suppress warning about palm detection
    
    
    [ Upstream commit 587d8628fb71c3bfae29fb2bbe84c1478c59bac8 ]
    
    This patch prevents the thinkpad_acpi driver from warning about 2 event
    codes returned for keyboard palm-detection. No behavioral changes,
    other than suppressing the warning in the kernel log. The events are
    still forwarded via acpi-netlink channels.
    
    We could, optionally, decide to forward the event through a
    input-switch on the tpacpi input device. However, so far no suitable
    input-code exists, and no similar drivers report such events. Hence,
    leave it an acpi event for now.
    
    Note that the event-codes are named based on empirical studies. On the
    ThinkPad X1 5th Gen the sensor can be found underneath the arrow key.
    
    Cc: Matthew Thode <mthode@mthode.org>
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9d78055c6aea80faa783b105520efa05b443075
Author: Alan Brady <alan.brady@intel.com>
Date:   Fri Jan 5 04:55:21 2018 -0500

    i40evf: ignore link up if not running
    
    
    [ Upstream commit e0346f9fcb6c636d2f870e6666de8781413f34ea ]
    
    If we receive the link status message from PF with link up before queues
    are actually enabled, it will trigger a TX hang.  This fixes the issue
    by ignoring a link up message if the VF state is not yet in RUNNING
    state.
    
    Signed-off-by: Alan Brady <alan.brady@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09f6d65db13b0a58af216d11a8e3f23069dc0f47
Author: Avinash Dayanand <avinash.dayanand@intel.com>
Date:   Mon Dec 18 05:16:43 2017 -0500

    i40evf: Don't schedule reset_task when device is being removed
    
    
    [ Upstream commit 06aa040f039404a0039a5158cd12f41187487a1f ]
    
    When a host disables and enables a PF device, all the associated
    VFs are removed and added back in. It also generates a PFR which in turn
    resets all the connected VFs. This behaviour is different from that of
    Linux guest on Linux host. Hence we end up in a situation where there's
    a PFR and device removal at the same time. And watchdog doesn't have a
    clue about this and schedules a reset_task. This patch adds code to send
    signal to reset_task that the device is currently being removed.
    
    Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c7ae4ed2fcd5a10bdac40b82deaa7f940f001ed
Author: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Date:   Tue Jan 23 13:30:44 2018 +0900

    bpf: test_maps: cleanup sockmaps when test ends
    
    
    [ Upstream commit 783687810e986a15ffbf86c516a1a48ff37f38f7 ]
    
    Bug: BPF programs and maps related to sockmaps test exist
    in memory even after test_maps ends.
    
    This patch fixes it as a short term workaround (sockmap
    kernel side needs real fixing) by empyting sockmaps when
    test ends.
    
    Fixes: 6f6d33f3b3d0f ("bpf: selftests add sockmap tests")
    Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
    [ daniel: Note on workaround. ]
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c6e38aeff2b4131de2718a993d07995844dcc8
Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
Date:   Tue Jan 23 09:10:19 2018 -0700

    block: Set BIO_TRACE_COMPLETION on new bio during split
    
    
    [ Upstream commit 20d59023c5ec4426284af492808bcea1f39787ef ]
    
    We inadvertently set it again on the source bio, but we need
    to set it on the new split bio instead.
    
    Fixes: fbbaf700e7b1 ("block: trace completion of all bios.")
    Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2e73df302f31b588086b6eb5a4151b196faf427
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Tue Jan 23 02:10:27 2018 +0000

    nfp: fix error return code in nfp_pci_probe()
    
    
    [ Upstream commit e58decc9c51eb61697aba35ba8eda33f4b80552d ]
    
    Fix to return error code -EINVAL instead of 0 when num_vfs above
    limit_vfs, as done elsewhere in this function.
    
    Fixes: 0dc786219186 ("nfp: handle SR-IOV already enabled when driver is probing")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Acked-by: Jakub Kicinski <jakub.kicinski@netronome.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 8591958413bfeacbe294dbb846e53c7bbd82e685
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jan 10 12:39:03 2018 +0300

    HID: roccat: prevent an out of bounds read in kovaplus_profile_activated()
    
    
    [ Upstream commit 7ad81482cad67cbe1ec808490d1ddfc420c42008 ]
    
    We get the "new_profile_index" value from the mouse device when we're
    handling raw events.  Smatch taints it as untrusted data and complains
    that we need a bounds check.  This seems like a reasonable warning
    otherwise there is a small read beyond the end of the array.
    
    Fixes: 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Silvan Jegen <s.jegen@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 6a5505da41faa98555526ba50ca9865a2bd0ef99
Author: Andi Shyti <andi.shyti@samsung.com>
Date:   Mon Jan 22 17:32:46 2018 -0800

    Input: stmfts - set IRQ_NOAUTOEN to the irq flag
    
    
    [ Upstream commit cba04cdf437d745fac85220d1d692a9ae23d7004 ]
    
    The interrupt is requested before the device is powered on and
    it's value in some cases cannot be reliable. It happens on some
    devices that an interrupt is generated as soon as requested
    before having the chance to disable the irq.
    
    Set the irq flag as IRQ_NOAUTOEN before requesting it.
    
    This patch mutes the error:
    
      stmfts 2-0049: failed to read events: -11
    
    received sometimes during boot time.
    
    Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8afed2798e50f3f9b84a6b0c9eb9810119a0fc3f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Jan 18 14:16:38 2018 +0100

    scsi: fas216: fix sense buffer initialization
    
    
    [ Upstream commit 96d5eaa9bb74d299508d811d865c2c41b38b0301 ]
    
    While testing with the ARM specific memset() macro removed, I ran into a
    compiler warning that shows an old bug:
    
    drivers/scsi/arm/fas216.c: In function 'fas216_rq_sns_done':
    drivers/scsi/arm/fas216.c:2014:40: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess]
    
    It turns out that the definition of the scsi_cmd structure changed back
    in linux-2.6.25, so now we clear only four bytes (sizeof(pointer))
    instead of 96 (SCSI_SENSE_BUFFERSIZE). I did not check whether we
    actually need to initialize the buffer here, but it's clear that if we
    do it, we should use the correct size.
    
    Fixes: de25deb18016 ("[SCSI] use dynamically allocated sense buffer")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    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 800fda575b119312b429fe488680e990b32e2de6
Author: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date:   Mon Jan 15 17:47:23 2018 +0100

    scsi: devinfo: fix format of the device list
    
    
    [ Upstream commit 3f884a0a8bdf28cfd1e9987d54d83350096cdd46 ]
    
    Replace "" with NULL for product revision level, and merge TEXEL
    duplicate entries.
    
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
    Cc: SCSI ML <linux-scsi@vger.kernel.org>
    Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.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 a09881cfb7135787375a3975cbd05bc94e07a0d0
Author: Sheng Yong <shengyong1@huawei.com>
Date:   Wed Jan 17 12:11:31 2018 +0800

    f2fs: avoid hungtask when GC encrypted block if io_bits is set
    
    
    [ Upstream commit a9d572c7550044d5b217b5287d99a2e6d34b97b0 ]
    
    When io_bits is set, GCing encrypted block may hit the following hungtask.
    Since io_bits requires aligned block address, f2fs_submit_page_write may
    return -EAGAIN if new_blkaddr does not satisify io_bits alignment. As a
    result, the encrypted page will never be writtenback.
    
    This patch makes move_data_block aware the EAGAIN error and cancel the
    writeback.
    
    [  246.751371] INFO: task kworker/u4:4:797 blocked for more than 90 seconds.
    [  246.752423]       Not tainted 4.15.0-rc4+ #11
    [  246.754176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  246.755336] kworker/u4:4    D25448   797      2 0x80000000
    [  246.755597] Workqueue: writeback wb_workfn (flush-7:0)
    [  246.755616] Call Trace:
    [  246.755695]  ? __schedule+0x322/0xa90
    [  246.755761]  ? blk_init_request_from_bio+0x120/0x120
    [  246.755773]  ? pci_mmcfg_check_reserved+0xb0/0xb0
    [  246.755801]  ? __radix_tree_create+0x19e/0x200
    [  246.755813]  ? delete_node+0x136/0x370
    [  246.755838]  schedule+0x43/0xc0
    [  246.755904]  io_schedule+0x17/0x40
    [  246.755939]  wait_on_page_bit_common+0x17b/0x240
    [  246.755950]  ? wake_page_function+0xa0/0xa0
    [  246.755961]  ? add_to_page_cache_lru+0x160/0x160
    [  246.755972]  ? page_cache_tree_insert+0x170/0x170
    [  246.755983]  ? __lru_cache_add+0x96/0xb0
    [  246.756086]  __filemap_fdatawait_range+0x14f/0x1c0
    [  246.756097]  ? wait_on_page_bit_common+0x240/0x240
    [  246.756120]  ? __wake_up_locked_key_bookmark+0x20/0x20
    [  246.756167]  ? wait_on_all_pages_writeback+0xc9/0x100
    [  246.756179]  ? __remove_ino_entry+0x120/0x120
    [  246.756192]  ? wait_woken+0x100/0x100
    [  246.756204]  filemap_fdatawait_range+0x9/0x20
    [  246.756216]  write_checkpoint+0x18a1/0x1f00
    [  246.756254]  ? blk_get_request+0x10/0x10
    [  246.756265]  ? cpumask_next_and+0x43/0x60
    [  246.756279]  ? f2fs_sync_inode_meta+0x160/0x160
    [  246.756289]  ? remove_element.isra.4+0xa0/0xa0
    [  246.756300]  ? __put_compound_page+0x40/0x40
    [  246.756310]  ? f2fs_sync_fs+0xec/0x1c0
    [  246.756320]  ? f2fs_sync_fs+0x120/0x1c0
    [  246.756329]  f2fs_sync_fs+0x120/0x1c0
    [  246.756357]  ? trace_event_raw_event_f2fs__page+0x260/0x260
    [  246.756393]  ? ata_build_rw_tf+0x173/0x410
    [  246.756397]  f2fs_balance_fs_bg+0x198/0x390
    [  246.756405]  ? drop_inmem_page+0x230/0x230
    [  246.756415]  ? ahci_qc_prep+0x1bb/0x2e0
    [  246.756418]  ? ahci_qc_issue+0x1df/0x290
    [  246.756422]  ? __accumulate_pelt_segments+0x42/0xd0
    [  246.756426]  ? f2fs_write_node_pages+0xd1/0x380
    [  246.756429]  f2fs_write_node_pages+0xd1/0x380
    [  246.756437]  ? sync_node_pages+0x8f0/0x8f0
    [  246.756440]  ? update_curr+0x53/0x220
    [  246.756444]  ? __accumulate_pelt_segments+0xa2/0xd0
    [  246.756448]  ? __update_load_avg_se.isra.39+0x349/0x360
    [  246.756452]  ? do_writepages+0x2a/0xa0
    [  246.756456]  do_writepages+0x2a/0xa0
    [  246.756460]  __writeback_single_inode+0x70/0x490
    [  246.756463]  ? check_preempt_wakeup+0x199/0x310
    [  246.756467]  writeback_sb_inodes+0x2a2/0x660
    [  246.756471]  ? is_empty_dir_inode+0x40/0x40
    [  246.756474]  ? __writeback_single_inode+0x490/0x490
    [  246.756477]  ? string+0xbf/0xf0
    [  246.756480]  ? down_read_trylock+0x35/0x60
    [  246.756484]  __writeback_inodes_wb+0x9f/0xf0
    [  246.756488]  wb_writeback+0x41d/0x4b0
    [  246.756492]  ? writeback_inodes_wb.constprop.55+0x150/0x150
    [  246.756498]  ? set_worker_desc+0xf7/0x130
    [  246.756502]  ? current_is_workqueue_rescuer+0x60/0x60
    [  246.756511]  ? _find_next_bit+0x2c/0xa0
    [  246.756514]  ? wb_workfn+0x400/0x5d0
    [  246.756518]  wb_workfn+0x400/0x5d0
    [  246.756521]  ? finish_task_switch+0xdf/0x2a0
    [  246.756525]  ? inode_wait_for_writeback+0x30/0x30
    [  246.756529]  process_one_work+0x3a7/0x6f0
    [  246.756533]  worker_thread+0x82/0x750
    [  246.756537]  kthread+0x16f/0x1c0
    [  246.756541]  ? trace_event_raw_event_workqueue_work+0x110/0x110
    [  246.756544]  ? kthread_create_worker_on_cpu+0xb0/0xb0
    [  246.756548]  ret_from_fork+0x1f/0x30
    
    Signed-off-by: Sheng Yong <shengyong1@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 889177d172d3a1879742cdd17debbbeb300ca1b5
Author: Parav Pandit <parav@mellanox.com>
Date:   Tue Jan 9 15:58:54 2018 +0200

    RDMA/cma: Check existence of netdevice during port validation
    
    
    [ Upstream commit 00db63c128dd3daf38f481371976c24d32678142 ]
    
    If valid netdevice is not found for RoCE, GID table should not be
    searched with NULL netdevice.
    
    Doing so causes the search routines to ignore the netdev argument and may
    match the wrong GID table entry if the netdev is deleted.
    
    Fixes: abae1b71dd37 ("IB/cma: cma_validate_port should verify the port and netdevice")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Reviewed-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    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 48b8839d91a49cde35ddab422a99ef908391aeee
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Tue Jan 9 18:36:25 2018 -0700

    Btrfs: raid56: fix race between merge_bio and rbio_orig_end_io
    
    
    [ Upstream commit 7583d8d088ff2c323b1d4f15b191ca2c23d32558 ]
    
    Before rbio_orig_end_io() goes to free rbio, rbio may get merged with
    more bios from other rbios and rbio->bio_list becomes non-empty,
    in that case, these newly merged bios don't end properly.
    
    Once unlock_stripe() is done, rbio->bio_list will not be updated any
    more and we can call bio_endio() on all queued bios.
    
    It should only happen in error-out cases, the normal path of recover
    and full stripe write have already set RBIO_RMW_LOCKED_BIT to disable
    merge before doing IO, so rbio_orig_end_io() called by them doesn't
    have the above issue.
    
    Reported-by: Jérôme Carretero <cJ-ko@zougloub.eu>
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    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 ebe064401f078ae68f2532833ad8f212b6ee2be2
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Fri Jan 5 12:51:09 2018 -0700

    Btrfs: fix unexpected EEXIST from btrfs_get_extent
    
    
    [ Upstream commit 18e83ac75bfe67009c4ddcdd581bba8eb16f4030 ]
    
    This fixes a corner case that is caused by a race of dio write vs dio
    read/write.
    
    Here is how the race could happen.
    
    Suppose that no extent map has been loaded into memory yet.
    There is a file extent [0, 32K), two jobs are running concurrently
    against it, t1 is doing dio write to [8K, 32K) and t2 is doing dio
    read from [0, 4K) or [4K, 8K).
    
    t1 goes ahead of t2 and splits em [0, 32K) to em [0K, 8K) and [8K 32K).
    
    ------------------------------------------------------
                 t1                                t2
          btrfs_get_blocks_direct()         btrfs_get_blocks_direct()
           -> btrfs_get_extent()              -> btrfs_get_extent()
               -> lookup_extent_mapping()
               -> add_extent_mapping()            -> lookup_extent_mapping()
                  # load [0, 32K)
           -> btrfs_new_extent_direct()
               -> btrfs_drop_extent_cache()
                  # split [0, 32K) and
                  # drop [8K, 32K)
               -> add_extent_mapping()
                  # add [8K, 32K)
                                                  -> add_extent_mapping()
                                                     # handle -EEXIST when adding
                                                     # [0, 32K)
    ------------------------------------------------------
    About how t2(dio read/write) runs into -EEXIST:
    
    a) add_extent_mapping() gets -EEXIST for adding em [0, 32k),
    
    b) search_extent_mapping() then returns [0, 8k) as the existing em,
       even though start == existing->start, em is [0, 32k) so that
       extent_map_end(em) > extent_map_end(existing), i.e. 32k > 8k,
    
    c) then it goes thru merge_extent_mapping() which tries to add a [8k, 8k)
       (with a length 0) and returns -EEXIST as [8k, 32k) is already in tree,
    
    d) so btrfs_get_extent() ends up returning -EEXIST to dio read/write,
       which is confusing applications.
    
    Here I conclude all the possible situations,
    1) start < existing->start
    
                +-----------+em+-----------+
    +--prev---+ |     +-------------+      |
    |         | |     |             |      |
    +---------+ +     +---+existing++      ++
                    +
                    |
                    +
                 start
    
    2) start == existing->start
    
          +------------em------------+
          |     +-------------+      |
          |     |             |      |
          +     +----existing-+      +
                |
                |
                +
             start
    
    3) start > existing->start && start < (existing->start + existing->len)
    
          +------------em------------+
          |     +-------------+      |
          |     |             |      |
          +     +----existing-+      +
                   |
                   |
                   +
                 start
    
    4) start >= (existing->start + existing->len)
    
    +-----------+em+-----------+
    |     +-------------+      | +--next---+
    |     |             |      | |         |
    +     +---+existing++      + +---------+
                          +
                          |
                          +
                       start
    
    As we can see, it turns out that if start is within existing em (front
    inclusive), then the existing em should be returned as is, otherwise,
    we try our best to merge candidate em with sibling ems to form a
    larger em (in order to reduce the total number of em).
    
    Reported-by: David Vallender <david.vallender@landmark.co.uk>
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Reviewed-by: Josef Bacik <jbacik@fb.com>
    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 c231cec825a9d72642b712b6b62bb9c99b7407fd
Author: Anand Jain <Anand.Jain@oracle.com>
Date:   Tue Jan 9 09:05:43 2018 +0800

    btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP
    
    
    [ Upstream commit 6f794e3c5c8f8fdd3b5bb20d9ded894e685b5bbe ]
    
    It appears from the original commit [1] that there isn't any design
    specific reason not to fail the mount instead of just warning. This
    patch will change it to fail.
    
    [1]
     commit 319e4d0661e5323c9f9945f0f8fb5905e5fe74c3
        btrfs: Enhance super validation check
    
    Fixes: 319e4d0661e5323 ("btrfs: Enhance super validation check")
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d91bb7c6988bd6450284c762b33f2e1ea3fe7c97
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Tue Jan 2 13:36:41 2018 -0700

    Btrfs: fix scrub to repair raid6 corruption
    
    
    [ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]
    
    The raid6 corruption is that,
    suppose that all disks can be read without problems and if the content
    that was read out doesn't match its checksum, currently for raid6
    btrfs at most retries twice,
    
    - the 1st retry is to rebuild with all other stripes, it'll eventually
      be a raid5 xor rebuild,
    - if the 1st fails, the 2nd retry will deliberately fail parity p so
      that it will do raid6 style rebuild,
    
    however, the chances are that another non-parity stripe content also
    has something corrupted, so that the above retries are not able to
    return correct content.
    
    We've fixed normal reads to rebuild raid6 correctly with more retries
    in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix
    scrub to do the exactly same rebuild process.
    
    [1]: https://patchwork.kernel.org/patch/10091755/
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    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 db6d651eccded6fe512f0ed02347e0638dd95296
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Tue Dec 12 11:14:49 2017 +0200

    btrfs: Fix out of bounds access in btrfs_search_slot
    
    
    [ Upstream commit 9ea2c7c9da13c9073e371c046cbbc45481ecb459 ]
    
    When modifying a tree where the root is at BTRFS_MAX_LEVEL - 1 then
    the level variable is going to be 7 (this is the max height of the
    tree). On the other hand btrfs_cow_block is always called with
    "level + 1" as an index into the nodes and slots arrays. This leads to
    an out of bounds access. Admittdely this will be benign since an OOB
    access of the nodes array will likely read the 0th element from the
    slots array, which in this case is going to be 0 (since we start CoW at
    the top of the tree). The OOB access into the slots array in turn will
    read the 0th and 1st values of the locks array, which would both be 0
    at the time. However, this benign behavior relies on the fact that the
    path being passed hasn't been initialised, if it has already been used to
    query a btree then it could potentially have populated the nodes/slots arrays.
    
    Fix it by explicitly checking if we are at level 7 (the maximum allowed
    index in nodes/slots arrays) and explicitly call the CoW routine with
    NULL for parent's node/slot.
    
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Fixes-coverity-id: 711515
    Reviewed-by: David Sterba <dsterba@suse.com>
    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 a4909c8518f79875e06d4903d249f2524126c2cd
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Wed Nov 15 16:10:28 2017 -0700

    Btrfs: set plug for fsync
    
    
    [ Upstream commit 343e4fc1c60971b0734de26dbbd475d433950982 ]
    
    Setting plug can merge adjacent IOs before dispatching IOs to the disk
    driver.
    
    Without plug, it'd not be a problem for single disk usecases, but for
    multiple disks using raid profile, a large IO can be split to several
    IOs of stripe length, and plug can be helpful to bring them together
    for each disk so that we can save several disk access.
    
    Moreover, fsync issues synchronous writes, so plug can really take
    effect.
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    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 fb5d97a19fc39d9fd5238af989a45cc56b4c2b9a
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Thu Jan 18 01:43:19 2018 +0000

    ipmi/powernv: Fix error return code in ipmi_powernv_probe()
    
    
    [ Upstream commit e749d328b0b450aa78d562fa26a0cd8872325dd9 ]
    
    Fix to return a negative error code from the request_irq() error
    handling case instead of 0, as done elsewhere in this function.
    
    Fixes: dce143c3381c ("ipmi/powernv: Convert to irq event interface")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afadc440a1cc08895f451b4a9db551a45f2a1a21
Author: weiyongjun (A) <weiyongjun1@huawei.com>
Date:   Thu Jan 18 02:23:34 2018 +0000

    mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()
    
    
    [ Upstream commit 0ddcff49b672239dda94d70d0fcf50317a9f4b51 ]
    
    'hwname' is malloced in hwsim_new_radio_nl() and should be freed
    before leaving from the error handling cases, otherwise it will cause
    memory leak.
    
    Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Reviewed-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    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 18004e6f26ec406ee762fd3f8cceaf4ab5acde41
Author: Ulf Magnusson <ulfalizer@gmail.com>
Date:   Sun Oct 8 19:35:45 2017 +0200

    kconfig: Fix expr_free() E_NOT leak
    
    
    [ Upstream commit 5b1374b3b3c2fc4f63a398adfa446fb8eff791a4 ]
    
    Only the E_NOT operand and not the E_NOT node itself was freed, due to
    accidentally returning too early in expr_free(). Outline of leak:
    
            switch (e->type) {
            ...
            case E_NOT:
                    expr_free(e->left.expr);
                    return;
            ...
            }
            *Never reached, 'e' leaked*
            free(e);
    
    Fix by changing the 'return' to a 'break'.
    
    Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
    
            LEAK SUMMARY:
               definitely lost: 44,448 bytes in 1,852 blocks
               ...
    
    Summary after the fix:
    
            LEAK SUMMARY:
               definitely lost: 1,608 bytes in 67 blocks
               ...
    
    Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f511f3dda8c6fb2c799eab22acfb39056047a49
Author: Ulf Magnusson <ulfalizer@gmail.com>
Date:   Sun Oct 8 19:35:44 2017 +0200

    kconfig: Fix automatic menu creation mem leak
    
    
    [ Upstream commit ae7440ef0c8013d68c00dad6900e7cce5311bb1c ]
    
    expr_trans_compare() always allocates and returns a new expression,
    giving the following leak outline:
    
            ...
            *Allocate*
            basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no);
            ...
            for (menu = parent->next; menu; menu = menu->next) {
                    ...
                    *Copy*
                    dep2 = expr_copy(basedep);
                    ...
                    *Free copy*
                    expr_free(dep2);
            }
            *basedep lost!*
    
    Fix by freeing 'basedep' after the loop.
    
    Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
    
            LEAK SUMMARY:
               definitely lost: 344,376 bytes in 14,349 blocks
               ...
    
    Summary after the fix:
    
            LEAK SUMMARY:
               definitely lost: 44,448 bytes in 1,852 blocks
               ...
    
    Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bf116b258c286137635542a752ec68ffebd809b
Author: Ulf Magnusson <ulfalizer@gmail.com>
Date:   Sun Oct 8 19:11:21 2017 +0200

    kconfig: Don't leak main menus during parsing
    
    
    [ Upstream commit 0724a7c32a54e3e50d28e19e30c59014f61d4e2c ]
    
    If a 'mainmenu' entry appeared in the Kconfig files, two things would
    leak:
    
            - The 'struct property' allocated for the default "Linux Kernel
              Configuration" prompt.
    
            - The string for the T_WORD/T_WORD_QUOTE prompt after the
              T_MAINMENU token, allocated on the heap in zconf.l.
    
    To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches
    if there's no 'mainmenu' and adds the default prompt. That means the
    prompt only gets allocated once regardless of whether there's a
    'mainmenu' statement or not, and managing it becomes simple.
    
    Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:
    
            LEAK SUMMARY:
               definitely lost: 344,568 bytes in 14,352 blocks
               ...
    
    Summary after the fix:
    
            LEAK SUMMARY:
               definitely lost: 344,440 bytes in 14,350 blocks
               ...
    
    Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f2df99f9eb020a1fa4fceb460d9a494c3b33341
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Dec 24 13:04:07 2017 -0800

    watchdog: sp5100_tco: Fix watchdog disable bit
    
    
    [ Upstream commit f541c09ebfc61697b586b38c9ebaf4b70defb278 ]
    
    According to all published information, the watchdog disable bit for SB800
    compatible controllers is bit 1 of PM register 0x48, not bit 2. For the
    most part that doesn't matter in practice, since the bit has to be cleared
    to enable watchdog address decoding, which is the default setting, but it
    still needs to be fixed.
    
    Cc: Zoltán Böszörményi <zboszor@pr.hu>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebf5ffca1bf2be571544befa56e37723e8b8356f
Author: Niklas Cassel <niklas.cassel@axis.com>
Date:   Fri Jan 19 10:39:06 2018 +0100

    PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build
    
    
    [ Upstream commit 80db6f08b7af93eddc9487535e6150b220262637 ]
    
    Some hardware can operate in either "host" or "endpoint" mode, which means
    there can be both a host bridge driver and an endpoint driver for the same
    device.  Those drivers share a lot of code, so sometimes they live in the
    same source file.
    
    The host bridge driver requires CONFIG_PCI=y because it enumerates PCI
    devices below the bridge using the PCI core.  The endpoint driver does not
    require CONFIG_PCI=y because it runs in an embedded kernel on the other
    side of the device, e.g., on an adapter card.
    
    pci-dra7xx.c contains both host and endpoint drivers.  If we select only
    the endpoint driver (CONFIG_PCI=n and CONFIG_PCI_DRA7XX_EP=y), the unneeded
    host driver is still compiled.  It references pci_irqd_intx_xlate(), which
    is not present when CONFIG_PCI=n, which causes this error:
    
      drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate' undeclared here (not in a function)
    
    Add a dummy pci_irqd_intx_xlate() for the CONFIG_PCI=n case.
    
    [bhelgaas: changelog]
    Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c212c855a09d826b95eb18d5adf04f4c65ecb8ca
Author: James Hogan <jhogan@kernel.org>
Date:   Tue Jan 16 21:38:24 2018 +0000

    MIPS: Fix clean of vmlinuz.{32,ecoff,bin,srec}
    
    
    [ Upstream commit 5f2483eb2423152445b39f2db59d372f523e664e ]
    
    Make doesn't expand shell style "vmlinuz.{32,ecoff,bin,srec}" to the 4
    separate files, so none of these files get cleaned up by make clean.
    List the files separately instead.
    
    Fixes: ec3352925b74 ("MIPS: Remove all generated vmlinuz* files on "make clean"")
    Signed-off-by: James Hogan <jhogan@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/18491/
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81fbb7e26ea1068d6c7777f5c1f8d4f9b4ec68a9
Author: Jan Chochol <jan@chochol.info>
Date:   Fri Jan 5 08:39:12 2018 +0100

    nfs: Do not convert nfs_idmap_cache_timeout to jiffies
    
    
    [ Upstream commit cbebc6ef4fc830f4040d4140bf53484812d5d5d9 ]
    
    Since commit 57e62324e469 ("NFS: Store the legacy idmapper result in the
    keyring") nfs_idmap_cache_timeout changed units from jiffies to seconds.
    Unfortunately sysctl interface was not updated accordingly.
    
    As a effect updating /proc/sys/fs/nfs/idmap_cache_timeout with some
    value will incorrectly multiply this value by HZ.
    Also reading /proc/sys/fs/nfs/idmap_cache_timeout will show real value
    divided by HZ.
    
    Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
    Signed-off-by: Jan Chochol <jan@chochol.info>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35ceddc59cd4f70343072247fd5b9995d8fceb87
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Sun Jan 14 17:07:50 2018 +0200

    IB/cq: Don't force IB_POLL_DIRECT poll context for ib_process_cq_direct
    
    
    [ Upstream commit 246d8b184c100e8eb6b4e8c88f232c2ed2a4e672 ]
    
    polling the completion queue directly does not interfere
    with the existing polling logic, hence drop the requirement.
    Be aware that running ib_process_cq_direct with non IB_POLL_DIRECT
    CQ may trigger concurrent CQ processing.
    
    This can be used for polling mode ULPs.
    
    Cc: Bart Van Assche <bart.vanassche@wdc.com>
    Reported-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    [maxg: added wcs array argument to __ib_process_cq]
    Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58bc0fd8434d510c5e86f6739c9856b695730504
Author: Maxime Chevallier <maxime.chevallier@smile.fr>
Date:   Wed Jan 17 17:15:25 2018 +0100

    spi: a3700: Clear DATA_OUT when performing a read
    
    
    [ Upstream commit 44a5f423e70374e5b42cecd85e78f2d79334e0f2 ]
    
    When performing a read using FIFO mode, the spi controller shifts out
    the last 2 bytes that were written in a previous transfer on MOSI.
    
    This undocumented behaviour can cause devices to misinterpret the
    transfer, so we explicitly clear the WFIFO before each read.
    
    This behaviour was noticed on EspressoBin.
    
    Signed-off-by: Maxime Chevallier <maxime.chevallier@smile.fr>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bb5b9c68192b81e16eef1b7f9d4d526fe6afefe
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Mon Jan 15 18:10:15 2018 +0100

    net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
    
    
    [ Upstream commit fb7d38a70e1d8ffd54f7a7464dcc4889d7e490ad ]
    
    On Meson8b the only valid input clock is MPLL2. The bootloader
    configures that to run at 500002394Hz which cannot be divided evenly
    down to 125MHz using the m250_div clock. Currently the common clock
    framework chooses a m250_div of 2 - with the internal fixed
    "divide by 10" this results in a RGMII TX clock of 125001197Hz (120Hz
    above the requested 125MHz).
    
    Letting the common clock framework propagate the rate changes up to the
    parent of m250_mux allows us to get the best possible clock rate. With
    this patch the common clock framework calculates a rate of
    very-close-to-250MHz (249999701Hz to be exact) for the MPLL2 clock
    (which is the mux input). Dividing that by 2 (which is an internal,
    fixed divider for the RGMII TX clock) gives us an RGMII TX clock of
    124999850Hz (which is only 150Hz off the requested 125MHz, compared to
    1197Hz based on the MPLL2 rate set by u-boot and the Amlogic GPL kernel
    sources).
    
    SoCs from the Meson GX series are not affected by this change because
    the input clock is FCLK_DIV2 whose rate cannot be changed (which is fine
    since it's running at 1GHz, so it's already a multiple of 250MHz and
    125MHz).
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Suggested-by: Jerome Brunet <jbrunet@baylibre.com>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Tested-by: Jerome Brunet <jbrunet@baylibre.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 5bfa11c9619283d77cf8193152fba8ae18819557
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Mon Jan 15 18:10:14 2018 +0100

    net: stmmac: dwmac-meson8b: fix setting the RGMII TX clock on Meson8b
    
    
    [ Upstream commit 433c6cab9d298687c097f6ee82e49157044dc7c6 ]
    
    Meson8b only supports MPLL2 as clock input. The rate of the MPLL2 clock
    set by Odroid-C1's u-boot is close to (but not exactly) 500MHz. The
    exact rate is 500002394Hz, which is calculated in
    drivers/clk/meson/clk-mpll.c using the following formula:
    DIV_ROUND_UP_ULL((u64)parent_rate * SDM_DEN, (SDM_DEN * n2) + sdm)
    Odroid-C1's u-boot configures MPLL2 with the following values:
    - SDM_DEN = 16384
    - SDM = 1638
    - N2 = 5
    
    The 250MHz clock (m250_div) inside dwmac-meson8b driver is derived from
    the MPLL2 clock. Due to MPLL2 running slightly faster than 500MHz the
    common clock framework chooses a divider which is too big to generate
    the 250MHz clock (a divider of 2 would be needed, but this is rounded up
    to a divider of 3). This breaks the RTL8211F RGMII PHY on Odroid-C1
    because it requires a (close to) 125MHz RGMII TX clock (on Gbit speeds,
    the IP block internally divides that down to 25MHz on 100Mbit/s
    connections and 2.5MHz on 10Mbit/s connections - we don't need any
    special configuration for that).
    
    Round the divider to the closest value to prevent this issue on Meson8b.
    This means we'll now end up with a clock rate for the RGMII TX clock of
    125001197Hz (= 125MHz plus 1197Hz), which is close-enough to 125MHz.
    This has no effect on the Meson GX SoCs since there fclk_div2 is used as
    input clock, which has a rate of 1000MHz (and thus is divisible cleanly
    to 250MHz and 125MHz).
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Reported-by: Emiliano Ingrassia <ingrassia@epigenesys.com>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Tested-by: Jerome Brunet <jbrunet@baylibre.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 2a71a742f09b390a200110dd3d8ff9f6f51f9443
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Sun Sep 17 10:32:20 2017 +0200

    ubifs: Fix uninitialized variable in search_dh_cookie()
    
    
    [ Upstream commit c877154d307f4a91e0b5b85b75535713dab945ae ]
    
    fs/ubifs/tnc.c: In function ‘search_dh_cookie’:
    fs/ubifs/tnc.c:1893: warning: ‘err’ is used uninitialized in this function
    
    Indeed, err is always used uninitialized.
    
    According to an original review comment from Hyunchul, acknowledged by
    Richard, err should be initialized to -ENOENT to avoid the first call to
    tnc_next().  But we can achieve the same by reordering the code.
    
    Fixes: 781f675e2d7e ("ubifs: Fix unlink code wrt. double hash lookups")
    Reported-by: Hyunchul Lee <hyc.lee@gmail.com>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1dfcb01e374729f6920c3c07867914c5e848fb4
Author: Ming Lei <ming.lei@redhat.com>
Date:   Thu Jan 18 00:41:52 2018 +0800

    blk-mq: turn WARN_ON in __blk_mq_run_hw_queue into printk
    
    
    [ Upstream commit 7df938fbc4ee641e70e05002ac67c24b19e86e74 ]
    
    We know this WARN_ON is harmless and in reality it may be trigged,
    so convert it to printk() and dump_stack() to avoid to confusing
    people.
    
    Also add comment about two releated races here.
    
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: Stefan Haberland <sth@linux.vnet.ibm.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: "jianchao.wang" <jianchao.w.wang@oracle.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e102fe86ede237ca875da9336648caa5e2fcac6
Author: Ming Lei <ming.lei@redhat.com>
Date:   Thu Jan 11 14:01:56 2018 +0800

    dm mpath: return DM_MAPIO_REQUEUE on blk-mq rq allocation failure
    
    
    [ Upstream commit 050af08ffb1b62af69196d61c22a0755f9a3cdbd ]
    
    blk-mq will rerun queue via RESTART or dispatch wake after one request
    is completed, so not necessary to wait random time for requeuing, we
    should trust blk-mq to do it.
    
    More importantly, we need to return BLK_STS_RESOURCE to blk-mq so that
    dequeuing from the I/O scheduler can be stopped, this results in
    improved I/O merging.
    
    Signed-off-by: Ming Lei <ming.lei@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 223ed638e937c53fdb49c6a55aa3c9de2c728b0f
Author: mulhern <amulhern@redhat.com>
Date:   Mon Nov 27 10:02:39 2017 -0500

    dm thin: fix documentation relative to low water mark threshold
    
    
    [ Upstream commit 9b28a1102efc75d81298198166ead87d643a29ce ]
    
    Fixes:
    1. The use of "exceeds" when the opposite of exceeds, falls below,
    was meant.
    2. Properly speaking, a table can not exceed a threshold.
    
    It emphasizes the important point, which is that it is the userspace
    daemon's responsibility to check for low free space when a device
    is resumed, since it won't get a special event indicating low free
    space in that situation.
    
    Signed-off-by: mulhern <amulhern@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 e9c8a5fa078ca85b4a78dfbe837fadfef780608d
Author: Peter Xu <peterx@redhat.com>
Date:   Wed Jan 10 13:51:37 2018 +0800

    iommu/vt-d: Use domain instead of cache fetching
    
    
    [ Upstream commit 9d2e6505f6d6934e681aed502f566198cb25c74a ]
    
    after commit a1ddcbe93010 ("iommu/vt-d: Pass dmar_domain directly into
    iommu_flush_iotlb_psi", 2015-08-12), we have domain pointer as parameter
    to iommu_flush_iotlb_psi(), so no need to fetch it from cache again.
    
    More importantly, a NULL reference pointer bug is reported on RHEL7 (and
    it can be reproduced on some old upstream kernels too, e.g., v4.13) by
    unplugging an 40g nic from a VM (hard to test unplug on real host, but
    it should be the same):
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1531367
    
    [   24.391863] pciehp 0000:00:03.0:pcie004: Slot(0): Attention button pressed
    [   24.393442] pciehp 0000:00:03.0:pcie004: Slot(0): Powering off due to button press
    [   29.721068] i40evf 0000:01:00.0: Unable to send opcode 2 to PF, err I40E_ERR_QUEUE_EMPTY, aq_err OK
    [   29.783557] iommu: Removing device 0000:01:00.0 from group 3
    [   29.784662] BUG: unable to handle kernel NULL pointer dereference at 0000000000000304
    [   29.785817] IP: iommu_flush_iotlb_psi+0xcf/0x120
    [   29.786486] PGD 0
    [   29.786487] P4D 0
    [   29.786812]
    [   29.787390] Oops: 0000 [#1] SMP
    [   29.787876] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_ng
    [   29.795371] CPU: 0 PID: 156 Comm: kworker/0:2 Not tainted 4.13.0 #14
    [   29.796366] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.11.0-1.el7 04/01/2014
    [   29.797593] Workqueue: pciehp-0 pciehp_power_thread
    [   29.798328] task: ffff94f5745b4a00 task.stack: ffffb326805ac000
    [   29.799178] RIP: 0010:iommu_flush_iotlb_psi+0xcf/0x120
    [   29.799919] RSP: 0018:ffffb326805afbd0 EFLAGS: 00010086
    [   29.800666] RAX: ffff94f5bc56e800 RBX: 0000000000000000 RCX: 0000000200000025
    [   29.801667] RDX: ffff94f5bc56e000 RSI: 0000000000000082 RDI: 0000000000000000
    [   29.802755] RBP: ffffb326805afbf8 R08: 0000000000000000 R09: ffff94f5bc86bbf0
    [   29.803772] R10: ffffb326805afba8 R11: 00000000000ffdc4 R12: ffff94f5bc86a400
    [   29.804789] R13: 0000000000000000 R14: 00000000ffdc4000 R15: 0000000000000000
    [   29.805792] FS:  0000000000000000(0000) GS:ffff94f5bfc00000(0000) knlGS:0000000000000000
    [   29.806923] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   29.807736] CR2: 0000000000000304 CR3: 000000003499d000 CR4: 00000000000006f0
    [   29.808747] Call Trace:
    [   29.809156]  flush_unmaps_timeout+0x126/0x1c0
    [   29.809800]  domain_exit+0xd6/0x100
    [   29.810322]  device_notifier+0x6b/0x70
    [   29.810902]  notifier_call_chain+0x4a/0x70
    [   29.812822]  __blocking_notifier_call_chain+0x47/0x60
    [   29.814499]  blocking_notifier_call_chain+0x16/0x20
    [   29.816137]  device_del+0x233/0x320
    [   29.817588]  pci_remove_bus_device+0x6f/0x110
    [   29.819133]  pci_stop_and_remove_bus_device+0x1a/0x20
    [   29.820817]  pciehp_unconfigure_device+0x7a/0x1d0
    [   29.822434]  pciehp_disable_slot+0x52/0xe0
    [   29.823931]  pciehp_power_thread+0x8a/0xa0
    [   29.825411]  process_one_work+0x18c/0x3a0
    [   29.826875]  worker_thread+0x4e/0x3b0
    [   29.828263]  kthread+0x109/0x140
    [   29.829564]  ? process_one_work+0x3a0/0x3a0
    [   29.831081]  ? kthread_park+0x60/0x60
    [   29.832464]  ret_from_fork+0x25/0x30
    [   29.833794] Code: 85 ed 74 0b 5b 41 5c 41 5d 41 5e 41 5f 5d c3 49 8b 54 24 60 44 89 f8 0f b6 c4 48 8b 04 c2 48 85 c0 74 49 45 0f b6 ff 4a 8b 3c f8 <80> bf
    [   29.838514] RIP: iommu_flush_iotlb_psi+0xcf/0x120 RSP: ffffb326805afbd0
    [   29.840362] CR2: 0000000000000304
    [   29.841716] ---[ end trace b10ec0d6900868d3 ]---
    
    This patch fixes that problem if applied to v4.13 kernel.
    
    The bug does not exist on latest upstream kernel since it's fixed as a
    side effect of commit 13cf01744608 ("iommu/vt-d: Make use of iova
    deferred flushing", 2017-08-15).  But IMHO it's still good to have this
    patch upstream.
    
    CC: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Fixes: a1ddcbe93010 ("iommu/vt-d: Pass dmar_domain directly into iommu_flush_iotlb_psi")
    Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ec6bd8ec2e363f7955a992d97038b7fbed4974b
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Sun Dec 24 02:49:22 2017 +1000

    powerpc: System reset avoid interleaving oops using die synchronisation
    
    
    [ Upstream commit 4552d128c26e0f0f27a5bd2fadc24092b8f6c1d7 ]
    
    The die() oops path contains a serializing lock to prevent oops
    messages from being interleaved. In the case of a system reset
    initiated oops (e.g., qemu nmi command), __die was being called
    which lacks that synchronisation and oops reports could be
    interleaved across CPUs.
    
    A recent patch 4388c9b3a6ee7 ("powerpc: Do not send system reset
    request through the oops path") changed this to __die to avoid
    the debugger() call, but there is no real harm to calling it twice
    if the first time fell through. So go back to using die() here.
    This was observed to fix the problem.
    
    Fixes: 4388c9b3a6ee7 ("powerpc: Do not send system reset request through the oops path")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc5fddf315f8a1664754bac4ef3752f4bc553e44
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Tue Jan 9 15:34:07 2018 +0000

    iommu/exynos: Don't unconditionally steal bus ops
    
    
    [ Upstream commit dc98b8480d8a68c2ce9aa28b9f0d714fd258bc0b ]
    
    Removing the early device registration hook overlooked the fact that
    it only ran conditionally on a compatible device being present in the
    DT. With exynos_iommu_init() now running as an unconditional initcall,
    problems arise on non-Exynos systems when other IOMMU drivers find
    themselves unable to install their ops on the platform bus, or at worst
    the Exynos ops get called with someone else's domain and all hell breaks
    loose.
    
    The global ops/cache setup could probably all now be triggered from the
    first IOMMU probe, as with dma_dev assigment, but for the time being the
    simplest fix is to resurrect the logic from commit a7b67cd5d9af
    ("iommu/exynos: Play nice in multi-platform builds") to explicitly check
    the DT for the presence of an Exynos IOMMU before trying anything.
    
    Fixes: 928055a01b3f ("iommu/exynos: Remove custom platform device registration code")
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77d17d0e8934b65864051d74b099f04420066689
Author: Thomas Richter <tmricht@linux.vnet.ibm.com>
Date:   Wed Jan 17 14:16:11 2018 +0100

    perf record: Fix failed memory allocation for get_cpuid_str
    
    
    [ Upstream commit 81fccd6ca507d3b2012eaf1edeb9b1dbf4bd22db ]
    
    In x86 architecture dependend part function get_cpuid_str() mallocs a
    128 byte buffer, but does not check if the memory allocation succeeded
    or not.
    
    When the memory allocation fails, function __get_cpuid() is called with
    first parameter being a NULL pointer.  However this function references
    its first parameter and operates on a NULL pointer which might cause
    core dumps.
    
    Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Link: http://lkml.kernel.org/r/20180117131611.34319-1-tmricht@linux.vnet.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 1fe5e88c389a2f7bda893ed57aa0f3fff52b82b0
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Jan 11 19:47:51 2018 -0500

    tools lib traceevent: Fix get_field_str() for dynamic strings
    
    
    [ Upstream commit d777f8de99b05d399c0e4e51cdce016f26bd971b ]
    
    If a field is a dynamic string, get_field_str() returned just the
    offset/size value and not the string. Have it parse the offset/size
    correctly to return the actual string. Otherwise filtering fails when
    trying to filter fields that are dynamic strings.
    
    Reported-by: Gopanapalli Pradeep <prap_hai@yahoo.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20180112004823.146333275@goodmis.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 4e63115b6b9d040c153a9d4b53cd783e0ce9ae76
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Jan 15 11:07:58 2018 -0300

    perf callchain: Fix attr.sample_max_stack setting
    
    
    [ Upstream commit 249d98e567e25dd03e015e2d31e1b7b9648f34df ]
    
    When setting the "dwarf" unwinder for a specific event and not
    specifying the max-stack, the attr.sample_max_stack ended up using an
    uninitialized callchain_param.max_stack, fix it by using designated
    initializers for that callchain_param variable, zeroing all non
    explicitely initialized struct members.
    
    Here is what happened:
    
      # perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
      callchain: type DWARF
      callchain: stack dump size 8192
      perf_event_attr:
        type                             2
        size                             112
        config                           0x730
        { sample_period, sample_freq }   1
        sample_type                      IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
        exclude_callchain_user           1
        { wakeup_events, wakeup_watermark } 1
        sample_regs_user                 0xff0fff
        sample_stack_user                8192
        sample_max_stack                 50656
      sys_perf_event_open failed, error -75
      Value too large for defined data type
      # perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
      callchain: type DWARF
      callchain: stack dump size 8192
      perf_event_attr:
        type                             2
        size                             112
        config                           0x730
        sample_type                      IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
        exclude_callchain_user           1
        sample_regs_user                 0xff0fff
        sample_stack_user                8192
        sample_max_stack                 30448
      sys_perf_event_open failed, error -75
      Value too large for defined data type
      #
    
    Now the attr.sample_max_stack is set to zero and the above works as
    expected:
    
      # perf trace --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
      PING ::1(::1) 56 data bytes
      64 bytes from ::1: icmp_seq=1 ttl=64 time=0.072 ms
    
      --- ::1 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms
           0.000 probe_libc:inet_pton:(7feb7a998350))
                                             __inet_pton (inlined)
                                             gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                             __GI_getaddrinfo (inlined)
                                             [0xffffaa39b6108f3f] (/usr/bin/ping)
      #
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Link: https://lkml.kernel.org/n/tip-is9tramondqa9jlxxsgcm9iz@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 448bcd67b4c51bd7e4ac3a6d4a1b49e880c5bb5a
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Jan 11 19:47:45 2018 -0500

    tools lib traceevent: Simplify pointer print logic and fix %pF
    
    
    [ Upstream commit 38d70b7ca1769f26c0b79f3c08ff2cc949712b59 ]
    
    When processing %pX in pretty_print(), simplify the logic slightly by
    incrementing the ptr to the format string if isalnum(ptr[1]) is true.
    This follows the logic a bit more closely to what is in the kernel.
    
    Also, this fixes a small bug where %pF was not giving the offset of the
    function.
    
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20180112004822.260262257@goodmis.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 0eda4d03ef4c4c707a3f40c5afe634238775ff8a
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Jan 15 16:48:46 2018 -0300

    perf unwind: Do not look just at the global callchain_param.record_mode
    
    
    [ Upstream commit eabad8c6856f185f876b54c426c2cc69fe0f0a7d ]
    
    When setting up DWARF callchains on specific events, without using
    'record' or 'trace' --call-graph, but instead doing it like:
    
            perf trace -e cycles/call-graph=dwarf/
    
    The unwind__prepare_access() call in thread__insert_map() when we
    process PERF_RECORD_MMAP(2) metadata events were not being performed,
    precluding us from using per-event DWARF callchains, handling them just
    when we asked for all events to be DWARF, using "--call-graph dwarf".
    
    We do it in the PERF_RECORD_MMAP because we have to look at one of the
    executable maps to figure out the executable type (64-bit, 32-bit) of
    the DSO laid out in that mmap. Also to look at the architecture where
    the perf.data file was recorded.
    
    All this probably should be deferred to when we process a sample for
    some thread that has callchains, so that we do this processing only for
    the threads with samples, not for all of them.
    
    For now, fix using DWARF on specific events.
    
    Before:
    
      # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
      PING ::1(::1) 56 data bytes
      64 bytes from ::1: icmp_seq=1 ttl=64 time=0.048 ms
    
      --- ::1 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 0.048/0.048/0.048/0.000 ms
         0.000 probe_libc:inet_pton:(7fe9597bb350))
      Problem processing probe_libc:inet_pton callchain, skipping...
      #
    
    After:
    
      # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
      PING ::1(::1) 56 data bytes
      64 bytes from ::1: icmp_seq=1 ttl=64 time=0.060 ms
    
      --- ::1 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 0.060/0.060/0.060/0.000 ms
           0.000 probe_libc:inet_pton:(7fd4aa930350))
                                             __inet_pton (inlined)
                                             gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                             __GI_getaddrinfo (inlined)
                                             [0xffffaa804e51af3f] (/usr/bin/ping)
                                             __libc_start_main (/usr/lib64/libc-2.26.so)
                                             [0xffffaa804e51b379] (/usr/bin/ping)
      #
      # perf trace --call-graph=dwarf --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
      PING ::1(::1) 56 data bytes
      64 bytes from ::1: icmp_seq=1 ttl=64 time=0.057 ms
    
      --- ::1 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms
           0.000 probe_libc:inet_pton:(7f9363b9e350))
                                             __inet_pton (inlined)
                                             gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                             __GI_getaddrinfo (inlined)
                                             [0xffffa9e8a14e0f3f] (/usr/bin/ping)
                                             __libc_start_main (/usr/lib64/libc-2.26.so)
                                             [0xffffa9e8a14e1379] (/usr/bin/ping)
      #
      # perf trace --call-graph=fp --no-syscalls -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
      PING ::1(::1) 56 data bytes
      64 bytes from ::1: icmp_seq=1 ttl=64 time=0.077 ms
    
      --- ::1 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 0.077/0.077/0.077/0.000 ms
           0.000 probe_libc:inet_pton:(7f4947e1c350))
                                             __inet_pton (inlined)
                                             gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                             __GI_getaddrinfo (inlined)
                                             [0xffffaa716d88ef3f] (/usr/bin/ping)
                                             __libc_start_main (/usr/lib64/libc-2.26.so)
                                             [0xffffaa716d88f379] (/usr/bin/ping)
      #
      # perf trace --no-syscalls -e probe_libc:inet_pton/call-graph=fp/ ping -6 -c 1 ::1
      PING ::1(::1) 56 data bytes
      64 bytes from ::1: icmp_seq=1 ttl=64 time=0.078 ms
    
      --- ::1 ping statistics ---
      1 packets transmitted, 1 received, 0% packet loss, time 0ms
      rtt min/avg/max/mdev = 0.078/0.078/0.078/0.000 ms
           0.000 probe_libc:inet_pton:(7fa157696350))
                                             __GI___inet_pton (/usr/lib64/libc-2.26.so)
                                             getaddrinfo (/usr/lib64/libc-2.26.so)
                                             [0xffffa9ba39c74f40] (/usr/bin/ping)
      #
    
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Link: https://lkml.kernel.org/r/20180116182650.GE16107@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 f3a7d11834f30d04a67c68dd572493953c088834
Author: himanshu.madhani@cavium.com <himanshu.madhani@cavium.com>
Date:   Mon Jan 15 20:46:48 2018 -0800

    scsi: qla2xxx: Fix warning in qla2x00_async_iocb_timeout()
    
    
    [ Upstream commit 7ac0c332f96bb9688560726f5e80c097ed8de59a ]
    
    This patch fixes following Smatch warning:
    
    drivers/scsi/qla2xxx/qla_init.c:130 qla2x00_async_iocb_timeout() error: we previously assumed 'fcport' could be null (see line 107)
    
    Fixes: 5c25d451163c ("scsi: qla2xxx: Fix NULL pointer access for fcport structure")
    Reported by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
    Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3ce194cae63c2d1749dbfe4c92e1ce7b56e0648
Author: Shiraz Saleem <shiraz.saleem@intel.com>
Date:   Thu Jan 11 18:10:51 2018 -0600

    i40iw: Zero-out consumer key on allocate stag for FMR
    
    
    [ Upstream commit 6376e926af1a8661dd1b2e6d0896e07f84a35844 ]
    
    If the application invalidates the MR before the FMR WR, HW parses the
    consumer key portion of the stag and returns an invalid stag key
    Asynchronous Event (AE) that tears down the QP.
    
    Fix this by zeroing-out the consumer key portion of the allocated stag
    returned to application for FMR.
    
    Fixes: ee855d3b93f3 ("RDMA/i40iw: Add base memory management extensions")
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.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 b3b2ca24d9f7c5c34a073553a983c099a2862119
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Thu Jan 11 18:10:54 2018 -0600

    i40iw: Free IEQ resources
    
    
    [ Upstream commit f20d429511affab6a2a9129f46042f43e6ffe396 ]
    
    The iWARP Exception Queue (IEQ) resources are not freed when a QP is
    destroyed. Fix this by freeing IEQ resources when freeing QP resources.
    
    Fixes: d37498417947 ("i40iw: add files for iwarp interface")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.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 0d5ef8956c84a4d6667d41085755b09ac54266c6
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jan 16 15:20:58 2018 -0800

    Input: synaptics - reset the ABS_X/Y fuzz after initializing MT axes
    
    
    [ Upstream commit 19eb4ed1141bd1096b9bc84ba9c4d03d5830c143 ]
    
    input_mt_init_slots() resets the ABS_X/Y fuzz to 0 and expects the driver
    to call input_mt_report_pointer_emulation(). That is based on the MT
    position bits which are already defuzzed - hence a fuzz of 0.
    
    In the case of synaptics semi-mt devices, we report the ABS_X/Y axes
    manually.  This results in the MT position being defuzzed but the
    single-touch emulation missing that defuzzing.
    
    Work around this by re-initializing the ABS_X/Y axes after the MT axis to
    get the same fuzz value back.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=104533
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d9a46ae3204b0d07ec6a4de00573cf12b0b1822
Author: Jesper Dangaard Brouer <brouer@redhat.com>
Date:   Wed Jan 17 00:20:40 2018 +0100

    libbpf: Makefile set specified permission mode
    
    
    [ Upstream commit 7110d80d53f472956420cd05a6297f49b558b674 ]
    
    The third parameter to do_install was not used by $(INSTALL) command.
    Fix this by only setting the -m option when the third parameter is supplied.
    
    The use of a third parameter was introduced in commit  eb54e522a000 ("bpf:
    install libbpf headers on 'make install'").
    
    Without this change, the header files are install as executables files (755).
    
    Fixes: eb54e522a000 ("bpf: install libbpf headers on 'make install'")
    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d925c308742284e508c984bc820b47a3d5c88397
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Jan 9 13:44:46 2018 -0800

    Input: psmouse - fix Synaptics detection when protocol is disabled
    
    
    [ Upstream commit 2bc4298f59d2f15175bb568e2d356b5912d0cdd9 ]
    
    When Synaptics protocol is disabled, we still need to try and detect the
    hardware, so we can switch to SMBus device if SMbus is detected, or we know
    that it is Synaptics device and reset it properly for the bare PS/2
    protocol.
    
    Fixes: c378b5119eb0 ("Input: psmouse - factor out common protocol probing code")
    Reported-by: Matteo Croce <mcroce@redhat.com>
    Tested-by: Matteo Croce <mcroce@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03fdc4ef7a67217506d48e1fcd2a03ab9c1f74bb
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Jan 16 10:05:26 2018 -0700

    PCI: Add function 1 DMA alias quirk for Marvell 9128
    
    
    [ Upstream commit aa008206634363ef800fbd5f0262016c9ff81dea ]
    
    The Marvell 9128 is the original device generating bug 42679, from which
    many other Marvell DMA alias quirks have been sourced, but we didn't have
    positive confirmation of the fix on 9128 until now.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
    Link: https://www.spinics.net/lists/kvm/msg161459.html
    Reported-by: Binarus <lists@binarus.de>
    Tested-by: Binarus <lists@binarus.de>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c45ab4fb384cb3fc05e0949ca3a6ca4d6f7613fb
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Sun Jan 14 22:50:07 2018 +0900

    selftest: ftrace: Fix to pick text symbols for kprobes
    
    
    [ Upstream commit 5e46664703b364434a2cbda3e6988fc24ae0ced5 ]
    
    Fix to pick text symbols for multiple kprobe testcase.
    kallsyms shows text symbols with " t " or " T " but
    current testcase picks all symbols including "t",
    so it picks data symbols if it includes 't' (e.g. "str").
    
    This fixes it to find symbol lines with " t " or " T "
    (including spaces).
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Reported-by: Russell King <linux@armlinux.org.uk>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 342d9092a50184b4b6d1c3f1f6bed06321afa88d
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Dec 14 20:56:09 2017 -0500

    xprtrdma: Fix backchannel allocation of extra rpcrdma_reps
    
    
    [ Upstream commit d698c4a02ee02053bbebe051322ff427a2dad56a ]
    
    The backchannel code uses rpcrdma_recv_buffer_put to add new reps
    to the free rep list. This also decrements rb_recv_count, which
    spoofs the receive overrun logic in rpcrdma_buffer_get_rep.
    
    Commit 9b06688bc3b9 ("xprtrdma: Fix additional uses of
    spin_lock_irqsave(rb_lock)") replaced the original open-coded
    list_add with a call to rpcrdma_recv_buffer_put(), but then a year
    later, commit 05c974669ece ("xprtrdma: Fix receive buffer
    accounting") added rep accounting to rpcrdma_recv_buffer_put.
    It was an oversight to let the backchannel continue to use this
    function.
    
    The fix this, let's combine the "add to free list" logic with
    rpcrdma_create_rep.
    
    Also, do not allocate RPCRDMA_MAX_BC_REQUESTS rpcrdma_reps in
    rpcrdma_buffer_create and then allocate additional rpcrdma_reps in
    rpcrdma_bc_setup_reps. Allocating the extra reps during backchannel
    set-up is sufficient.
    
    Fixes: 05c974669ece ("xprtrdma: Fix receive buffer accounting")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79f2ced39657f6eb539f70664c355183cf21aa79
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jan 11 15:14:39 2018 +0100

    platform/x86: dell-laptop: Filter out spurious keyboard backlight change events
    
    
    [ Upstream commit 4d6bde512a86c32df3a1f289d2b4cd04b17758d1 ]
    
    On some Dell XPS models WMI events of type 0x0000 reporting a keycode of
    0xe00c get reported when the brightness of the LCD panel changes.
    
    This leads to us reporting false-positive kbd_led change events to
    userspace which in turn leads to the kbd backlight OSD showing when it
    should not.
    
    We already read the current keyboard backlight brightness value when
    reporting events because the led_classdev_notify_brightness_hw_changed
    API requires this. Compare this value to the last known value and filter
    out duplicate events, fixing this.
    
    Note the fixed issue is esp. a problem on XPS models with an ambient light
    sensor and automatic brightness adjustments turned on, this causes the kbd
    backlight OSD to show all the time there.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514969
    Fixes: 9c656b0799 ("platform/x86: dell-*: Call new led hw_changed API ...")
    Acked-by: Pali Rohár <pali.rohar@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80bd91ab9ad853d2f4f769b732fb8a501c90ec9d
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Thu Nov 16 15:12:52 2017 +0100

    KVM: s390: use created_vcpus in more places
    
    
    [ Upstream commit 241e3ec0faf5ab1a0d9b1f6c43eefa919fb9c112 ]
    
    commit a03825bbd0c3 ("KVM: s390: use kvm->created_vcpus") introduced
    kvm->created_vcpus to avoid races with the existing kvm->online_vcpus
    scheme. One place was "forgotten" and one new place was "added".
    Let's fix those.
    
    Reported-by: Halil Pasic <pasic@linux.vnet.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Fixes: 4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
    Fixes: a03825bbd0c3 ("KVM: s390: use kvm->created_vcpus")
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5a8ca753c0c4659287416ce282ba357c30098a8
Author: Anna-Maria Gleixner <anna-maria@linutronix.de>
Date:   Thu Dec 21 11:41:37 2017 +0100

    tracing/hrtimer: Fix tracing bugs by taking all clock bases and modes into account
    
    
    [ Upstream commit 91633eed73a3ac37aaece5c8c1f93a18bae616a9 ]
    
    So far only CLOCK_MONOTONIC and CLOCK_REALTIME were taken into account as
    well as HRTIMER_MODE_ABS/REL in the hrtimer_init tracepoint. The query for
    detecting the ABS or REL timer modes is not valid anymore, it got broken
    by the introduction of HRTIMER_MODE_PINNED.
    
    HRTIMER_MODE_PINNED is not evaluated in the hrtimer_init() call, but for the
    sake of completeness print all given modes.
    
    Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: keescook@chromium.org
    Link: http://lkml.kernel.org/r/20171221104205.7269-9-anna-maria@linutronix.de
    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 e0a1cec3db0a2fcf002fc101a15fcede7551c699
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Fri Jan 12 17:36:27 2018 -0700

    netfilter: ipv6: nf_defrag: Pass on packets to stack per RFC2460
    
    
    [ Upstream commit 83f1999caeb14e15df205e80d210699951733287 ]
    
    ipv6_defrag pulls network headers before fragment header. In case of
    an error, the netfilter layer is currently dropping these packets.
    This results in failure of some IPv6 standards tests which passed on
    older kernels due to the netfilter framework using cloning.
    
    The test case run here is a check for ICMPv6 error message replies
    when some invalid IPv6 fragments are sent. This specific test case is
    listed in https://www.ipv6ready.org/docs/Core_Conformance_Latest.pdf
    in the Extension Header Processing Order section.
    
    A packet with unrecognized option Type 11 is sent and the test expects
    an ICMP error in line with RFC2460 section 4.2 -
    
    11 - discard the packet and, only if the packet's Destination
         Address was not a multicast address, send an ICMP Parameter
         Problem, Code 2, message to the packet's Source Address,
         pointing to the unrecognized Option Type.
    
    Since netfilter layer now drops all invalid IPv6 frag packets, we no
    longer see the ICMP error message and fail the test case.
    
    To fix this, save the transport header. If defrag is unable to process
    the packet due to RFC2460, restore the transport header and allow packet
    to be processed by stack. There is no change for other packet
    processing paths.
    
    Tested by confirming that stack sends an ICMP error when it receives
    these packets. Also tested that fragmented ICMP pings succeed.
    
    v1->v2: Instead of cloning always, save the transport_header and
    restore it in case of this specific error. Update the title and
    commit message accordingly.
    
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    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 ddf09f2a0896bb29f1574d0ef983f42eb8592346
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Fri Jan 12 20:55:20 2018 +1100

    KVM: PPC: Book3S HV: Enable migration of decrementer register
    
    
    [ Upstream commit 5855564c8ab2d9cefca7b2933bd19818eb795e40 ]
    
    This adds a register identifier for use with the one_reg interface
    to allow the decrementer expiry time to be read and written by
    userspace.  The decrementer expiry time is in guest timebase units
    and is equal to the sum of the decrementer and the guest timebase.
    (The expiry time is used rather than the decrementer value itself
    because the expiry time is not constantly changing, though the
    decrementer value is, while the guest vcpu is not running.)
    
    Without this, a guest vcpu migrated to a new host will see its
    decrementer set to some random value.  On POWER8 and earlier, the
    decrementer is 32 bits wide and counts down at 512MHz, so the
    guest vcpu will potentially see no decrementer interrupts for up
    to about 4 seconds, which will lead to a stall.  With POWER9, the
    decrementer is now 56 bits side, so the stall can be much longer
    (up to 2.23 years) and more noticeable.
    
    To help work around the problem in cases where userspace has not been
    updated to migrate the decrementer expiry time, we now set the
    default decrementer expiry at vcpu creation time to the current time
    rather than the maximum possible value.  This should mean an
    immediate decrementer interrupt when a migrated vcpu starts
    running.  In cases where the decrementer is 32 bits wide and more
    than 4 seconds elapse between the creation of the vcpu and when it
    first runs, the decrementer would have wrapped around to positive
    values and there may still be a stall - but this is no worse than
    the current situation.  In the large-decrementer case, we are sure
    to get an immediate decrementer interrupt (assuming the time from
    vcpu creation to first run is less than 2.23 years) and we thus
    avoid a very long stall.
    
    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 b7b27e19e374e12b8bb3d12627242e6c5d69d706
Author: Parav Pandit <parav@mellanox.com>
Date:   Fri Jan 12 07:58:42 2018 +0200

    RDMA/core: Clarify rdma_ah_find_type
    
    
    [ Upstream commit a6532e7139660c103dda181aa5b2c734aa26ed6c ]
    
    iWARP does not use rdma_ah_attr_type, and for this reason we do not have a
    RDMA_AH_ATTR_TYPE_IWARP. rdma_ah_find_type should not even be called on iwarp
    ports and for clarity it shouldn't have a special test for iWarp.
    
    This changes the result from RDMA_AH_ATTR_TYPE_ROCE to RDMA_AH_ATTR_TYPE_IB
    when wrongly called on an iWarp port.
    
    Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    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 8e40eae185f85426d9d6d667f2e55aa721b84e0d
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Oct 26 15:45:47 2017 +0200

    kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl
    
    
    [ Upstream commit 51776043afa415435c7e4636204fbe4f7edc4501 ]
    
    This ioctl is obsolete (it was used by Xenner as far as I know) but
    still let's not break it gratuitously...  Its handler is copying
    directly into struct kvm.  Go through a bounce buffer instead, with
    the added benefit that we can actually do something useful with the
    flags argument---the previous code was exiting with -EINVAL but still
    doing the copy.
    
    This technically is a userspace ABI breakage, but since no one should be
    using the ioctl, it's a good occasion to see if someone actually
    complains.
    
    Cc: kernel-hardening@lists.openwall.com
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f3017fa1540cf5eb6bd6af1f76f76a831c99652
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jan 15 11:08:38 2018 +0300

    ASoC: au1x: Fix timeout tests in au1xac97c_ac97_read()
    
    
    [ Upstream commit 123af9043e93cb6f235207d260d50f832cdb5439 ]
    
    The loop timeout doesn't work because it's a post op and ends with "tmo"
    set to -1.  I changed it from a post-op to a pre-op and I changed the
    initial the starting value from 5 to 6 so we still iterate 5 times.  I
    left the other as it was because it's a large number.
    
    Fixes: b3c70c9ea62a ("ASoC: Alchemy AC97C/I2SC audio support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3222cfc0b58f022a17f5f936b5c5d2df8a3f868
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 15 10:44:35 2018 +0100

    ALSA: hda - Use IS_REACHABLE() for dependency on input
    
    
    [ Upstream commit c469652bb5e8fb715db7d152f46d33b3740c9b87 ]
    
    The commit ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek
    HD-audio codec") introduced the reverse-selection of CONFIG_INPUT for
    Realtek codec in order to avoid the mess with dependency between
    built-in and modules.  Later on, we obtained IS_REACHABLE() macro
    exactly for this kind of problems, and now we can remove th INPUT
    selection in Kconfig and put IS_REACHABLE(INPUT) to the appropriate
    places in the code, so that the driver doesn't need to select other
    subsystem forcibly.
    
    Fixes: ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek HD-audio codec")
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org> # and build-tested
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e7284b34c78a11f04452621b3eb41e1bdb83bff
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Jan 14 21:01:48 2018 +0100

    ACPI / LPSS: Do not instiate platform_dev for devs without MMIO resources
    
    
    [ Upstream commit e1681599345b8466786b6e54a2db2a00a068a3f3 ]
    
    acpi_lpss_create_device() skips handling LPSS devices which do not have
    a mmio resources in their resource list (typically these devices are
    disabled by the firmware). But since the LPSS code does not bind to the
    device, acpi_bus_attach() ends up still creating a platform device for
    it and the regular platform_driver for the ACPI HID still tries to bind
    to it.
    
    This happens e.g. on some boards which do not use the pwm-controller
    and have an empty or invalid resource-table for it. Currently this causes
    these error messages to get logged:
    
    [    3.281966] pwm-lpss 80862288:00: invalid resource
    [    3.287098] pwm-lpss: probe of 80862288:00 failed with error -22
    
    This commit stops the undesirable creation of a platform_device for
    disabled LPSS devices by setting pnp.type.platform_id to 0. Note that
    acpi_scan_attach_handler() also sets pnp.type.platform_id to 0 when there
    is a matching handler for the device and that handler has no attach
    callback, so we simply behave as a handler without an attach function
    in this case.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a420b5d95a5428887dbcbd338ddb36fdbdc9233
Author: NeilBrown <neilb@suse.com>
Date:   Wed Dec 13 09:57:09 2017 +1100

    NFSv4: always set NFS_LOCK_LOST when a lock is lost.
    
    
    [ Upstream commit dce2630c7da73b0634686bca557cc8945cc450c8 ]
    
    There are 2 comments in the NFSv4 code which suggest that
    SIGLOST should possibly be sent to a process.  In these
    cases a lock has been lost.
    The current practice is to set NFS_LOCK_LOST so that
    read/write returns EIO when a lock is lost.
    So change these comments to code when sets NFS_LOCK_LOST.
    
    One case is when lock recovery after apparent server restart
    fails with NFS4ERR_DENIED, NFS4ERR_RECLAIM_BAD, or
    NFS4ERRO_RECLAIM_CONFLICT.  The other case is when a lock
    attempt as part of lease recovery fails with NFS4ERR_DENIED.
    
    In an ideal world, these should not happen.  However I have
    a packet trace showing an NFSv4.1 session getting
    NFS4ERR_BADSESSION after an extended network parition.  The
    NFSv4.1 client treats this like server reboot until/unless
    it get NFS4ERR_NO_GRACE, in which case it switches over to
    "nograce" recovery mode.  In this network trace, the client
    attempts to recover a lock and the server (incorrectly)
    reports NFS4ERR_DENIED rather than NFS4ERR_NO_GRACE.  This
    leads to the ineffective comment and the client then
    continues to write using the OPEN stateid.
    
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 239c948e3266adba944da4ea257362e773f39823
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Dec 22 10:20:11 2017 +0100

    x86/tsc: Allow TSC calibration without PIT
    
    
    [ Upstream commit 30c7e5b123673d5e570e238dbada2fb68a87212c ]
    
    Zhang Rui reported that a Surface Pro 4 will fail to boot with
    lapic=notscdeadline. Part of the problem is that that machine doesn't have
    a PIT.
    
    If, for some reason, the TSC init has to fall back to TSC calibration, it
    relies on the PIT to be present.
    
    Allow TSC calibration to reliably fall back to HPET.
    
    The below results in an accurate TSC measurement when forced on a IVB:
    
      tsc: Unable to calibrate against PIT
      tsc: No reference (HPET/PMTIMER) available
      tsc: Unable to calibrate against PIT
      tsc: using HPET reference calibration
      tsc: Detected 2792.451 MHz processor
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: len.brown@intel.com
    Cc: rui.zhang@intel.com
    Link: https://lkml.kernel.org/r/20171222092243.333145937@infradead.org
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a5d70332d57bd473ffe76d8777a2e9f847c7863
Author: Hector Martin <marcan@marcan.st>
Date:   Fri Nov 3 20:28:57 2017 +0900

    firewire-ohci: work around oversized DMA reads on JMicron controllers
    
    
    [ Upstream commit 188775181bc05f29372b305ef96485840e351fde ]
    
    At least some JMicron controllers issue buggy oversized DMA reads when
    fetching context descriptors, always fetching 0x20 bytes at once for
    descriptors which are only 0x10 bytes long. This is often harmless, but
    can cause page faults on modern systems with IOMMUs:
    
    DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set
    firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read
    
    This works around the problem by always leaving 0x10 padding bytes at
    the end of descriptor buffer pages, which should be harmless to do
    unconditionally for controllers in case others have the same behavior.
    
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Reviewed-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f52b0c642157bafda295c16a4650b4f0c26f4d1
Author: Merlijn Wajer <merlijn@wizzup.org>
Date:   Tue Mar 13 09:48:40 2018 -0500

    usb: musb: Fix external abort in musb_remove on omap2430
    
    commit 94e46a4f2d5eb14059e42f313c098d4854847376 upstream.
    
    This fixes an oops on unbind / module unload (on the musb omap2430
    platform).
    
    musb_remove function now calls musb_platform_exit before disabling
    runtime pm.
    
    Signed-off-by: Merlijn Wajer <merlijn@wizzup.org>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de4c4914cce296b8dd9f5381f5d5dad70a065ba0
Author: Merlijn Wajer <merlijn@wizzup.org>
Date:   Mon Mar 5 11:35:10 2018 -0600

    usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers
    
    commit df6b074dbe248d8c43a82131e8fd429e401841a5 upstream.
    
    Without pm_runtime_{get,put}_sync calls in place, reading
    vbus status via /sys causes the following error:
    
    Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060
    pgd = b333e822
    [fa0ab060] *pgd=48011452(bad)
    
    [<c05261b0>] (musb_default_readb) from [<c0525bd0>] (musb_vbus_show+0x58/0xe4)
    [<c0525bd0>] (musb_vbus_show) from [<c04c0148>] (dev_attr_show+0x20/0x44)
    [<c04c0148>] (dev_attr_show) from [<c0259f74>] (sysfs_kf_seq_show+0x80/0xdc)
    [<c0259f74>] (sysfs_kf_seq_show) from [<c0210bac>] (seq_read+0x250/0x448)
    [<c0210bac>] (seq_read) from [<c01edb40>] (__vfs_read+0x1c/0x118)
    [<c01edb40>] (__vfs_read) from [<c01edccc>] (vfs_read+0x90/0x144)
    [<c01edccc>] (vfs_read) from [<c01ee1d0>] (SyS_read+0x3c/0x74)
    [<c01ee1d0>] (SyS_read) from [<c0106fe0>] (ret_fast_syscall+0x0/0x54)
    
    Solution was suggested by Tony Lindgren <tony@atomide.com>.
    
    Signed-off-by: Merlijn Wajer <merlijn@wizzup.org>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43de32cdf0f4f73519e2df12fb93adc24f9746cb
Author: Andreas Kemnade <andreas@kemnade.info>
Date:   Tue Feb 20 07:30:10 2018 -0600

    usb: musb: fix enumeration after resume
    
    commit 17539f2f4f0b7fa906b508765c8ada07a1e45f52 upstream.
    
    On dm3730 there are enumeration problems after resume.
    Investigation led to the cause that the MUSB_POWER_SOFTCONN
    bit is not set. If it was set before suspend (because it
    was enabled via musb_pullup()), it is set in
    musb_restore_context() so the pullup is enabled. But then
    musb_start() is called which overwrites MUSB_POWER and
    therefore disables MUSB_POWER_SOFTCONN, so no pullup is
    enabled and the device is not enumerated.
    
    So let's do a subset of what musb_start() does
    in the same way as musb_suspend() does it. Platform-specific
    stuff it still called as there might be some phy-related stuff
    which needs to be enabled.
    Also interrupts are enabled, as it was the original idea
    of calling musb_start() in musb_resume() according to
    Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend,
    enable them on resume")
    
    Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
    Tested-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 829239740c129fe9aaf276843fd546bdd45f114e
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Jan 30 16:29:38 2018 +0200

    drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing
    
    commit 5e1df40f40ee45a97bb1066c3d71f0ae920a9672 upstream.
    
    Currently we see sporadic timeouts during CDCLK changing both on BXT and
    GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
    changing the frequency in a tight loop after blanking the display. The
    upper bound for the completion time is 800us based on my tests, so
    increase it from the current 500us to 2ms; with that I couldn't trigger
    the problem either on BXT or GLK.
    
    Note that timeouts happened during both the change notification and the
    voltage level setting PCODE request. (For the latter one BSpec doesn't
    require us to wait for completion before further HW programming.)
    
    This issue is similar to
    commit 2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK
    change notification")
    but there the PCODE request does complete (as shown by the mbox
    busy flag), only the reply we get from PCODE indicates a failure.
    So there we keep resending the request until a success reply, here we
    just have to increase the timeout for the one PCODE request we send.
    
    v2:
    - s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)
    
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: <stable@vger.kernel.org> # v4.4+
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
    (cherry picked from commit e76019a81921e87a4d9e7b3d86102bc708a6c227)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    (Rebased for v4.14 stable tree due to upstream cdclk_state and pcu_lock change)
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c825627d4e5dd1989b44b7c27feba8061084096
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Apr 16 18:53:09 2018 +0300

    drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state
    
    commit 7eb2c4dd54ff841f2fe509a84973eb25fa20bda2 upstream.
    
    LSPCON adapters in low-power state may ignore the first I2C write during
    TMDS output buffer enabling, resulting in a blank screen even with an
    otherwise enabled pipe. Fix this by reading back and validating the
    written value a few times.
    
    The problem was noticed on GLK machines with an onboard LSPCON adapter
    after entering/exiting DC5 power state. Doing an I2C read of the adapter
    ID as the first transaction - instead of the I2C write to enable the
    TMDS buffers - returns the correct value. Based on this we assume that
    the transaction itself is sent properly, it's only the adapter that is
    not ready for some reason to accept this first write after waking from
    low-power state. In my case the second I2C write attempt always
    succeeded.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
    Cc: Clinton Taylor <clinton.a.taylor@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180416155309.11100-1-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6312eff3c70ed43bc0d4a86a042772e4921d649d
Author: Xidong Wang <wangxidong_97@163.com>
Date:   Wed Apr 4 10:38:24 2018 +0100

    drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value
    
    commit fcf1fadf4c65eea6c519c773d2d9901e8ad94f5f upstream.
    
    Along the eb_lookup_vmas() error path, the return value from
    kmem_cache_alloc() was freed using kfree(). Fix it to use the proper
    kmem_cache_free() instead.
    
    Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
    Signed-off-by: Xidong Wang <wangxidong_97@163.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: <stable@vger.kernel.org> # v4.14+
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180404093824.9313-1-chris@chris-wilson.co.uk
    (cherry picked from commit 6be1187dbffa0027ea379c53f7ca0c782515c610)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e0489cf4d098ab4fe1c30941390362fb2843b7c
Author: Gaurav K Singh <gaurav.k.singh@intel.com>
Date:   Tue Apr 17 23:52:18 2018 +0530

    drm/i915/audio: Fix audio detection issue on GLK
    
    commit b4615730530be85fc45ab4631c2ad6d8e2d0b97d upstream.
    
    On Geminilake, sometimes audio card is not getting
    detected after reboot. This is a spurious issue happening on
    Geminilake. HW codec and HD audio controller link was going
    out of sync for which there was a fix in i915 driver but
    was not getting invoked for GLK. Extending this fix to GLK as well.
    
    Tested by Du,Wenkai on GLK board.
    
    Bspec: 21829
    
    v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N)
    
    Cc: <stable@vger.kernel.org> # b651bd2a3ae3 ("drm/i915/audio: Fix audio enumeration issue on BXT")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
    Reviewed-by: Abhay Kumar <abhay.Kumar@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1523989338-29677-1-git-send-email-gaurav.k.singh@intel.com
    (cherry picked from commit 8221229046e862977ae93ec9d34aa583fbd10397)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c53f225fd792970c75ce0cb4042a11d04ef06d09
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed Mar 21 15:08:47 2018 +0100

    drm/i915/gvt: throw error on unhandled vfio ioctls
    
    commit 9f591ae60e1be026901398ef99eede91237aa3a1 upstream.
    
    On unknown/unhandled ioctls the driver should return an error, so
    userspace knows it tried to use something unsupported.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 325abf3db041d7ca130a5f84024da2ffffa35f0e
Author: Daniel J Blueman <daniel@quora.org>
Date:   Mon Apr 2 15:10:35 2018 +0800

    drm/vc4: Fix memory leak during BO teardown
    
    commit c0db1b677e1d584fab5d7ac76a32e1c0157542e0 upstream.
    
    During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being
    freed leading to leaking many 128B allocations. Fix the memory leak by
    releasing it at teardown time.
    
    Cc: stable@vger.kernel.org
    Fixes: 6d45c81d229d ("drm/vc4: Add support for branching in shader validation.")
    Signed-off-by: Daniel J Blueman <daniel@quora.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180402071035.25356-1-daniel@quora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08641a24d4e70607f767b066def49d3b3a3f9c98
Author: Xiaoming Gao <gxm.linux.kernel@gmail.com>
Date:   Fri Apr 13 17:48:08 2018 +0800

    x86/tsc: Prevent 32bit truncation in calc_hpet_ref()
    
    commit d3878e164dcd3925a237a20e879432400e369172 upstream.
    
    The TSC calibration code uses HPET as reference. The conversion normalizes
    the delta of two HPET timestamps:
    
        hpetref = ((tshpet1 - tshpet2) * HPET_PERIOD) / 1e6
    
    and then divides the normalized delta of the corresponding TSC timestamps
    by the result to calulate the TSC frequency.
    
        tscfreq = ((tstsc1 - tstsc2 ) * 1e6) / hpetref
    
    This uses do_div() which takes an u32 as the divisor, which worked so far
    because the HPET frequency was low enough that 'hpetref' never exceeded
    32bit.
    
    On Skylake machines the HPET frequency increased so 'hpetref' can exceed
    32bit. do_div() truncates the divisor, which causes the calibration to
    fail.
    
    Use div64_u64() to avoid the problem.
    
    [ tglx: Fixes whitespace mangled patch and rewrote changelog ]
    
    Signed-off-by: Xiaoming Gao <newtongao@tencent.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Cc: peterz@infradead.org
    Cc: hpa@zytor.com
    Link: https://lkml.kernel.org/r/38894564-4fc9-b8ec-353f-de702839e44e@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6aaaaa4d62ad885a8ca0a255d4af975f843ee98
Author: Anson Huang <Anson.Huang@nxp.com>
Date:   Thu Apr 19 14:04:43 2018 +0800

    clocksource/imx-tpm: Correct -ETIME return condition check
    
    commit 7407188489c62a7b5694bc75a6db2b82af94c9a5 upstream.
    
    The additional brakects added to tpm_set_next_event's return value
    computation causes (int) forced type conversion NOT taking effect, and the
    incorrect value return will cause various system timer issue, like RCU
    stall etc..
    
    Remove the additional brackets to make sure tpm_set_next_event always
    returns correct value.
    
    Fixes: 059ab7b82eec ("clocksource/drivers/imx-tpm: Add imx tpm timer support")
    Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Dong Aisheng <Aisheng.dong@nxp.com>
    Cc: stable@vger.kernel.org
    Cc: daniel.lezcano@linaro.org
    Cc: Linux-imx@nxp.com
    Link: https://lkml.kernel.org/r/1524117883-2484-1-git-send-email-Anson.Huang@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8d4055372b58aad4a51b67e176eabdcc238fde3
Author: Dou Liyang <douly.fnst@cn.fujitsu.com>
Date:   Thu Apr 12 09:40:52 2018 +0800

    x86/acpi: Prevent X2APIC id 0xffffffff from being accounted
    
    commit 10daf10ab154e31237a8c07242be3063fb6a9bf4 upstream.
    
    RongQing reported that there are some X2APIC id 0xffffffff in his machine's
    ACPI MADT table, which makes the number of possible CPU inaccurate.
    
    The reason is that the ACPI X2APIC parser has no sanity check for APIC ID
    0xffffffff, which is an invalid id in all APIC types. See "Intel® 64
    Architecture x2APIC Specification", Chapter 2.4.1.
    
    Add a sanity check to acpi_parse_x2apic() which ignores the invalid id.
    
    Reported-by: Li RongQing <lirongqing@baidu.com>
    Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Cc: len.brown@intel.com
    Cc: rjw@rjwysocki.net
    Cc: hpa@zytor.com
    Link: https://lkml.kernel.org/r/20180412014052.25186-1-douly.fnst@cn.fujitsu.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6edc45e21c35f9e0124f7ac8b2d8eb7f551cc3b
Author: David Sterba <dsterba@suse.com>
Date:   Mon Apr 16 21:10:14 2018 +0200

    btrfs: fix unaligned access in readdir
    
    commit 92d32170847bfff2dd08af2c016085779f2fd2a1 upstream.
    
    The last update to readdir introduced a temporary buffer to store the
    emitted readdir data, but as there are file names of variable length,
    there's a lot of unaligned access.
    
    This was observed on a sparc64 machine:
    
      Kernel unaligned access at TPC[102f3080] btrfs_real_readdir+0x51c/0x718 [btrfs]
    
    Fixes: 23b5ec74943 ("btrfs: fix readdir deadlock with pagefault")
    CC: stable@vger.kernel.org # 4.14+
    Reported-and-tested-by: René Rebe <rene@exactcode.com>
    Reviewed-by: Liu Bo <bo.liu@linux.alibaba.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 240a528684852cc3231b276b59c3e4bf1b533de5
Author: Steve French <smfrench@gmail.com>
Date:   Fri Apr 20 12:19:07 2018 -0500

    cifs: do not allow creating sockets except with SMB1 posix exensions
    
    commit 1d0cffa674cfa7d185a302c8c6850fc50b893bed upstream.
    
    RHBZ: 1453123
    
    Since at least the 3.10 kernel and likely a lot earlier we have
    not been able to create unix domain sockets in a cifs share
    when mounted using the SFU mount option (except when mounted
    with the cifs unix extensions to Samba e.g.)
    Trying to create a socket, for example using the af_unix command from
    xfstests will cause :
    BUG: unable to handle kernel NULL pointer dereference at 00000000
    00000040
    
    Since no one uses or depends on being able to create unix domains sockets
    on a cifs share the easiest fix to stop this vulnerability is to simply
    not allow creation of any other special files than char or block devices
    when sfu is used.
    
    Added update to Ronnie's patch to handle a tcon link leak, and
    to address a buf leak noticed by Gustavo and Colin.
    
    Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    CC:  Colin Ian King <colin.king@canonical.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Reported-by: Eryu Guan <eguan@redhat.com>
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>