commit aaa1f5834d71fe7b687a0c41834bd8d4cc733d90
Author: Sasha Levin <sashal@kernel.org>
Date:   Wed Jul 7 08:24:58 2021 -0400

    Linux 5.13.1
    
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f6cbd0b3e1e8c96e1c8773bb3978825dec5d00a
Author: Mel Gorman <mgorman@techsingularity.net>
Date:   Mon Jun 28 19:33:29 2021 -0700

    mm/page_alloc: correct return value of populated elements if bulk array is populated
    
    commit ff4b2b4014cbffb3d32b22629252f4dc8616b0fe upstream.
    
    Dave Jones reported the following
    
            This made it into 5.13 final, and completely breaks NFSD for me
            (Serving tcp v3 mounts).  Existing mounts on clients hang, as do
            new mounts from new clients.  Rebooting the server back to rc7
            everything recovers.
    
    The commit b3b64ebd3822 ("mm/page_alloc: do bulk array bounds check after
    checking populated elements") returns the wrong value if the array is
    already populated which is interpreted as an allocation failure.  Dave
    reported this fixes his problem and it also passed a test running dbench
    over NFS.
    
    Link: https://lkml.kernel.org/r/20210628150219.GC3840@techsingularity.net
    Fixes: b3b64ebd3822 ("mm/page_alloc: do bulk array bounds check after checking populated elements")
    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
    Reported-by: Dave Jones <davej@codemonkey.org.uk>
    Tested-by: Dave Jones <davej@codemonkey.org.uk>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Jesper Dangaard Brouer <brouer@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org> [5.13+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5863699d23914b2526b519adc17cb02fb76c165f
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jun 22 10:56:50 2021 -0700

    Revert "KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack"
    
    commit f71a53d1180d5ecc346f0c6a23191d837fe2871b upstream.
    
    Restore CR4.LA57 to the mmu_role to fix an amusing edge case with nested
    virtualization.  When KVM (L0) is using TDP, CR4.LA57 is not reflected in
    mmu_role.base.level because that tracks the shadow root level, i.e. TDP
    level.  Normally, this is not an issue because LA57 can't be toggled
    while long mode is active, i.e. the guest has to first disable paging,
    then toggle LA57, then re-enable paging, thus ensuring an MMU
    reinitialization.
    
    But if L1 is crafty, it can load a new CR4 on VM-Exit and toggle LA57
    without having to bounce through an unpaged section.  L1 can also load a
    new CR3 on exit, i.e. it doesn't even need to play crazy paging games, a
    single entry PML5 is sufficient.  Such shenanigans are only problematic
    if L0 and L1 use TDP, otherwise L1 and L2 share an MMU that gets
    reinitialized on nested VM-Enter/VM-Exit due to mmu_role.base.guest_mode.
    
    Note, in the L2 case with nested TDP, even though L1 can switch between
    L2s with different LA57 settings, thus bypassing the paging requirement,
    in that case KVM's nested_mmu will track LA57 in base.level.
    
    This reverts commit 8053f924cad30bf9f9a24e02b6c8ddfabf5202ea.
    
    Fixes: 8053f924cad3 ("KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210622175739.3610207-6-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>