commit f6d5cb9e2c06f7d583dd9f4f7cca21d13d78c32a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Aug 26 10:31:07 2020 +0200

    Linux 4.19.142
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f09071279b2e5c2ebffa9b60375c52aee576c61
Author: Will Deacon <will@kernel.org>
Date:   Tue Aug 11 11:27:25 2020 +0100

    KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set
    
    commit b5331379bc62611d1026173a09c73573384201d9 upstream.
    
    When an MMU notifier call results in unmapping a range that spans multiple
    PGDs, we end up calling into cond_resched_lock() when crossing a PGD boundary,
    since this avoids running into RCU stalls during VM teardown. Unfortunately,
    if the VM is destroyed as a result of OOM, then blocking is not permitted
    and the call to the scheduler triggers the following BUG():
    
     | BUG: sleeping function called from invalid context at arch/arm64/kvm/mmu.c:394
     | in_atomic(): 1, irqs_disabled(): 0, non_block: 1, pid: 36, name: oom_reaper
     | INFO: lockdep is turned off.
     | CPU: 3 PID: 36 Comm: oom_reaper Not tainted 5.8.0 #1
     | Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
     | Call trace:
     |  dump_backtrace+0x0/0x284
     |  show_stack+0x1c/0x28
     |  dump_stack+0xf0/0x1a4
     |  ___might_sleep+0x2bc/0x2cc
     |  unmap_stage2_range+0x160/0x1ac
     |  kvm_unmap_hva_range+0x1a0/0x1c8
     |  kvm_mmu_notifier_invalidate_range_start+0x8c/0xf8
     |  __mmu_notifier_invalidate_range_start+0x218/0x31c
     |  mmu_notifier_invalidate_range_start_nonblock+0x78/0xb0
     |  __oom_reap_task_mm+0x128/0x268
     |  oom_reap_task+0xac/0x298
     |  oom_reaper+0x178/0x17c
     |  kthread+0x1e4/0x1fc
     |  ret_from_fork+0x10/0x30
    
    Use the new 'flags' argument to kvm_unmap_hva_range() to ensure that we
    only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is set in the notifier
    flags.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 8b3405e345b5 ("kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd")
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Message-Id: <20200811102725.7121-3-will@kernel.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [will: Backport to 4.19; use 'blockable' instead of non-existent MMU_NOTIFIER_RANGE_BLOCKABLE flag]
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a53dc16499fc9efd8db0b40e45f3344a0fb9c0a2
Author: Will Deacon <will@kernel.org>
Date:   Tue Aug 11 11:27:24 2020 +0100

    KVM: Pass MMU notifier range flags to kvm_unmap_hva_range()
    
    commit fdfe7cbd58806522e799e2a50a15aee7f2cbb7b6 upstream.
    
    The 'flags' field of 'struct mmu_notifier_range' is used to indicate
    whether invalidate_range_{start,end}() are permitted to block. In the
    case of kvm_mmu_notifier_invalidate_range_start(), this field is not
    forwarded on to the architecture-specific implementation of
    kvm_unmap_hva_range() and therefore the backend cannot sensibly decide
    whether or not to block.
    
    Add an extra 'flags' parameter to kvm_unmap_hva_range() so that
    architectures are aware as to whether or not they are permitted to block.
    
    Cc: <stable@vger.kernel.org>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Message-Id: <20200811102725.7121-2-will@kernel.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [will: Backport to 4.19; use 'blockable' instead of non-existent range flags]
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 903c6bd937ca84ee9e60eca6beb5c2593d0bfd4e
Author: Stephen Boyd <sboyd@kernel.org>
Date:   Wed Aug 28 11:19:59 2019 -0700

    clk: Evict unregistered clks from parent caches
    
    commit bdcf1dc253248542537a742ae1e7ccafdd03f2d3 upstream.
    
    We leave a dangling pointer in each clk_core::parents array that has an
    unregistered clk as a potential parent when that clk_core pointer is
    freed by clk{_hw}_unregister(). It is impossible for the true parent of
    a clk to be set with clk_set_parent() once the dangling pointer is left
    in the cache because we compare parent pointers in
    clk_fetch_parent_index() instead of checking for a matching clk name or
    clk_hw pointer.
    
    Before commit ede77858473a ("clk: Remove global clk traversal on fetch
    parent index"), we would check clk_hw pointers, which has a higher
    chance of being the same between registration and unregistration, but it
    can still be allocated and freed by the clk provider. In fact, this has
    been a long standing problem since commit da0f0b2c3ad2 ("clk: Correct
    lookup logic in clk_fetch_parent_index()") where we stopped trying to
    compare clk names and skipped over entries in the cache that weren't
    NULL.
    
    There are good (performance) reasons to not do the global tree lookup in
    cases where the cache holds dangling pointers to parents that have been
    unregistered. Let's take the performance hit on the uncommon
    registration path instead. Loop through all the clk_core::parents arrays
    when a clk is unregistered and set the entry to NULL when the parent
    cache entry and clk being unregistered are the same pointer. This will
    fix this problem and avoid the overhead for the "normal" case.
    
    Based on a patch by Bjorn Andersson.
    
    Fixes: da0f0b2c3ad2 ("clk: Correct lookup logic in clk_fetch_parent_index()")
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Link: https://lkml.kernel.org/r/20190828181959.204401-1-sboyd@kernel.org
    Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da1754a2fb2d95c355949e282409cccf884ed7a2
Author: Juergen Gross <jgross@suse.com>
Date:   Thu Aug 20 08:59:08 2020 +0200

    xen: don't reschedule in preemption off sections
    
    For support of long running hypercalls xen_maybe_preempt_hcall() is
    calling cond_resched() in case a hypercall marked as preemptible has
    been interrupted.
    
    Normally this is no problem, as only hypercalls done via some ioctl()s
    are marked to be preemptible. In rare cases when during such a
    preemptible hypercall an interrupt occurs and any softirq action is
    started from irq_exit(), a further hypercall issued by the softirq
    handler will be regarded to be preemptible, too. This might lead to
    rescheduling in spite of the softirq handler potentially having set
    preempt_disable(), leading to splats like:
    
    BUG: sleeping function called from invalid context at drivers/xen/preempt.c:37
    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 20775, name: xl
    INFO: lockdep is turned off.
    CPU: 1 PID: 20775 Comm: xl Tainted: G D W 5.4.46-1_prgmr_debug.el7.x86_64 #1
    Call Trace:
    <IRQ>
    dump_stack+0x8f/0xd0
    ___might_sleep.cold.76+0xb2/0x103
    xen_maybe_preempt_hcall+0x48/0x70
    xen_do_hypervisor_callback+0x37/0x40
    RIP: e030:xen_hypercall_xen_version+0xa/0x20
    Code: ...
    RSP: e02b:ffffc900400dcc30 EFLAGS: 00000246
    RAX: 000000000004000d RBX: 0000000000000200 RCX: ffffffff8100122a
    RDX: ffff88812e788000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffffff83ee3ad0 R08: 0000000000000001 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000246 R12: ffff8881824aa0b0
    R13: 0000000865496000 R14: 0000000865496000 R15: ffff88815d040000
    ? xen_hypercall_xen_version+0xa/0x20
    ? xen_force_evtchn_callback+0x9/0x10
    ? check_events+0x12/0x20
    ? xen_restore_fl_direct+0x1f/0x20
    ? _raw_spin_unlock_irqrestore+0x53/0x60
    ? debug_dma_sync_single_for_cpu+0x91/0xc0
    ? _raw_spin_unlock_irqrestore+0x53/0x60
    ? xen_swiotlb_sync_single_for_cpu+0x3d/0x140
    ? mlx4_en_process_rx_cq+0x6b6/0x1110 [mlx4_en]
    ? mlx4_en_poll_rx_cq+0x64/0x100 [mlx4_en]
    ? net_rx_action+0x151/0x4a0
    ? __do_softirq+0xed/0x55b
    ? irq_exit+0xea/0x100
    ? xen_evtchn_do_upcall+0x2c/0x40
    ? xen_do_hypervisor_callback+0x29/0x40
    </IRQ>
    ? xen_hypercall_domctl+0xa/0x20
    ? xen_hypercall_domctl+0x8/0x20
    ? privcmd_ioctl+0x221/0x990 [xen_privcmd]
    ? do_vfs_ioctl+0xa5/0x6f0
    ? ksys_ioctl+0x60/0x90
    ? trace_hardirqs_off_thunk+0x1a/0x20
    ? __x64_sys_ioctl+0x16/0x20
    ? do_syscall_64+0x62/0x250
    ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fix that by testing preempt_count() before calling cond_resched().
    
    In kernel 5.8 this can't happen any more due to the entry code rework
    (more than 100 patches, so not a candidate for backporting).
    
    The issue was introduced in kernel 4.3, so this patch should go into
    all stable kernels in [4.3 ... 5.7].
    
    Reported-by: Sarah Newman <srn@prgmr.com>
    Fixes: 0fa2f5cb2b0ecd8 ("sched/preempt, xen: Use need_resched() instead of should_resched()")
    Cc: Sarah Newman <srn@prgmr.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Tested-by: Chris Brannon <cmb@prgmr.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 734654ae7962be55c44ff3fb0bb0652b5149cc17
Author: Peter Xu <peterx@redhat.com>
Date:   Thu Aug 6 23:26:11 2020 -0700

    mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible
    
    commit 75802ca66354a39ab8e35822747cd08b3384a99a upstream.
    
    This is found by code observation only.
    
    Firstly, the worst case scenario should assume the whole range was covered
    by pmd sharing.  The old algorithm might not work as expected for ranges
    like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the
    expected range should be (0, 2g).
    
    Since at it, remove the loop since it should not be required.  With that,
    the new code should be faster too when the invalidating range is huge.
    
    Mike said:
    
    : With range (1g-2m, 1g+2m) within a vma (0, 2g) the existing code will only
    : adjust to (0, 1g+2m) which is incorrect.
    :
    : We should cc stable.  The original reason for adjusting the range was to
    : prevent data corruption (getting wrong page).  Since the range is not
    : always adjusted correctly, the potential for corruption still exists.
    :
    : However, I am fairly confident that adjust_range_if_pmd_sharing_possible
    : is only gong to be called in two cases:
    :
    : 1) for a single page
    : 2) for range == entire vma
    :
    : In those cases, the current code should produce the correct results.
    :
    : To be safe, let's just cc stable.
    
    Fixes: 017b1660df89 ("mm: migration: fix migration of huge PMD shared pages")
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200730201636.74778-1-peterx@redhat.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcb6e6efb3298e59d90ee05c6ed33de810314892
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Aug 22 18:25:52 2020 -0400

    do_epoll_ctl(): clean the failure exits up a bit
    
    commit 52c479697c9b73f628140dcdfcd39ea302d05482 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4957d56414ff5ca8fe62f8f11f0f9814f35b1d11
Author: Marc Zyngier <maz@kernel.org>
Date:   Wed Aug 19 17:12:17 2020 +0100

    epoll: Keep a reference on files added to the check list
    
    commit a9ed4a6560b8562b7e2e2bed9527e88001f7b682 upstream.
    
    When adding a new fd to an epoll, and that this new fd is an
    epoll fd itself, we recursively scan the fds attached to it
    to detect cycles, and add non-epool files to a "check list"
    that gets subsequently parsed.
    
    However, this check list isn't completely safe when deletions
    can happen concurrently. To sidestep the issue, make sure that
    a struct file placed on the check list sees its f_count increased,
    ensuring that a concurrent deletion won't result in the file
    disapearing from under our feet.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ff3c97b47521d6700cc6485c7935908dcd2c27c
Author: Li Heng <liheng40@huawei.com>
Date:   Mon Jul 20 15:22:18 2020 +0800

    efi: add missed destroy_workqueue when efisubsys_init fails
    
    commit 98086df8b70c06234a8f4290c46064e44dafa0ed upstream.
    
    destroy_workqueue() should be called to destroy efi_rts_wq
    when efisubsys_init() init resources fails.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Li Heng <liheng40@huawei.com>
    Link: https://lore.kernel.org/r/1595229738-10087-1-git-send-email-liheng40@huawei.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa80b284d706f445e353255db0f943e9b4b797cc
Author: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Date:   Thu Aug 20 11:48:44 2020 +0530

    powerpc/pseries: Do not initiate shutdown when system is running on UPS
    
    commit 90a9b102eddf6a3f987d15f4454e26a2532c1c98 upstream.
    
    As per PAPR we have to look for both EPOW sensor value and event
    modifier to identify the type of event and take appropriate action.
    
    In LoPAPR v1.1 section 10.2.2 includes table 136 "EPOW Action Codes":
    
      SYSTEM_SHUTDOWN 3
    
      The system must be shut down. An EPOW-aware OS logs the EPOW error
      log information, then schedules the system to be shut down to begin
      after an OS defined delay internal (default is 10 minutes.)
    
    Then in section 10.3.2.2.8 there is table 146 "Platform Event Log
    Format, Version 6, EPOW Section", which includes the "EPOW Event
    Modifier":
    
      For EPOW sensor value = 3
      0x01 = Normal system shutdown with no additional delay
      0x02 = Loss of utility power, system is running on UPS/Battery
      0x03 = Loss of system critical functions, system should be shutdown
      0x04 = Ambient temperature too high
      All other values = reserved
    
    We have a user space tool (rtas_errd) on LPAR to monitor for
    EPOW_SHUTDOWN_ON_UPS. Once it gets an event it initiates shutdown
    after predefined time. It also starts monitoring for any new EPOW
    events. If it receives "Power restored" event before predefined time
    it will cancel the shutdown. Otherwise after predefined time it will
    shutdown the system.
    
    Commit 79872e35469b ("powerpc/pseries: All events of
    EPOW_SYSTEM_SHUTDOWN must initiate shutdown") changed our handling of
    the "on UPS/Battery" case, to immediately shutdown the system. This
    breaks existing setups that rely on the userspace tool to delay
    shutdown and let the system run on the UPS.
    
    Fixes: 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown")
    Cc: stable@vger.kernel.org # v4.0+
    Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
    [mpe: Massage change log and add PAPR references]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200820061844.306460-1-hegdevasant@linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 405ef1b43a3d837e50b30b5164a5cab815931d66
Author: Tom Rix <trix@redhat.com>
Date:   Fri Aug 21 06:56:00 2020 -0700

    net: dsa: b53: check for timeout
    
    [ Upstream commit 774d977abfd024e6f73484544b9abe5a5cd62de7 ]
    
    clang static analysis reports this problem
    
    b53_common.c:1583:13: warning: The left expression of the compound
      assignment is an uninitialized value. The computed value will
      also be garbage
            ent.port &= ~BIT(port);
            ~~~~~~~~ ^
    
    ent is set by a successful call to b53_arl_read().  Unsuccessful
    calls are caught by an switch statement handling specific returns.
    b32_arl_read() calls b53_arl_op_wait() which fails with the
    unhandled -ETIMEDOUT.
    
    So add -ETIMEDOUT to the switch statement.  Because
    b53_arl_op_wait() already prints out a message, do not add another
    one.
    
    Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bf1ca93b93a35e54a3f2b6f36f40d026917c679
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Thu Aug 20 14:53:15 2020 -0700

    hv_netvsc: Fix the queue_mapping in netvsc_vf_xmit()
    
    [ Upstream commit c3d897e01aef8ddc43149e4d661b86f823e3aae7 ]
    
    netvsc_vf_xmit() / dev_queue_xmit() will call VF NIC’s ndo_select_queue
    or netdev_pick_tx() again. They will use skb_get_rx_queue() to get the
    queue number, so the “skb->queue_mapping - 1” will be used. This may
    cause the last queue of VF not been used.
    
    Use skb_record_rx_queue() here, so that the skb_get_rx_queue() called
    later will get the correct queue number, and VF will be able to use
    all queues.
    
    Fixes: b3bf5666a510 ("hv_netvsc: defer queue selection to VF")
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 391d0ad15088a310a3e6a4c8703793143f57796b
Author: Wang Hai <wanghai38@huawei.com>
Date:   Wed Aug 19 10:33:09 2020 +0800

    net: gemini: Fix missing free_netdev() in error path of gemini_ethernet_port_probe()
    
    [ Upstream commit cf96d977381d4a23957bade2ddf1c420b74a26b6 ]
    
    Replace alloc_etherdev_mq with devm_alloc_etherdev_mqs. In this way,
    when probe fails, netdev can be freed automatically.
    
    Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 676f44ce25afa1edf3f69359bb7c8206a7945311
Author: Shay Agroskin <shayagr@amazon.com>
Date:   Wed Aug 19 20:28:36 2020 +0300

    net: ena: Prevent reset after device destruction
    
    [ Upstream commit 63d4a4c145cca2e84dc6e62d2ef5cb990c9723c2 ]
    
    The reset work is scheduled by the timer routine whenever it
    detects that a device reset is required (e.g. when a keep_alive signal
    is missing).
    When releasing device resources in ena_destroy_device() the driver
    cancels the scheduling of the timer routine without destroying the reset
    work explicitly.
    
    This creates the following bug:
        The driver is suspended and the ena_suspend() function is called
            -> This function calls ena_destroy_device() to free the net device
               resources
                -> The driver waits for the timer routine to finish
                its execution and then cancels it, thus preventing from it
                to be called again.
    
        If, in its final execution, the timer routine schedules a reset,
        the reset routine might be called afterwards,and a redundant call to
        ena_restore_device() would be made.
    
    By changing the reset routine we allow it to read the device's state
    accurately.
    This is achieved by checking whether ENA_FLAG_TRIGGER_RESET flag is set
    before resetting the device and making both the destruction function and
    the flag check are under rtnl lock.
    The ENA_FLAG_TRIGGER_RESET is cleared at the end of the destruction
    routine. Also surround the flag check with 'likely' because
    we expect that the reset routine would be called only when
    ENA_FLAG_TRIGGER_RESET flag is set.
    
    The destruction of the timer and reset services in __ena_shutoff() have to
    stay, even though the timer routine is destroyed in ena_destroy_device().
    This is to avoid a case in which the reset routine is scheduled after
    free_netdev() in __ena_shutoff(), which would create an access to freed
    memory in adapter->flags.
    
    Fixes: 8c5c7abdeb2d ("net: ena: add power management ops to the ENA driver")
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae405ea98693f3991192d172cbbcea04c53b0aba
Author: Jiri Wiesner <jwiesner@suse.com>
Date:   Sun Aug 16 20:52:44 2020 +0200

    bonding: fix active-backup failover for current ARP slave
    
    [ Upstream commit 0410d07190961ac526f05085765a8d04d926545b ]
    
    When the ARP monitor is used for link detection, ARP replies are
    validated for all slaves (arp_validate=3) and fail_over_mac is set to
    active, two slaves of an active-backup bond may get stuck in a state
    where both of them are active and pass packets that they receive to
    the bond. This state makes IPv6 duplicate address detection fail. The
    state is reached thus:
    1. The current active slave goes down because the ARP target
       is not reachable.
    2. The current ARP slave is chosen and made active.
    3. A new slave is enslaved. This new slave becomes the current active
       slave and can reach the ARP target.
    As a result, the current ARP slave stays active after the enslave
    action has finished and the log is littered with "PROBE BAD" messages:
    > bond0: PROBE: c_arp ens10 && cas ens11 BAD
    The workaround is to remove the slave with "going back" status from
    the bond and re-enslave it. This issue was encountered when DPDK PMD
    interfaces were being enslaved to an active-backup bond.
    
    I would be possible to fix the issue in bond_enslave() or
    bond_change_active_slave() but the ARP monitor was fixed instead to
    keep most of the actions changing the current ARP slave in the ARP
    monitor code. The current ARP slave is set as inactive and backup
    during the commit phase. A new state, BOND_LINK_FAIL, has been
    introduced for slaves in the context of the ARP monitor. This allows
    administrators to see how slaves are rotated for sending ARP requests
    and attempts are made to find a new active slave.
    
    Fixes: b2220cad583c9 ("bonding: refactor ARP active-backup monitor")
    Signed-off-by: Jiri Wiesner <jwiesner@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d676b22edb8034427b916a7a17088b54f62156c5
Author: David Howells <dhowells@redhat.com>
Date:   Fri Aug 21 10:15:12 2020 +0100

    afs: Fix NULL deref in afs_dynroot_depopulate()
    
    [ Upstream commit 5e0b17b026eb7c6de9baa9b0d45a51b05f05abe1 ]
    
    If an error occurs during the construction of an afs superblock, it's
    possible that an error occurs after a superblock is created, but before
    we've created the root dentry.  If the superblock has a dynamic root
    (ie.  what's normally mounted on /afs), the afs_kill_super() will call
    afs_dynroot_depopulate() to unpin any created dentries - but this will
    oops if the root hasn't been created yet.
    
    Fix this by skipping that bit of code if there is no root dentry.
    
    This leads to an oops looking like:
    
            general protection fault, ...
            KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
            ...
            RIP: 0010:afs_dynroot_depopulate+0x25f/0x529 fs/afs/dynroot.c:385
            ...
            Call Trace:
             afs_kill_super+0x13b/0x180 fs/afs/super.c:535
             deactivate_locked_super+0x94/0x160 fs/super.c:335
             afs_get_tree+0x1124/0x1460 fs/afs/super.c:598
             vfs_get_tree+0x89/0x2f0 fs/super.c:1547
             do_new_mount fs/namespace.c:2875 [inline]
             path_mount+0x1387/0x2070 fs/namespace.c:3192
             do_mount fs/namespace.c:3205 [inline]
             __do_sys_mount fs/namespace.c:3413 [inline]
             __se_sys_mount fs/namespace.c:3390 [inline]
             __x64_sys_mount+0x27f/0x300 fs/namespace.c:3390
             do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
             entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    which is oopsing on this line:
    
            inode_lock(root->d_inode);
    
    presumably because sb->s_root was NULL.
    
    Fixes: 0da0b7fd73e4 ("afs: Display manually added cells in dynamic root mount")
    Reported-by: syzbot+c1eff8205244ae7e11a6@syzkaller.appspotmail.com
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0e3b33f47cfe719868e15b3a5d5d25f17312ef6
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Wed Aug 5 21:45:48 2020 -0700

    RDMA/bnxt_re: Do not add user qps to flushlist
    
    [ Upstream commit a812f2d60a9fb7818f9c81f967180317b52545c0 ]
    
    Driver shall add only the kernel qps to the flush list for clean up.
    During async error events from the HW, driver is adding qps to this list
    without checking if the qp is kernel qp or not.
    
    Add a check to avoid user qp addition to the flush list.
    
    Fixes: 942c9b6ca8de ("RDMA/bnxt_re: Avoid Hard lockup during error CQE processing")
    Fixes: c50866e2853a ("bnxt_re: fix the regression due to changes in alloc_pbl")
    Link: https://lore.kernel.org/r/1596689148-4023-1-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32d8e2b4b1774b33a2be126064ad6ded16bad2b9
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Thu Aug 20 06:30:47 2020 +0200

    Fix build error when CONFIG_ACPI is not set/enabled:
    
    [ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
    
    ../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
    ../arch/x86/pci/xen.c:410:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
      acpi_noirq_set();
    
    Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: xen-devel@lists.xenproject.org
    Cc: linux-pci@vger.kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1eb3a9ed6d529814f5061cd92e3c80fa61877000
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Jul 10 16:16:51 2020 +0200

    efi: avoid error message when booting under Xen
    
    [ Upstream commit 6163a985e50cb19d5bdf73f98e45b8af91a77658 ]
    
    efifb_probe() will issue an error message in case the kernel is booted
    as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
    that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set.
    
    Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2152780222402f071071f4fd83da184c879bb80
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Aug 18 01:36:29 2020 +0900

    kconfig: qconf: fix signal connection to invalid slots
    
    [ Upstream commit d85de3399f97467baa2026fbbbe587850d01ba8a ]
    
    If you right-click in the ConfigList window, you will see the following
    messages in the console:
    
    QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:888
    QObject::connect:  (sender name:   'config')
    QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:897
    QObject::connect:  (sender name:   'config')
    QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:906
    QObject::connect:  (sender name:   'config')
    
    Right, there is no such slot in QAction. I think this is a typo of
    setChecked.
    
    Due to this bug, when you toggled the menu "Option->Show Name/Range/Data"
    the state of the context menu was not previously updated. Fix this.
    
    Fixes: d5d973c3f8a9 ("Port xconfig to Qt5 - Put back some of the old implementation(part 2)")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0a40332820b52fce33c2fe14eb647af02952f6d
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri Aug 7 18:19:08 2020 +0900

    kconfig: qconf: do not limit the pop-up menu to the first row
    
    [ Upstream commit fa8de0a3bf3c02e6f00b7746e7e934db522cdda9 ]
    
    If you right-click the first row in the option tree, the pop-up menu
    shows up, but if you right-click the second row or below, the event
    is ignored due to the following check:
    
      if (e->y() <= header()->geometry().bottom()) {
    
    Perhaps, the intention was to show the pop-menu only when the tree
    header was right-clicked, but this handler is not called in that case.
    
    Since the origin of e->y() starts from the bottom of the header,
    this check is odd.
    
    Going forward, you can right-click anywhere in the tree to get the
    pop-up menu.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9701d5dd61067d16010388e843b1cc7ab403753
Author: Jim Mattson <jmattson@google.com>
Date:   Mon Aug 17 11:16:54 2020 -0700

    kvm: x86: Toggling CR4.PKE does not load PDPTEs in PAE mode
    
    [ Upstream commit cb957adb4ea422bd758568df5b2478ea3bb34f35 ]
    
    See the SDM, volume 3, section 4.4.1:
    
    If PAE paging would be in use following an execution of MOV to CR0 or
    MOV to CR4 (see Section 4.1.1) and the instruction is modifying any of
    CR0.CD, CR0.NW, CR0.PG, CR4.PAE, CR4.PGE, CR4.PSE, or CR4.SMEP; then
    the PDPTEs are loaded from the address in CR3.
    
    Fixes: b9baba8614890 ("KVM, pkeys: expose CPUID/CR4 to guest")
    Cc: Huaitong Han <huaitong.han@intel.com>
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Peter Shier <pshier@google.com>
    Reviewed-by: Oliver Upton <oupton@google.com>
    Message-Id: <20200817181655.3716509-1-jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec877b0e7cb26c9cd87361ea2c50c5255b36d56e
Author: Jim Mattson <jmattson@google.com>
Date:   Mon Aug 17 11:16:55 2020 -0700

    kvm: x86: Toggling CR4.SMAP does not load PDPTEs in PAE mode
    
    [ Upstream commit 427890aff8558eb4326e723835e0eae0e6fe3102 ]
    
    See the SDM, volume 3, section 4.4.1:
    
    If PAE paging would be in use following an execution of MOV to CR0 or
    MOV to CR4 (see Section 4.1.1) and the instruction is modifying any of
    CR0.CD, CR0.NW, CR0.PG, CR4.PAE, CR4.PGE, CR4.PSE, or CR4.SMEP; then
    the PDPTEs are loaded from the address in CR3.
    
    Fixes: 0be0226f07d14 ("KVM: MMU: fix SMAP virtualization")
    Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Peter Shier <pshier@google.com>
    Reviewed-by: Oliver Upton <oupton@google.com>
    Message-Id: <20200817181655.3716509-2-jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d200964e4deaa72f2a7d2eaefc9953d3df8784ce
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Aug 17 11:09:13 2020 -0600

    vfio/type1: Add proper error unwind for vfio_iommu_replay()
    
    [ Upstream commit aae7a75a821a793ed6b8ad502a5890fb8e8f172d ]
    
    The vfio_iommu_replay() function does not currently unwind on error,
    yet it does pin pages, perform IOMMU mapping, and modify the vfio_dma
    structure to indicate IOMMU mapping.  The IOMMU mappings are torn down
    when the domain is destroyed, but the other actions go on to cause
    trouble later.  For example, the iommu->domain_list can be empty if we
    only have a non-IOMMU backed mdev attached.  We don't currently check
    if the list is empty before getting the first entry in the list, which
    leads to a bogus domain pointer.  If a vfio_dma entry is erroneously
    marked as iommu_mapped, we'll attempt to use that bogus pointer to
    retrieve the existing physical page addresses.
    
    This is the scenario that uncovered this issue, attempting to hot-add
    a vfio-pci device to a container with an existing mdev device and DMA
    mappings, one of which could not be pinned, causing a failure adding
    the new group to the existing container and setting the conditions
    for a subsequent attempt to explode.
    
    To resolve this, we can first check if the domain_list is empty so
    that we can reject replay of a bogus domain, should we ever encounter
    this inconsistent state again in the future.  The real fix though is
    to add the necessary unwind support, which means cleaning up the
    current pinning if an IOMMU mapping fails, then walking back through
    the r-b tree of DMA entries, reading from the IOMMU which ranges are
    mapped, and unmapping and unpinning those ranges.  To be able to do
    this, we also defer marking the DMA entry as IOMMU mapped until all
    entries are processed, in order to allow the unwind to know the
    disposition of each entry.
    
    Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices")
    Reported-by: Zhiyi Guo <zhguo@redhat.com>
    Tested-by: Zhiyi Guo <zhguo@redhat.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b2dd0c04bb889a88fbf92f2480f295d36e61ec9
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Thu Aug 13 16:41:10 2020 +0800

    ASoC: intel: Fix memleak in sst_media_open
    
    [ Upstream commit 062fa09f44f4fb3776a23184d5d296b0c8872eb9 ]
    
    When power_up_sst() fails, stream needs to be freed
    just like when try_module_get() fails. However, current
    code is returning directly and ends up leaking memory.
    
    Fixes: 0121327c1a68b ("ASoC: Intel: mfld-pcm: add control for powering up/down dsp")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20200813084112.26205-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd79b3b960f26209bf3c06067d8909bf93831564
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Aug 11 11:34:52 2020 +0100

    ASoC: msm8916-wcd-analog: fix register Interrupt offset
    
    [ Upstream commit ff69c97ef84c9f7795adb49e9f07c9adcdd0c288 ]
    
    For some reason interrupt set and clear register offsets are
    not set correctly.
    This patch corrects them!
    
    Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec")
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Tested-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20200811103452.20448-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5599b901df07d2a91e8b13f35f0393a25b2b832
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Wed Aug 12 18:56:28 2020 +0200

    s390/ptrace: fix storage key handling
    
    [ Upstream commit fd78c59446b8d050ecf3e0897c5a486c7de7c595 ]
    
    The key member of the runtime instrumentation control block contains
    only the access key, not the complete storage key. Therefore the value
    must be shifted by four bits. Since existing user space does not
    necessarily query and set the access key correctly, just ignore the
    user space provided key and use the correct one.
    Note: this is only relevant for debugging purposes in case somebody
    compiles a kernel with a default storage access key set to a value not
    equal to zero.
    
    Fixes: 262832bc5acd ("s390/ptrace: add runtime instrumention register get/set")
    Reported-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a5120b162798fdf07147dff03b23b69f147d311
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Wed Aug 12 18:55:41 2020 +0200

    s390/runtime_instrumentation: fix storage key handling
    
    [ Upstream commit 9eaba29c7985236e16468f4e6a49cc18cf01443e ]
    
    The key member of the runtime instrumentation control block contains
    only the access key, not the complete storage key. Therefore the value
    must be shifted by four bits.
    Note: this is only relevant for debugging purposes in case somebody
    compiles a kernel with a default storage access key set to a value not
    equal to zero.
    
    Fixes: e4b8b3f33fca ("s390: add support for runtime instrumentation")
    Reported-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8dcf188973549e89ed751a10911eab5ff91a98e8
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Fri Aug 14 20:05:58 2020 -0700

    bonding: fix a potential double-unregister
    
    [ Upstream commit 832707021666411d04795c564a4adea5d6b94f17 ]
    
    When we tear down a network namespace, we unregister all
    the netdevices within it. So we may queue a slave device
    and a bonding device together in the same unregister queue.
    
    If the only slave device is non-ethernet, it would
    automatically unregister the bonding device as well. Thus,
    we may end up unregistering the bonding device twice.
    
    Workaround this special case by checking reg_state.
    
    Fixes: 9b5e383c11b0 ("net: Introduce unregister_netdevice_many()")
    Reported-by: syzbot+af23e7f3e0a7e10c8b67@syzkaller.appspotmail.com
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Andy Gospodarek <andy@greyhouse.net>
    Cc: Jay Vosburgh <j.vosburgh@gmail.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a74506f2d91c7395e353202e616aa8712a606bff
Author: Jarod Wilson <jarod@redhat.com>
Date:   Thu Aug 13 10:09:00 2020 -0400

    bonding: show saner speed for broadcast mode
    
    [ Upstream commit 4ca0d9ac3fd8f9f90b72a15d8da2aca3ffb58418 ]
    
    Broadcast mode bonds transmit a copy of all traffic simultaneously out of
    all interfaces, so the "speed" of the bond isn't really the aggregate of
    all interfaces, but rather, the speed of the slowest active interface.
    
    Also, the type of the speed field is u32, not unsigned long, so adjust
    that accordingly, as required to make min() function here without
    complaining about mismatching types.
    
    Fixes: bb5b052f751b ("bond: add support to read speed and duplex via ethtool")
    CC: Jay Vosburgh <j.vosburgh@gmail.com>
    CC: Veaceslav Falico <vfalico@gmail.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: netdev@vger.kernel.org
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99728347a5351990818805246f84847b760cbc3f
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Thu Aug 13 15:13:14 2020 +0800

    net: fec: correct the error path for regulator disable in probe
    
    [ Upstream commit c6165cf0dbb82ded90163dce3ac183fc7a913dc4 ]
    
    Correct the error path for regulator disable.
    
    Fixes: 9269e5560b26 ("net: fec: add phy-reset-gpios PROBE_DEFER check")
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46858b2f609ffd81d6f437a6099d4782fa2e33a8
Author: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
Date:   Tue Aug 11 10:56:49 2020 +0000

    i40e: Fix crash during removing i40e driver
    
    [ Upstream commit 5b6d4a7f20b09c47ca598760f6dafd554af8b6d5 ]
    
    Fix the reason of crashing system by add waiting time to finish reset
    recovery process before starting remove driver procedure.
    Now VSI is releasing if VSI is not in reset recovery mode.
    Without this fix it was possible to start remove driver if other
    processing command need reset recovery procedure which resulted in
    null pointer dereference. VSI used by the ethtool process has been
    cleared by remove driver process.
    
    [ 6731.508665] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [ 6731.508668] #PF: supervisor read access in kernel mode
    [ 6731.508670] #PF: error_code(0x0000) - not-present page
    [ 6731.508671] PGD 0 P4D 0
    [ 6731.508674] Oops: 0000 [#1] SMP PTI
    [ 6731.508679] Hardware name: Intel Corporation S2600WT2R/S2600WT2R, BIOS SE5C610.86B.01.01.0021.032120170601 03/21/2017
    [ 6731.508694] RIP: 0010:i40e_down+0x252/0x310 [i40e]
    [ 6731.508696] Code: c7 78 de fa c0 e8 61 02 3a c1 66 83 bb f6 0c 00 00 00 0f 84 bf 00 00 00 45 31 e4 45 31 ff eb 03 41 89 c7 48 8b 83 98 0c 00 00 <4a> 8b 3c 20 e8 a5 79 02 00 48 83 bb d0 0c 00 00 00 74 10 48 8b 83
    [ 6731.508698] RSP: 0018:ffffb75ac7b3faf0 EFLAGS: 00010246
    [ 6731.508700] RAX: 0000000000000000 RBX: ffff9c9874bd5000 RCX: 0000000000000007
    [ 6731.508701] RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff9c987f4d9780
    [ 6731.508703] RBP: ffffb75ac7b3fb30 R08: 0000000000005b60 R09: 0000000000000004
    [ 6731.508704] R10: ffffb75ac64fbd90 R11: 0000000000000001 R12: 0000000000000000
    [ 6731.508706] R13: ffff9c97a08e0000 R14: ffff9c97a08e0a68 R15: 0000000000000000
    [ 6731.508708] FS:  00007f2617cd2740(0000) GS:ffff9c987f4c0000(0000) knlGS:0000000000000000
    [ 6731.508710] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 6731.508711] CR2: 0000000000000000 CR3: 0000001e765c4006 CR4: 00000000003606e0
    [ 6731.508713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 6731.508714] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 6731.508715] Call Trace:
    [ 6731.508734]  i40e_vsi_close+0x84/0x90 [i40e]
    [ 6731.508742]  i40e_quiesce_vsi.part.98+0x3c/0x40 [i40e]
    [ 6731.508749]  i40e_pf_quiesce_all_vsi+0x55/0x60 [i40e]
    [ 6731.508757]  i40e_prep_for_reset+0x59/0x130 [i40e]
    [ 6731.508765]  i40e_reconfig_rss_queues+0x5a/0x120 [i40e]
    [ 6731.508774]  i40e_set_channels+0xda/0x170 [i40e]
    [ 6731.508778]  ethtool_set_channels+0xe9/0x150
    [ 6731.508781]  dev_ethtool+0x1b94/0x2920
    [ 6731.508805]  dev_ioctl+0xc2/0x590
    [ 6731.508811]  sock_do_ioctl+0xae/0x150
    [ 6731.508813]  sock_ioctl+0x34f/0x3c0
    [ 6731.508821]  ksys_ioctl+0x98/0xb0
    [ 6731.508828]  __x64_sys_ioctl+0x1a/0x20
    [ 6731.508831]  do_syscall_64+0x57/0x1c0
    [ 6731.508835]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 4b8164467b85 ("i40e: Add common function for finding VSI by type")
    Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com>
    Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 04efb368bc0bd90cbb07b8e9fa79dcea11f5b8ce
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Thu Aug 6 13:40:59 2020 +0000

    i40e: Set RX_ONLY mode for unicast promiscuous on VLAN
    
    [ Upstream commit 4bd5e02a2ed1575c2f65bd3c557a077dd399f0e8 ]
    
    Trusted VF with unicast promiscuous mode set, could listen to TX
    traffic of other VFs.
    Set unicast promiscuous mode to RX traffic, if VSI has port VLAN
    configured. Rename misleading I40E_AQC_SET_VSI_PROMISC_TX bit to
    I40E_AQC_SET_VSI_PROMISC_RX_ONLY. Aligned unicast promiscuous with
    VLAN to the one without VLAN.
    
    Fixes: 6c41a7606967 ("i40e: Add promiscuous on VLAN support")
    Fixes: 3b1200891b7f ("i40e: When in promisc mode apply promisc mode to Tx Traffic as well")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9d4cab67f7e2fe7c444f82cefef5660c079ad71
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Tue Aug 11 13:02:05 2020 +0100

    ASoC: q6routing: add dummy register read/write function
    
    [ Upstream commit 796a58fe2b8c9b6668db00d92512ec84be663027 ]
    
    Most of the DAPM widgets for DSP ASoC components reuse reg field
    of the widgets for its internal calculations, however these are not
    real registers. So read/writes to these numbers are not really
    valid. However ASoC core will read these registers to get default
    state during startup.
    
    With recent changes to ASoC core, every register read/write
    failures are reported very verbosely. Prior to this fails to reads
    are totally ignored, so we never saw any error messages.
    
    To fix this add dummy read/write function to return default value.
    
    Fixes: e3a33673e845 ("ASoC: qdsp6: q6routing: Add q6routing driver")
    Reported-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20200811120205.21805-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1373f884a081d336aafd9ed742229fb2cd7a3613
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 28 15:04:33 2020 +0200

    ext4: don't allow overlapping system zones
    
    [ Upstream commit bf9a379d0980e7413d94cb18dac73db2bfc5f470 ]
    
    Currently, add_system_zone() just silently merges two added system zones
    that overlap. However the overlap should not happen and it generally
    suggests that some unrelated metadata overlap which indicates the fs is
    corrupted. We should have caught such problems earlier (e.g. in
    ext4_check_descriptors()) but add this check as another line of defense.
    In later patch we also use this for stricter checking of journal inode
    extent tree.
    
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20200728130437.7804-3-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3ddf6ba5e28a57729fff1605ae08e21be5c92e3
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Wed Jun 17 14:19:04 2020 -0500

    ext4: fix potential negative array index in do_split()
    
    [ Upstream commit 5872331b3d91820e14716632ebb56b1399b34fe1 ]
    
    If for any reason a directory passed to do_split() does not have enough
    active entries to exceed half the size of the block, we can end up
    iterating over all "count" entries without finding a split point.
    
    In this case, count == move, and split will be zero, and we will
    attempt a negative index into map[].
    
    Guard against this by detecting this case, and falling back to
    split-to-half-of-count instead; in this case we will still have
    plenty of space (> half blocksize) in each split block.
    
    Fixes: ef2b02d3e617 ("ext34: ensure do_split leaves enough free space in both blocks")
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/f53e246b-647c-64bb-16ec-135383c70ad7@redhat.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c89e40ede2b0f1e292fb54d2e73fe952b4d44d8
Author: Helge Deller <deller@gmx.de>
Date:   Tue Aug 11 18:36:04 2020 -0700

    fs/signalfd.c: fix inconsistent return codes for signalfd4
    
    [ Upstream commit a089e3fd5a82aea20f3d9ec4caa5f4c65cc2cfcc ]
    
    The kernel signalfd4() syscall returns different error codes when called
    either in compat or native mode.  This behaviour makes correct emulation
    in qemu and testing programs like LTP more complicated.
    
    Fix the code to always return -in both modes- EFAULT for unaccessible user
    memory, and EINVAL when called with an invalid signal mask.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Laurent Vivier <laurent@vivier.eu>
    Link: http://lkml.kernel.org/r/20200530100707.GA10159@ls3530.fritz.box
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6afcb8b93400b774f3d74df7e1fc63805cbc92b3
Author: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Date:   Tue Aug 11 18:33:54 2020 -0700

    alpha: fix annotation of io{read,write}{16,32}be()
    
    [ Upstream commit bd72866b8da499e60633ff28f8a4f6e09ca78efe ]
    
    These accessors must be used to read/write a big-endian bus.  The value
    returned or written is native-endian.
    
    However, these accessors are defined using be{16,32}_to_cpu() or
    cpu_to_be{16,32}() to make the endian conversion but these expect a
    __be{16,32} when none is present.  Keeping them would need a force cast
    that would solve nothing at all.
    
    So, do the conversion using swab{16,32}, like done in asm-generic for
    similar situations.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Cc: Matt Turner <mattst88@gmail.com>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Link: http://lkml.kernel.org/r/20200622114232.80039-1-luc.vanoostenryck@gmail.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c90652abae15465210207418ac8c1ecb230e3b1e
Author: Eiichi Tsukata <devel@etsukata.com>
Date:   Thu Aug 6 15:18:48 2020 -0700

    xfs: Fix UBSAN null-ptr-deref in xfs_sysfs_init
    
    [ Upstream commit 96cf2a2c75567ff56195fe3126d497a2e7e4379f ]
    
    If xfs_sysfs_init is called with parent_kobj == NULL, UBSAN
    shows the following warning:
    
      UBSAN: null-ptr-deref in ./fs/xfs/xfs_sysfs.h:37:23
      member access within null pointer of type 'struct xfs_kobj'
      Call Trace:
       dump_stack+0x10e/0x195
       ubsan_type_mismatch_common+0x241/0x280
       __ubsan_handle_type_mismatch_v1+0x32/0x40
       init_xfs_fs+0x12b/0x28f
       do_one_initcall+0xdd/0x1d0
       do_initcall_level+0x151/0x1b6
       do_initcalls+0x50/0x8f
       do_basic_setup+0x29/0x2b
       kernel_init_freeable+0x19f/0x20b
       kernel_init+0x11/0x1e0
       ret_from_fork+0x22/0x30
    
    Fix it by checking parent_kobj before the code accesses its member.
    
    Signed-off-by: Eiichi Tsukata <devel@etsukata.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    [darrick: minor whitespace edits]
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4e7716b534941ed1bfe7410ccaf531471cd042e
Author: Gaurav Singh <gaurav1086@gmail.com>
Date:   Thu Aug 6 23:17:25 2020 -0700

    tools/testing/selftests/cgroup/cgroup_util.c: cg_read_strcmp: fix null pointer dereference
    
    [ Upstream commit d830020656c5b68ced962ed3cb51a90e0a89d4c4 ]
    
    Haven't reproduced this issue. This PR is does a minor code cleanup.
    
    Signed-off-by: Gaurav Singh <gaurav1086@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Michal Koutn <mkoutny@suse.com>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Chris Down <chris@chrisdown.name>
    Link: http://lkml.kernel.org/r/20200726013808.22242-1-gaurav1086@gmail.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f489d30979bd352ffbd555020b6ca79efb93b89
Author: Mao Wenan <wenan.mao@linux.alibaba.com>
Date:   Sun Aug 2 15:44:09 2020 +0800

    virtio_ring: Avoid loop when vq is broken in virtqueue_poll
    
    [ Upstream commit 481a0d7422db26fb63e2d64f0652667a5c6d0f3e ]
    
    The loop may exist if vq->broken is true,
    virtqueue_get_buf_ctx_packed or virtqueue_get_buf_ctx_split
    will return NULL, so virtnet_poll will reschedule napi to
    receive packet, it will lead cpu usage(si) to 100%.
    
    call trace as below:
    virtnet_poll
            virtnet_receive
                    virtqueue_get_buf_ctx
                            virtqueue_get_buf_ctx_packed
                            virtqueue_get_buf_ctx_split
            virtqueue_napi_complete
                    virtqueue_poll           //return true
                    virtqueue_napi_schedule //it will reschedule napi
    
    to fix this, return false if vq is broken in virtqueue_poll.
    
    Signed-off-by: Mao Wenan <wenan.mao@linux.alibaba.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Link: https://lore.kernel.org/r/1596354249-96204-1-git-send-email-wenan.mao@linux.alibaba.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f419fd2f86d7db1d7fcb6f2fb9fde2c9fdd8bbe
Author: Javed Hasan <jhasan@marvell.com>
Date:   Wed Jul 29 01:18:23 2020 -0700

    scsi: libfc: Free skb in fc_disc_gpn_id_resp() for valid cases
    
    [ Upstream commit ec007ef40abb6a164d148b0dc19789a7a2de2cc8 ]
    
    In fc_disc_gpn_id_resp(), skb is supposed to get freed in all cases except
    for PTR_ERR. However, in some cases it didn't.
    
    This fix is to call fc_frame_free(fp) before function returns.
    
    Link: https://lore.kernel.org/r/20200729081824.30996-2-jhasan@marvell.com
    Reviewed-by: Girish Basrur <gbasrur@marvell.com>
    Reviewed-by: Santosh Vernekar <svernekar@marvell.com>
    Reviewed-by: Saurav Kashyap <skashyap@marvell.com>
    Reviewed-by: Shyam Sundar <ssundar@marvell.com>
    Signed-off-by: Javed Hasan <jhasan@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62646cb9ab6603423a51b3f4704ba1746b83182d
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Mon Aug 3 11:37:20 2020 -0700

    cpufreq: intel_pstate: Fix cpuinfo_max_freq when MSR_TURBO_RATIO_LIMIT is 0
    
    [ Upstream commit 4daca379c703ff55edc065e8e5173dcfeecf0148 ]
    
    The MSR_TURBO_RATIO_LIMIT can be 0. This is not an error. User can update
    this MSR via BIOS settings on some systems or can use msr tools to update.
    Also some systems boot with value = 0.
    
    This results in display of cpufreq/cpuinfo_max_freq wrong. This value
    will be equal to cpufreq/base_frequency, even though turbo is enabled.
    
    But platform will still function normally in HWP mode as we get max
    1-core frequency from the MSR_HWP_CAPABILITIES. This MSR is already used
    to calculate cpu->pstate.turbo_freq, which is used for to set
    policy->cpuinfo.max_freq. But some other places cpu->pstate.turbo_pstate
    is used. For example to set policy->max.
    
    To fix this, also update cpu->pstate.turbo_pstate when updating
    cpu->pstate.turbo_freq.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f831c6c95d02d667b450b579bbfa781e96661120
Author: Xiubo Li <xiubli@redhat.com>
Date:   Thu Jul 23 15:32:25 2020 +0800

    ceph: fix use-after-free for fsc->mdsc
    
    [ Upstream commit a7caa88f8b72c136f9a401f498471b8a8e35370d ]
    
    If the ceph_mdsc_init() fails, it will free the mdsc already.
    
    Reported-by: syzbot+b57f46d8d6ea51960b8c@syzkaller.appspotmail.com
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96de3dbf27ae663e0c276ff8ac2dfed58d87a9ab
Author: Zhe Li <lizhe67@huawei.com>
Date:   Fri Jun 19 17:06:35 2020 +0800

    jffs2: fix UAF problem
    
    [ Upstream commit 798b7347e4f29553db4b996393caf12f5b233daf ]
    
    The log of UAF problem is listed below.
    BUG: KASAN: use-after-free in jffs2_rmdir+0xa4/0x1cc [jffs2] at addr c1f165fc
    Read of size 4 by task rm/8283
    =============================================================================
    BUG kmalloc-32 (Tainted: P    B      O   ): kasan: bad access detected
    -----------------------------------------------------------------------------
    
    INFO: Allocated in 0xbbbbbbbb age=3054364 cpu=0 pid=0
            0xb0bba6ef
            jffs2_write_dirent+0x11c/0x9c8 [jffs2]
            __slab_alloc.isra.21.constprop.25+0x2c/0x44
            __kmalloc+0x1dc/0x370
            jffs2_write_dirent+0x11c/0x9c8 [jffs2]
            jffs2_do_unlink+0x328/0x5fc [jffs2]
            jffs2_rmdir+0x110/0x1cc [jffs2]
            vfs_rmdir+0x180/0x268
            do_rmdir+0x2cc/0x300
            ret_from_syscall+0x0/0x3c
    INFO: Freed in 0x205b age=3054364 cpu=0 pid=0
            0x2e9173
            jffs2_add_fd_to_list+0x138/0x1dc [jffs2]
            jffs2_add_fd_to_list+0x138/0x1dc [jffs2]
            jffs2_garbage_collect_dirent.isra.3+0x21c/0x288 [jffs2]
            jffs2_garbage_collect_live+0x16bc/0x1800 [jffs2]
            jffs2_garbage_collect_pass+0x678/0x11d4 [jffs2]
            jffs2_garbage_collect_thread+0x1e8/0x3b0 [jffs2]
            kthread+0x1a8/0x1b0
            ret_from_kernel_thread+0x5c/0x64
    Call Trace:
    [c17ddd20] [c02452d4] kasan_report.part.0+0x298/0x72c (unreliable)
    [c17ddda0] [d2509680] jffs2_rmdir+0xa4/0x1cc [jffs2]
    [c17dddd0] [c026da04] vfs_rmdir+0x180/0x268
    [c17dde00] [c026f4e4] do_rmdir+0x2cc/0x300
    [c17ddf40] [c001a658] ret_from_syscall+0x0/0x3c
    
    The root cause is that we don't get "jffs2_inode_info.sem" before
    we scan list "jffs2_inode_info.dents" in function jffs2_rmdir.
    This patch add codes to get "jffs2_inode_info.sem" before we scan
    "jffs2_inode_info.dents" to slove the UAF problem.
    
    Signed-off-by: Zhe Li <lizhe67@huawei.com>
    Reviewed-by: Hou Tao <houtao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bc31e520faf8af5555030e7662c0577f25a1be0
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Tue Jul 14 10:36:09 2020 -0700

    xfs: fix inode quota reservation checks
    
    [ Upstream commit f959b5d037e71a4d69b5bf71faffa065d9269b4a ]
    
    xfs_trans_dqresv is the function that we use to make reservations
    against resource quotas.  Each resource contains two counters: the
    q_core counter, which tracks resources allocated on disk; and the dquot
    reservation counter, which tracks how much of that resource has either
    been allocated or reserved by threads that are working on metadata
    updates.
    
    For disk blocks, we compare the proposed reservation counter against the
    hard and soft limits to decide if we're going to fail the operation.
    However, for inodes we inexplicably compare against the q_core counter,
    not the incore reservation count.
    
    Since the q_core counter is always lower than the reservation count and
    we unlock the dquot between reservation and transaction commit, this
    means that multiple threads can reserve the last inode count before we
    hit the hard limit, and when they commit, we'll be well over the hard
    limit.
    
    Fix this by checking against the incore inode reservation counter, since
    we would appear to maintain that correctly (and that's what we report in
    GETQUOTA).
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Allison Collins <allison.henderson@oracle.com>
    Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88f7857c90e457e44ff45872d012e37cb3e3a41e
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jun 30 15:55:45 2020 -0400

    svcrdma: Fix another Receive buffer leak
    
    [ Upstream commit 64d26422516b2e347b32e6d9b1d40b3c19a62aae ]
    
    During a connection tear down, the Receive queue is flushed before
    the device resources are freed. Typically, all the Receives flush
    with IB_WR_FLUSH_ERR.
    
    However, any pending successful Receives flush with IB_WR_SUCCESS,
    and the server automatically posts a fresh Receive to replace the
    completing one. This happens even after the connection has closed
    and the RQ is drained. Receives that are posted after the RQ is
    drained appear never to complete, causing a Receive resource leak.
    The leaked Receive buffer is left DMA-mapped.
    
    To prevent these late-posted recv_ctxt's from leaking, block new
    Receive posting after XPT_CLOSE is set.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 465bc917d164313baec14b0965e4e70db5e29ade
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Sat Jun 13 17:17:52 2020 +1000

    m68knommu: fix overwriting of bits in ColdFire V3 cache control
    
    [ Upstream commit bdee0e793cea10c516ff48bf3ebb4ef1820a116b ]
    
    The Cache Control Register (CACR) of the ColdFire V3 has bits that
    control high level caching functions, and also enable/disable the use
    of the alternate stack pointer register (the EUSP bit) to provide
    separate supervisor and user stack pointer registers. The code as
    it is today will blindly clear the EUSP bit on cache actions like
    invalidation. So it is broken for this case - and that will result
    in failed booting (interrupt entry and exit processing will be
    completely hosed).
    
    This only affects ColdFire V3 parts that support the alternate stack
    register (like the 5329 for example) - generally speaking new parts do,
    older parts don't. It has no impact on ColdFire V3 parts with the single
    stack pointer, like the 5307 for example.
    
    Fix the cache bit defines used, so they maintain the EUSP bit when
    carrying out cache actions through the CACR register.
    
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4af8c25bd9b16ecffbeb5c1a70c4cfec2f0c2ef
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Tue Jul 21 22:24:07 2020 -0700

    Input: psmouse - add a newline when printing 'proto' by sysfs
    
    [ Upstream commit 4aec14de3a15cf9789a0e19c847f164776f49473 ]
    
    When I cat parameter 'proto' by sysfs, it displays as follows. It's
    better to add a newline for easy reading.
    
    root@syzkaller:~# cat /sys/module/psmouse/parameters/proto
    autoroot@syzkaller:~#
    
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Link: https://lore.kernel.org/r/20200720073846.120724-1-wangxiongfeng2@huawei.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 773ae06f9c40d57c74f2d3e80e52290acc1064fa
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Fri Jul 10 11:02:23 2020 +0200

    media: vpss: clean up resources in init
    
    [ Upstream commit 9c487b0b0ea7ff22127fe99a7f67657d8730ff94 ]
    
    If platform_driver_register() fails within vpss_init() resources are not
    cleaned up. The patch fixes this issue by introducing the corresponding
    error handling.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5a5b21f34866d8a0d432e0d9274e5dc7a8b6de1
Author: Huacai Chen <chenhc@lemote.com>
Date:   Sat Jun 20 20:04:43 2020 +0800

    rtc: goldfish: Enable interrupt in set_alarm() when necessary
    
    [ Upstream commit 22f8d5a1bf230cf8567a4121fc3789babb46336d ]
    
    When use goldfish rtc, the "hwclock" command fails with "select() to
    /dev/rtc to wait for clock tick timed out". This is because "hwclock"
    need the set_alarm() hook to enable interrupt when alrm->enabled is
    true. This operation is missing in goldfish rtc (but other rtc drivers,
    such as cmos rtc, enable interrupt here), so add it.
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/1592654683-31314-1-git-send-email-chenhc@lemote.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b07b9521991cca961cc552213741afa7cf5906b5
Author: Chuhong Yuan <hslester96@gmail.com>
Date:   Fri Jun 5 18:17:28 2020 +0200

    media: budget-core: Improve exception handling in budget_register()
    
    [ Upstream commit fc0456458df8b3421dba2a5508cd817fbc20ea71 ]
    
    budget_register() has no error handling after its failure.
    Add the missed undo functions for error handling to fix it.
    
    Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d057ec39676bcb5fbf8177dad5f781f86e7d316
Author: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Date:   Thu Jun 18 15:16:32 2020 +0200

    scsi: target: tcmu: Fix crash in tcmu_flush_dcache_range on ARM
    
    [ Upstream commit 3145550a7f8b08356c8ff29feaa6c56aca12901d ]
    
    This patch fixes the following crash (see
    https://bugzilla.kernel.org/show_bug.cgi?id=208045)
    
     Process iscsi_trx (pid: 7496, stack limit = 0x0000000010dd111a)
     CPU: 0 PID: 7496 Comm: iscsi_trx Not tainted 4.19.118-0419118-generic
            #202004230533
     Hardware name: Greatwall QingTian DF720/F601, BIOS 601FBE20 Sep 26 2019
     pstate: 80400005 (Nzcv daif +PAN -UAO)
     pc : flush_dcache_page+0x18/0x40
     lr : is_ring_space_avail+0x68/0x2f8 [target_core_user]
     sp : ffff000015123a80
     x29: ffff000015123a80 x28: 0000000000000000
     x27: 0000000000001000 x26: ffff000023ea5000
     x25: ffffcfa25bbe08b8 x24: 0000000000000078
     x23: ffff7e0000000000 x22: ffff000023ea5001
     x21: ffffcfa24b79c000 x20: 0000000000000fff
     x19: ffff7e00008fa940 x18: 0000000000000000
     x17: 0000000000000000 x16: ffff2d047e709138
     x15: 0000000000000000 x14: 0000000000000000
     x13: 0000000000000000 x12: ffff2d047fbd0a40
     x11: 0000000000000000 x10: 0000000000000030
     x9 : 0000000000000000 x8 : ffffc9a254820a00
     x7 : 00000000000013b0 x6 : 000000000000003f
     x5 : 0000000000000040 x4 : ffffcfa25bbe08e8
     x3 : 0000000000001000 x2 : 0000000000000078
     x1 : ffffcfa25bbe08b8 x0 : ffff2d040bc88a18
     Call trace:
      flush_dcache_page+0x18/0x40
      is_ring_space_avail+0x68/0x2f8 [target_core_user]
      queue_cmd_ring+0x1f8/0x680 [target_core_user]
      tcmu_queue_cmd+0xe4/0x158 [target_core_user]
      __target_execute_cmd+0x30/0xf0 [target_core_mod]
      target_execute_cmd+0x294/0x390 [target_core_mod]
      transport_generic_new_cmd+0x1e8/0x358 [target_core_mod]
      transport_handle_cdb_direct+0x50/0xb0 [target_core_mod]
      iscsit_execute_cmd+0x2b4/0x350 [iscsi_target_mod]
      iscsit_sequence_cmd+0xd8/0x1d8 [iscsi_target_mod]
      iscsit_process_scsi_cmd+0xac/0xf8 [iscsi_target_mod]
      iscsit_get_rx_pdu+0x404/0xd00 [iscsi_target_mod]
      iscsi_target_rx_thread+0xb8/0x130 [iscsi_target_mod]
      kthread+0x130/0x138
      ret_from_fork+0x10/0x18
     Code: f9000bf3 aa0003f3 aa1e03e0 d503201f (f9400260)
     ---[ end trace 1e451c73f4266776 ]---
    
    The solution is based on patch:
    
      "scsi: target: tcmu: Optimize use of flush_dcache_page"
    
    which restricts the use of tcmu_flush_dcache_range() to addresses from
    vmalloc'ed areas only.
    
    This patch now replaces the virt_to_page() call in
    tcmu_flush_dcache_range() - which is wrong for vmalloced addrs - by
    vmalloc_to_page().
    
    The patch was tested on ARM with kernel 4.19.118 and 5.7.2
    
    Link: https://lore.kernel.org/r/20200618131632.32748-3-bstroesser@ts.fujitsu.com
    Tested-by: JiangYu <lnsyyj@hotmail.com>
    Tested-by: Daniel Meyerholt <dxm523@gmail.com>
    Acked-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ba7c21c03c4c73d9afe568e9b824682226b097f
Author: Stanley Chu <stanley.chu@mediatek.com>
Date:   Fri Jun 12 09:26:24 2020 +0800

    scsi: ufs: Add DELAY_BEFORE_LPM quirk for Micron devices
    
    [ Upstream commit c0a18ee0ce78d7957ec1a53be35b1b3beba80668 ]
    
    It is confirmed that Micron device needs DELAY_BEFORE_LPM quirk to have a
    delay before VCC is powered off. Sdd Micron vendor ID and this quirk for
    Micron devices.
    
    Link: https://lore.kernel.org/r/20200612012625.6615-2-stanley.chu@mediatek.com
    Reviewed-by: Bean Huo <beanhuo@micron.com>
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30872ac7dbf038869a2489d64bb8923cdb27d756
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Aug 3 13:09:01 2020 +0200

    spi: Prevent adding devices below an unregistering controller
    
    [ Upstream commit ddf75be47ca748f8b12d28ac64d624354fddf189 ]
    
    CONFIG_OF_DYNAMIC and CONFIG_ACPI allow adding SPI devices at runtime
    using a DeviceTree overlay or DSDT patch.  CONFIG_SPI_SLAVE allows the
    same via sysfs.
    
    But there are no precautions to prevent adding a device below a
    controller that's being removed.  Such a device is unusable and may not
    even be able to unbind cleanly as it becomes inaccessible once the
    controller has been torn down.  E.g. it is then impossible to quiesce
    the device's interrupt.
    
    of_spi_notify() and acpi_spi_notify() do hold a ref on the controller,
    but otherwise run lockless against spi_unregister_controller().
    
    Fix by holding the spi_add_lock in spi_unregister_controller() and
    bailing out of spi_add_device() if the controller has been unregistered
    concurrently.
    
    Fixes: ce79d54ae447 ("spi/of: Add OF notifier handler")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v3.19+
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: Octavian Purdila <octavian.purdila@intel.com>
    Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
    Link: https://lore.kernel.org/r/a8c3205088a969dc8410eec1eba9aface60f36af.1596451035.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c263d0e54f4348df126e4c3c1011253d7651544
Author: Liang Chen <cl@rock-chips.com>
Date:   Fri Mar 6 15:01:33 2020 +0800

    kthread: Do not preempt current task if it is going to call schedule()
    
    commit 26c7295be0c5e6da3fa45970e9748be983175b1b upstream.
    
    when we create a kthread with ktrhead_create_on_cpu(),the child thread
    entry is ktread.c:ktrhead() which will be preempted by the parent after
    call complete(done) while schedule() is not called yet,then the parent
    will call wait_task_inactive(child) but the child is still on the runqueue,
    so the parent will schedule_hrtimeout() for 1 jiffy,it will waste a lot of
    time,especially on startup.
    
      parent                             child
    ktrhead_create_on_cpu()
      wait_fo_completion(&done) -----> ktread.c:ktrhead()
                                 |----- complete(done);--wakeup and preempted by parent
     kthread_bind() <------------|  |-> schedule();--dequeue here
      wait_task_inactive(child)     |
       schedule_hrtimeout(1 jiffy) -|
    
    So we hope the child just wakeup parent but not preempted by parent, and the
    child is going to call schedule() soon,then the parent will not call
    schedule_hrtimeout(1 jiffy) as the child is already dequeue.
    
    The same issue for ktrhead_park()&&kthread_parkme().
    This patch can save 120ms on rk312x startup with CONFIG_HZ=300.
    
    Signed-off-by: Liang Chen <cl@rock-chips.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Link: https://lkml.kernel.org/r/20200306070133.18335-2-cl@rock-chips.com
    Signed-off-by: Chanho Park <chanho61.park@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e05c6786abadeda99b8bf3099643fe96b4d16977
Author: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Date:   Thu Aug 6 17:54:47 2020 -0400

    drm/amd/display: fix pow() crashing when given base 0
    
    commit d2e59d0ff4c44d1f6f8ed884a5bea7d1bb7fd98c upstream.
    
    [Why&How]
    pow(a,x) is implemented as exp(x*log(a)). log(0) will crash.
    So return 0^x = 0, unless x=0, convention seems to be 0^0 = 1.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
    Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
    Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d25a2b92cf4e168dc8ab8ace143173bd7f5aa77e
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu Aug 13 17:28:56 2020 +0200

    scsi: zfcp: Fix use-after-free in request timeout handlers
    
    commit 2d9a2c5f581be3991ba67fa9e7497c711220ea8e upstream.
    
    Before v4.15 commit 75492a51568b ("s390/scsi: Convert timers to use
    timer_setup()"), we intentionally only passed zfcp_adapter as context
    argument to zfcp_fsf_request_timeout_handler(). Since we only trigger
    adapter recovery, it was unnecessary to sync against races between timeout
    and (late) completion.  Likewise, we only passed zfcp_erp_action as context
    argument to zfcp_erp_timeout_handler(). Since we only wakeup an ERP action,
    it was unnecessary to sync against races between timeout and (late)
    completion.
    
    Meanwhile the timeout handlers get timer_list as context argument and do a
    timer-specific container-of to zfcp_fsf_req which can have been freed.
    
    Fix it by making sure that any request timeout handlers, that might just
    have started before del_timer(), are completed by using del_timer_sync()
    instead. This ensures the request free happens afterwards.
    
    Space time diagram of potential use-after-free:
    
    Basic idea is to have 2 or more pending requests whose timeouts run out at
    almost the same time.
    
    req 1 timeout     ERP thread        req 2 timeout
    ----------------  ----------------  ---------------------------------------
    zfcp_fsf_request_timeout_handler
    fsf_req = from_timer(fsf_req, t, timer)
    adapter = fsf_req->adapter
    zfcp_qdio_siosl(adapter)
    zfcp_erp_adapter_reopen(adapter,...)
                      zfcp_erp_strategy
                      ...
                      zfcp_fsf_req_dismiss_all
                      list_for_each_entry_safe
                        zfcp_fsf_req_complete 1
                        del_timer 1
                        zfcp_fsf_req_free 1
                        zfcp_fsf_req_complete 2
                                        zfcp_fsf_request_timeout_handler
                        del_timer 2
                                        fsf_req = from_timer(fsf_req, t, timer)
                        zfcp_fsf_req_free 2
                                        adapter = fsf_req->adapter
                                                  ^^^^^^^ already freed
    
    Link: https://lore.kernel.org/r/20200813152856.50088-1-maier@linux.ibm.com
    Fixes: 75492a51568b ("s390/scsi: Convert timers to use timer_setup()")
    Cc: <stable@vger.kernel.org> #4.15+
    Suggested-by: Julian Wiedmann <jwi@linux.ibm.com>
    Reviewed-by: Julian Wiedmann <jwi@linux.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 402ff143b90b48c1d1b29127fa538a2d227c2161
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Sat Jun 20 14:19:48 2020 +0800

    jbd2: add the missing unlock_buffer() in the error path of jbd2_write_superblock()
    
    commit ef3f5830b859604eda8723c26d90ab23edc027a4 upstream.
    
    jbd2_write_superblock() is under the buffer lock of journal superblock
    before ending that superblock write, so add a missing unlock_buffer() in
    in the error path before submitting buffer.
    
    Fixes: 742b06b5628f ("jbd2: check superblock mapped prior to committing")
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20200620061948.2049579-1-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5d3f789b272d76dadca4d35365a39ef516b31bf
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jul 31 18:21:35 2020 +0200

    ext4: fix checking of directory entry validity for inline directories
    
    commit 7303cb5bfe845f7d43cd9b2dbd37dbb266efda9b upstream.
    
    ext4_search_dir() and ext4_generic_delete_entry() can be called both for
    standard director blocks and for inline directories stored inside inode
    or inline xattr space. For the second case we didn't call
    ext4_check_dir_entry() with proper constraints that could result in
    accepting corrupted directory entry as well as false positive filesystem
    errors like:
    
    EXT4-fs error (device dm-0): ext4_search_dir:1395: inode #28320400:
    block 113246792: comm dockerd: bad entry in directory: directory entry too
    close to block end - offset=0, inode=28320403, rec_len=32, name_len=8,
    size=4096
    
    Fix the arguments passed to ext4_check_dir_entry().
    
    Fixes: 109ba779d6cc ("ext4: check for directory entries too close to block end")
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20200731162135.8080-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c666936d8d8b0ace4f3260d71a4eedefd53011d9
Author: Charan Teja Reddy <charante@codeaurora.org>
Date:   Thu Aug 20 17:42:27 2020 -0700

    mm, page_alloc: fix core hung in free_pcppages_bulk()
    
    commit 88e8ac11d2ea3acc003cf01bb5a38c8aa76c3cfd upstream.
    
    The following race is observed with the repeated online, offline and a
    delay between two successive online of memory blocks of movable zone.
    
    P1                                              P2
    
    Online the first memory block in
    the movable zone. The pcp struct
    values are initialized to default
    values,i.e., pcp->high = 0 &
    pcp->batch = 1.
    
                                            Allocate the pages from the
                                            movable zone.
    
    Try to Online the second memory
    block in the movable zone thus it
    entered the online_pages() but yet
    to call zone_pcp_update().
                                            This process is entered into
                                            the exit path thus it tries
                                            to release the order-0 pages
                                            to pcp lists through
                                            free_unref_page_commit().
                                            As pcp->high = 0, pcp->count = 1
                                            proceed to call the function
                                            free_pcppages_bulk().
    Update the pcp values thus the
    new pcp values are like, say,
    pcp->high = 378, pcp->batch = 63.
                                            Read the pcp's batch value using
                                            READ_ONCE() and pass the same to
                                            free_pcppages_bulk(), pcp values
                                            passed here are, batch = 63,
                                            count = 1.
    
                                            Since num of pages in the pcp
                                            lists are less than ->batch,
                                            then it will stuck in
                                            while(list_empty(list)) loop
                                            with interrupts disabled thus
                                            a core hung.
    
    Avoid this by ensuring free_pcppages_bulk() is called with proper count of
    pcp list pages.
    
    The mentioned race is some what easily reproducible without [1] because
    pcp's are not updated for the first memory block online and thus there is
    a enough race window for P2 between alloc+free and pcp struct values
    update through onlining of second memory block.
    
    With [1], the race still exists but it is very narrow as we update the pcp
    struct values for the first memory block online itself.
    
    This is not limited to the movable zone, it could also happen in cases
    with the normal zone (e.g., hotplug to a node that only has DMA memory, or
    no other memory yet).
    
    [1]: https://patchwork.kernel.org/patch/11696389/
    
    Fixes: 5f8dcc21211a ("page-allocator: split per-cpu list into one-list-per-migrate-type")
    Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: David Hildenbrand <david@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Vinayak Menon <vinmenon@codeaurora.org>
    Cc: <stable@vger.kernel.org> [2.6+]
    Link: http://lkml.kernel.org/r/1597150703-19003-1-git-send-email-charante@codeaurora.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84b8dc232afadf3aab425a104def45a1e7346a58
Author: Doug Berger <opendmb@gmail.com>
Date:   Thu Aug 20 17:42:24 2020 -0700

    mm: include CMA pages in lowmem_reserve at boot
    
    commit e08d3fdfe2dafa0331843f70ce1ff6c1c4900bf4 upstream.
    
    The lowmem_reserve arrays provide a means of applying pressure against
    allocations from lower zones that were targeted at higher zones.  Its
    values are a function of the number of pages managed by higher zones and
    are assigned by a call to the setup_per_zone_lowmem_reserve() function.
    
    The function is initially called at boot time by the function
    init_per_zone_wmark_min() and may be called later by accesses of the
    /proc/sys/vm/lowmem_reserve_ratio sysctl file.
    
    The function init_per_zone_wmark_min() was moved up from a module_init to
    a core_initcall to resolve a sequencing issue with khugepaged.
    Unfortunately this created a sequencing issue with CMA page accounting.
    
    The CMA pages are added to the managed page count of a zone when
    cma_init_reserved_areas() is called at boot also as a core_initcall.  This
    makes it uncertain whether the CMA pages will be added to the managed page
    counts of their zones before or after the call to
    init_per_zone_wmark_min() as it becomes dependent on link order.  With the
    current link order the pages are added to the managed count after the
    lowmem_reserve arrays are initialized at boot.
    
    This means the lowmem_reserve values at boot may be lower than the values
    used later if /proc/sys/vm/lowmem_reserve_ratio is accessed even if the
    ratio values are unchanged.
    
    In many cases the difference is not significant, but for example
    an ARM platform with 1GB of memory and the following memory layout
    
      cma: Reserved 256 MiB at 0x0000000030000000
      Zone ranges:
        DMA      [mem 0x0000000000000000-0x000000002fffffff]
        Normal   empty
        HighMem  [mem 0x0000000030000000-0x000000003fffffff]
    
    would result in 0 lowmem_reserve for the DMA zone.  This would allow
    userspace to deplete the DMA zone easily.
    
    Funnily enough
    
      $ cat /proc/sys/vm/lowmem_reserve_ratio
    
    would fix up the situation because as a side effect it forces
    setup_per_zone_lowmem_reserve.
    
    This commit breaks the link order dependency by invoking
    init_per_zone_wmark_min() as a postcore_initcall so that the CMA pages
    have the chance to be properly accounted in their zone(s) and allowing
    the lowmem_reserve arrays to receive consistent values.
    
    Fixes: bc22af74f271 ("mm: update min_free_kbytes from khugepaged after core initialization")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Jason Baron <jbaron@akamai.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/1597423766-27849-1-git-send-email-opendmb@gmail.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a54b901fd77e6f44a6ed6af2961671287e77fdf
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Thu Aug 20 17:42:14 2020 -0700

    kernel/relay.c: fix memleak on destroy relay channel
    
    commit 71e843295c680898959b22dc877ae3839cc22470 upstream.
    
    kmemleak report memory leak as follows:
    
      unreferenced object 0x607ee4e5f948 (size 8):
      comm "syz-executor.1", pid 2098, jiffies 4295031601 (age 288.468s)
      hex dump (first 8 bytes):
      00 00 00 00 00 00 00 00 ........
      backtrace:
         relay_open kernel/relay.c:583 [inline]
         relay_open+0xb6/0x970 kernel/relay.c:563
         do_blk_trace_setup+0x4a8/0xb20 kernel/trace/blktrace.c:557
         __blk_trace_setup+0xb6/0x150 kernel/trace/blktrace.c:597
         blk_trace_ioctl+0x146/0x280 kernel/trace/blktrace.c:738
         blkdev_ioctl+0xb2/0x6a0 block/ioctl.c:613
         block_ioctl+0xe5/0x120 fs/block_dev.c:1871
         vfs_ioctl fs/ioctl.c:48 [inline]
         __do_sys_ioctl fs/ioctl.c:753 [inline]
         __se_sys_ioctl fs/ioctl.c:739 [inline]
         __x64_sys_ioctl+0x170/0x1ce fs/ioctl.c:739
         do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    'chan->buf' is malloced in relay_open() by alloc_percpu() but not free
    while destroy the relay channel.  Fix it by adding free_percpu() before
    return from relay_destroy_channel().
    
    Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Daniel Axtens <dja@axtens.net>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Akash Goel <akash.goel@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200817122826.48518-1-weiyongjun1@huawei.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9660983738399465fd0e3b1977a61bbd29b2e5be
Author: Jann Horn <jannh@google.com>
Date:   Thu Aug 20 17:42:11 2020 -0700

    romfs: fix uninitialized memory leak in romfs_dev_read()
    
    commit bcf85fcedfdd17911982a3e3564fcfec7b01eebd upstream.
    
    romfs has a superblock field that limits the size of the filesystem; data
    beyond that limit is never accessed.
    
    romfs_dev_read() fetches a caller-supplied number of bytes from the
    backing device.  It returns 0 on success or an error code on failure;
    therefore, its API can't represent short reads, it's all-or-nothing.
    
    However, when romfs_dev_read() detects that the requested operation would
    cross the filesystem size limit, it currently silently truncates the
    requested number of bytes.  This e.g.  means that when the content of a
    file with size 0x1000 starts one byte before the filesystem size limit,
    ->readpage() will only fill a single byte of the supplied page while
    leaving the rest uninitialized, leaking that uninitialized memory to
    userspace.
    
    Fix it by returning an error code instead of truncating the read when the
    requested read operation would go beyond the end of the filesystem.
    
    Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: David Howells <dhowells@redhat.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20200818013202.2246365-1-jannh@google.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76c38196391b9a33894e0af8465dcef65e8deeab
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue Jul 21 10:17:50 2020 -0400

    btrfs: sysfs: use NOFS for device creation
    
    [ Upstream commit a47bd78d0c44621efb98b525d04d60dc4d1a79b0 ]
    
    Dave hit this splat during testing btrfs/078:
    
      ======================================================
      WARNING: possible circular locking dependency detected
      5.8.0-rc6-default+ #1191 Not tainted
      ------------------------------------------------------
      kswapd0/75 is trying to acquire lock:
      ffffa040e9d04ff8 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
    
      but task is already holding lock:
      ffffffff8b0c8040 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #2 (fs_reclaim){+.+.}-{0:0}:
             __lock_acquire+0x56f/0xaa0
             lock_acquire+0xa3/0x440
             fs_reclaim_acquire.part.0+0x25/0x30
             __kmalloc_track_caller+0x49/0x330
             kstrdup+0x2e/0x60
             __kernfs_new_node.constprop.0+0x44/0x250
             kernfs_new_node+0x25/0x50
             kernfs_create_link+0x34/0xa0
             sysfs_do_create_link_sd+0x5e/0xd0
             btrfs_sysfs_add_devices_dir+0x65/0x100 [btrfs]
             btrfs_init_new_device+0x44c/0x12b0 [btrfs]
             btrfs_ioctl+0xc3c/0x25c0 [btrfs]
             ksys_ioctl+0x68/0xa0
             __x64_sys_ioctl+0x16/0x20
             do_syscall_64+0x50/0xe0
             entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
      -> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}:
             __lock_acquire+0x56f/0xaa0
             lock_acquire+0xa3/0x440
             __mutex_lock+0xa0/0xaf0
             btrfs_chunk_alloc+0x137/0x3e0 [btrfs]
             find_free_extent+0xb44/0xfb0 [btrfs]
             btrfs_reserve_extent+0x9b/0x180 [btrfs]
             btrfs_alloc_tree_block+0xc1/0x350 [btrfs]
             alloc_tree_block_no_bg_flush+0x4a/0x60 [btrfs]
             __btrfs_cow_block+0x143/0x7a0 [btrfs]
             btrfs_cow_block+0x15f/0x310 [btrfs]
             push_leaf_right+0x150/0x240 [btrfs]
             split_leaf+0x3cd/0x6d0 [btrfs]
             btrfs_search_slot+0xd14/0xf70 [btrfs]
             btrfs_insert_empty_items+0x64/0xc0 [btrfs]
             __btrfs_commit_inode_delayed_items+0xb2/0x840 [btrfs]
             btrfs_async_run_delayed_root+0x10e/0x1d0 [btrfs]
             btrfs_work_helper+0x2f9/0x650 [btrfs]
             process_one_work+0x22c/0x600
             worker_thread+0x50/0x3b0
             kthread+0x137/0x150
             ret_from_fork+0x1f/0x30
    
      -> #0 (&delayed_node->mutex){+.+.}-{3:3}:
             check_prev_add+0x98/0xa20
             validate_chain+0xa8c/0x2a00
             __lock_acquire+0x56f/0xaa0
             lock_acquire+0xa3/0x440
             __mutex_lock+0xa0/0xaf0
             __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
             btrfs_evict_inode+0x3bf/0x560 [btrfs]
             evict+0xd6/0x1c0
             dispose_list+0x48/0x70
             prune_icache_sb+0x54/0x80
             super_cache_scan+0x121/0x1a0
             do_shrink_slab+0x175/0x420
             shrink_slab+0xb1/0x2e0
             shrink_node+0x192/0x600
             balance_pgdat+0x31f/0x750
             kswapd+0x206/0x510
             kthread+0x137/0x150
             ret_from_fork+0x1f/0x30
    
      other info that might help us debug this:
    
      Chain exists of:
        &delayed_node->mutex --> &fs_info->chunk_mutex --> fs_reclaim
    
       Possible unsafe locking scenario:
    
             CPU0                    CPU1
             ----                    ----
        lock(fs_reclaim);
                                     lock(&fs_info->chunk_mutex);
                                     lock(fs_reclaim);
        lock(&delayed_node->mutex);
    
       *** DEADLOCK ***
    
      3 locks held by kswapd0/75:
       #0: ffffffff8b0c8040 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30
       #1: ffffffff8b0b50b8 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x54/0x2e0
       #2: ffffa040e057c0e8 (&type->s_umount_key#26){++++}-{3:3}, at: trylock_super+0x16/0x50
    
      stack backtrace:
      CPU: 2 PID: 75 Comm: kswapd0 Not tainted 5.8.0-rc6-default+ #1191
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
      Call Trace:
       dump_stack+0x78/0xa0
       check_noncircular+0x16f/0x190
       check_prev_add+0x98/0xa20
       validate_chain+0xa8c/0x2a00
       __lock_acquire+0x56f/0xaa0
       lock_acquire+0xa3/0x440
       ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
       __mutex_lock+0xa0/0xaf0
       ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
       ? __lock_acquire+0x56f/0xaa0
       ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
       ? lock_acquire+0xa3/0x440
       ? btrfs_evict_inode+0x138/0x560 [btrfs]
       ? btrfs_evict_inode+0x2fe/0x560 [btrfs]
       ? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
       __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
       btrfs_evict_inode+0x3bf/0x560 [btrfs]
       evict+0xd6/0x1c0
       dispose_list+0x48/0x70
       prune_icache_sb+0x54/0x80
       super_cache_scan+0x121/0x1a0
       do_shrink_slab+0x175/0x420
       shrink_slab+0xb1/0x2e0
       shrink_node+0x192/0x600
       balance_pgdat+0x31f/0x750
       kswapd+0x206/0x510
       ? _raw_spin_unlock_irqrestore+0x3e/0x50
       ? finish_wait+0x90/0x90
       ? balance_pgdat+0x750/0x750
       kthread+0x137/0x150
       ? kthread_stop+0x2a0/0x2a0
       ret_from_fork+0x1f/0x30
    
    This is because we're holding the chunk_mutex while adding this device
    and adding its sysfs entries.  We actually hold different locks in
    different places when calling this function, the dev_replace semaphore
    for instance in dev replace, so instead of moving this call around
    simply wrap it's operations in NOFS.
    
    CC: stable@vger.kernel.org # 4.14+
    Reported-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35c1576814711791ecde4677bf5ef11254a0a940
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jul 28 16:39:26 2020 +0800

    btrfs: inode: fix NULL pointer dereference if inode doesn't need compression
    
    [ Upstream commit 1e6e238c3002ea3611465ce5f32777ddd6a40126 ]
    
    [BUG]
    There is a bug report of NULL pointer dereference caused in
    compress_file_extent():
    
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
      Workqueue: btrfs-delalloc btrfs_delalloc_helper [btrfs]
      NIP [c008000006dd4d34] compress_file_range.constprop.41+0x75c/0x8a0 [btrfs]
      LR [c008000006dd4d1c] compress_file_range.constprop.41+0x744/0x8a0 [btrfs]
      Call Trace:
      [c000000c69093b00] [c008000006dd4d1c] compress_file_range.constprop.41+0x744/0x8a0 [btrfs] (unreliable)
      [c000000c69093bd0] [c008000006dd4ebc] async_cow_start+0x44/0xa0 [btrfs]
      [c000000c69093c10] [c008000006e14824] normal_work_helper+0xdc/0x598 [btrfs]
      [c000000c69093c80] [c0000000001608c0] process_one_work+0x2c0/0x5b0
      [c000000c69093d10] [c000000000160c38] worker_thread+0x88/0x660
      [c000000c69093db0] [c00000000016b55c] kthread+0x1ac/0x1c0
      [c000000c69093e20] [c00000000000b660] ret_from_kernel_thread+0x5c/0x7c
      ---[ end trace f16954aa20d822f6 ]---
    
    [CAUSE]
    For the following execution route of compress_file_range(), it's
    possible to hit NULL pointer dereference:
    
     compress_file_extent()
     |- pages = NULL;
     |- start = async_chunk->start = 0;
     |- end = async_chunk = 4095;
     |- nr_pages = 1;
     |- inode_need_compress() == false; <<< Possible, see later explanation
     |  Now, we have nr_pages = 1, pages = NULL
     |- cont:
     |-             ret = cow_file_range_inline();
     |-             if (ret <= 0) {
     |-             for (i = 0; i < nr_pages; i++) {
     |-                     WARN_ON(pages[i]->mapping);     <<< Crash
    
    To enter above call execution branch, we need the following race:
    
        Thread 1 (chattr)     |            Thread 2 (writeback)
    --------------------------+------------------------------
                              | btrfs_run_delalloc_range
                              | |- inode_need_compress = true
                              | |- cow_file_range_async()
    btrfs_ioctl_set_flag()    |
    |- binode_flags |=        |
       BTRFS_INODE_NOCOMPRESS |
                              | compress_file_range()
                              | |- inode_need_compress = false
                              | |- nr_page = 1 while pages = NULL
                              | |  Then hit the crash
    
    [FIX]
    This patch will fix it by checking @pages before doing accessing it.
    This patch is only designed as a hot fix and easy to backport.
    
    More elegant fix may make btrfs only check inode_need_compress() once to
    avoid such race, but that would be another story.
    
    Reported-by: Luciano Chavez <chavez@us.ibm.com>
    Fixes: 4d3a800ebb12 ("btrfs: merge nr_pages input and output parameter in compress_pages")
    CC: stable@vger.kernel.org # 4.14.x: cecc8d9038d16: btrfs: Move free_pages_out label in inline extent handling branch in compress_file_range
    CC: stable@vger.kernel.org # 4.14+
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a3d84f1c2654c7210eab41e5894db4745db5029
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Wed Jul 17 14:41:45 2019 +0300

    btrfs: Move free_pages_out label in inline extent handling branch in compress_file_range
    
    [ Upstream commit cecc8d9038d164eda61fbcd72520975a554ea63e ]
    
    This label is only executed if compress_file_range fails to create an
    inline extent. So move its code in the semantically related inline
    extent handling branch. No functional changes.
    
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f50a0abaf3333cf6d967f56e0b5fa6bcb8ccc8f2
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Jul 22 11:12:46 2020 -0400

    btrfs: don't show full path of bind mounts in subvol=
    
    [ Upstream commit 3ef3959b29c4a5bd65526ab310a1a18ae533172a ]
    
    Chris Murphy reported a problem where rpm ostree will bind mount a bunch
    of things for whatever voodoo it's doing.  But when it does this
    /proc/mounts shows something like
    
      /dev/sda /mnt/test btrfs rw,relatime,subvolid=256,subvol=/foo 0 0
      /dev/sda /mnt/test/baz btrfs rw,relatime,subvolid=256,subvol=/foo/bar 0 0
    
    Despite subvolid=256 being subvol=/foo.  This is because we're just
    spitting out the dentry of the mount point, which in the case of bind
    mounts is the source path for the mountpoint.  Instead we should spit
    out the path to the actual subvol.  Fix this by looking up the name for
    the subvolid we have mounted.  With this fix the same test looks like
    this
    
      /dev/sda /mnt/test btrfs rw,relatime,subvolid=256,subvol=/foo 0 0
      /dev/sda /mnt/test/baz btrfs rw,relatime,subvolid=256,subvol=/foo 0 0
    
    Reported-by: Chris Murphy <chris@colorremedies.com>
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd39b6f6c29b354f14f835c8dcda82058b428229
Author: Marcos Paulo de Souza <mpdesouza@suse.com>
Date:   Fri Feb 21 14:56:12 2020 +0100

    btrfs: export helpers for subvolume name/id resolution
    
    [ Upstream commit c0c907a47dccf2cf26251a8fb4a8e7a3bf79ce84 ]
    
    The functions will be used outside of export.c and super.c to allow
    resolving subvolume name from a given id, eg. for subvolume deletion by
    id ioctl.
    
    Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ split from the next patch ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ef7ebb143705147bc74db2bc1bd0214c212e6bc
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Aug 20 17:42:02 2020 -0700

    khugepaged: adjust VM_BUG_ON_MM() in __khugepaged_enter()
    
    [ Upstream commit f3f99d63a8156c7a4a6b20aac22b53c5579c7dc1 ]
    
    syzbot crashes on the VM_BUG_ON_MM(khugepaged_test_exit(mm), mm) in
    __khugepaged_enter(): yes, when one thread is about to dump core, has set
    core_state, and is waiting for others, another might do something calling
    __khugepaged_enter(), which now crashes because I lumped the core_state
    test (known as "mmget_still_valid") into khugepaged_test_exit().  I still
    think it's best to lump them together, so just in this exceptional case,
    check mm->mm_users directly instead of khugepaged_test_exit().
    
    Fixes: bbe98f9cadff ("khugepaged: khugepaged_test_exit() check mmget_still_valid()")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Yang Shi <shy828301@gmail.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2008141503370.18085@eggly.anvils
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 17c08ee00b59067ed0537d91fd89873b3bba6491
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Aug 6 23:26:25 2020 -0700

    khugepaged: khugepaged_test_exit() check mmget_still_valid()
    
    [ Upstream commit bbe98f9cadff58cdd6a4acaeba0efa8565dabe65 ]
    
    Move collapse_huge_page()'s mmget_still_valid() check into
    khugepaged_test_exit() itself.  collapse_huge_page() is used for anon THP
    only, and earned its mmget_still_valid() check because it inserts a huge
    pmd entry in place of the page table's pmd entry; whereas
    collapse_file()'s retract_page_tables() or collapse_pte_mapped_thp()
    merely clears the page table's pmd entry.  But core dumping without mmap
    lock must have been as open to mistaking a racily cleared pmd entry for a
    page table at physical page 0, as exit_mmap() was.  And we certainly have
    no interest in mapping as a THP once dumping core.
    
    Fixes: 59ea6d06cfa9 ("coredump: fix race condition between collapse_huge_page() and core dumping")
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: <stable@vger.kernel.org>    [4.8+]
    Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2008021217020.27773@eggly.anvils
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cb22ed4f00f73cb5e36581d42542ce1192c99b3
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Fri Jul 10 22:11:23 2020 +0900

    perf probe: Fix memory leakage when the probe point is not found
    
    [ Upstream commit 12d572e785b15bc764e956caaa8a4c846fd15694 ]
    
    Fix the memory leakage in debuginfo__find_trace_events() when the probe
    point is not found in the debuginfo. If there is no probe point found in
    the debuginfo, debuginfo__find_probes() will NOT return -ENOENT, but 0.
    
    Thus the caller of debuginfo__find_probes() must check the tf.ntevs and
    release the allocated memory for the array of struct probe_trace_event.
    
    The current code releases the memory only if the debuginfo__find_probes()
    hits an error but not checks tf.ntevs. In the result, the memory allocated
    on *tevs are not released if tf.ntevs == 0.
    
    This fixes the memory leakage by checking tf.ntevs == 0 in addition to
    ret < 0.
    
    Fixes: ff741783506c ("perf probe: Introduce debuginfo to encapsulate dwarf information")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/159438668346.62703.10887420400718492503.stgit@devnote2
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b93a3871edf5126531f4a80df740c1d13b50a6f8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jul 8 16:49:11 2020 +0100

    drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
    
    [ Upstream commit 119c53d2d4044c59c450c4f5a568d80b9d861856 ]
    
    drm_gem_dumb_map_offset() now exists and does everything
    vgem_gem_dump_map does and *ought* to do.
    
    In particular, vgem_gem_dumb_map() was trying to reject mmapping an
    imported dmabuf by checking the existence of obj->filp. Unfortunately,
    we always allocated an obj->filp, even if unused for an imported dmabuf.
    Instead, the drm_gem_dumb_map_offset(), since commit 90378e589192
    ("drm/gem: drm_gem_dumb_map_offset(): reject dma-buf"), uses the
    obj->import_attach to reject such invalid mmaps.
    
    This prevents vgem from allowing userspace mmapping the dumb handle and
    attempting to incorrectly fault in remote pages belonging to another
    device, where there may not even be a struct page.
    
    v2: Use the default drm_gem_dumb_map_offset() callback
    
    Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: <stable@vger.kernel.org> # v4.13+
    Link: https://patchwork.freedesktop.org/patch/msgid/20200708154911.21236-1-chris@chris-wilson.co.uk
    Signed-off-by: Sasha Levin <sashal@kernel.org>